The Heretech

Forrester open house for PMs

Late last year, we kicked off a series of open house discussions at the Forrester office in Foster City, CA. We're ready to resume that series, so here's the schedule of topics for the next few months:

• March 11, 5:00 to 6:30 PM
  The demographics of B2B buyer behavior
• April 8, 5:00 to 6:30 PM
  The strategic PM
• May 13, 5:00 to 6:30 PM
  PM in the innovation process
• June 10, 5:00 to 6:30 PM
  PM in the transition to SaaS

These events are designed to be informal discussions among you and your fellow product managers and product marketers. (Here's some information about one of the previous meetings, covering PM's role in Agile adoption.) Forrester analysts such as Yours Truly will moderate the discussion, occasionally tossing in some interesting insights from our research.

More details to come as we get closer to the March 11 discussion. Hope to see you there, and please, pass the word to anyone else who might be interested in attending.

[Cross-posted at The Forrester product management blog.]

PM's latest annoying responsibility

The more social we get, the more we expose about ourselves. That's a fact of life that antedates social media, the Internet, or computers. From this perspective, social media are just a new way to  reveal ourselves, sometimes by choice, other times not. 

For the PM in charge of product requirements or release checklists, working on a social media product requires standing your ground on security and privacy issues. I won't beat on the unfortunate launch of Google Buzz further, except to make one last point. To avoid the sort of morass in which Google finds itself, someone in PM needs to have both the authority to insist on whatever external testing, use case analysis, red team testing—some way, any way, to avoid a class action lawsuit.

Unfortunately, very few PMs are experts in security and privacy. Historically, compliance and risk management don't overshadow the tech industry the way they figure prominently in pharmaceuticals and other tightly-regulated verticals. The section 508 requirements of the Americans With Disabilities Act, an important box to check before releasing a new product, is the closest many PMs get to anything resembling regulation.

That situation may change. Security specialists in tech companies deal with technical issues like, "How vulnerable are we to cross-site attacks?" Normally, they are not the people who think through the capabilities of the product to see if there is some way that product might compromise security or privacy. Even if they volunteered for the job, it's not feasible to bring them into the product development cycle early enough to make a difference. Nor will they be able to stay engaged to monitor how the features inevitably change over the course of development.

Therefore, it's unavoidable that security, risk management, privacy, and related issues naturally fall into the laps of PMs. Social media products raise questions about who can pry into your personal information, or how these details might become public without your permission or knowledge. Other products create different risks. For example, the Strange Case Of The Voyeuristic Laptops at a Philadelphia-area high school raises the question, is the company that produced the software used to spy on students at all liable for the abuse of the technology? Does circumventing an operating system's security features create other points of legal exposure?

I've yet to meet a PM who loves dealing with these kinds of issues. Who wants to be the person who, in a release meeting, presents the 15 potential security problems that need to be addressed before the product ships? Particularly if, just before you, someone gave a brilliant demo of how incredibly cool the product will be, if only it could get into the hands of customers. And, of course, success is defined as the absence of problems, not positive gains that everyone can celebrate. ("Woohoo! Three product releases without a lawsuit!") Sadly, I don't see a way of avoiding this responsibility.

Vote for Silicon Valley P-Camp topics

If you're a product manager or product manager on the West Coast, you should take a minute to vote for the topics you want to see covered in the Silicon Valley P-Camp next month. Here's my humble offering, how PM has become an increasingly a strategic asset in technology companies, why this shift is happening, and what you can do to convince your management of the wisdom of making these changes. That's the punchline of the research I've been doing in the last five years, and P-Camp is a good opportunity to wrap it all up with a pretty bow.

[Cross-posted at The Forrester product management blog.]

Buzz as a PM failure

Google now has two recent examples of how not to launch a product. To be more specific, the launches of Wave and Buzz are unfortunate illustrations of product management and product marketing breakdowns.

The first, Wave, was clearly a product marketing failure. Whether or not Wave is a work of sublime genius is beside the point. The dominant reaction to Wave was confusion. Was Wave more an application or a platform? A replacement for e-mail, or a supplement to it? Something built for a general audience, or just techies? Google somehow fumbled the most basic product marketing: We built this product to address this specific problem, for this specific audience, in this specific way.

The Buzz launch also had its product marketing problems, but as discussed in this blog last week, it had at least one huge product management snafu: the privacy features. It wasn't clear whether the auto-generated list of followers was open to the general public or not, and whether you were helpless to deal with unwanted overtures from other users. If you wanted to check, or God help you, change the relevant settings, it took some grit and cleverness to figure it out. And then there were new revelations, such as, by default, Buzz exposed the list of your RSS subscriptions in Google Reader.

A Google PM announced on his blog that the company has implemented "some immediate improvements we are making today based on your feedback." . I would add the word somewhat to that previous sentence. Hunting down some of the options is still difficult. The Buzz UI doesn't clearly convey what the product is supposed to do, other than post updates to some group of people who already appear in my e-mail contact list. Am I supposed to continue e-mailing them, or use this tool instead? What are the pros and cons?

Google got itself into this mess because the Buzz team did no external testing. Once again, a team of very smart people are only smart about the world they know. I'm sure Buzz worked just great in the pocket universe of Google itself. Unfortunately, the domain of people who would be using Buzz was much larger.

I'm a bit worried that the mistakes may continue. Google is collecting feedback through the Gmail forum, an approach that poses two immediate obstacles: (1) knowing that the Gmail forum exists; (2) knowing that the Gmail forum is the right place for Buzz feedback. Plus, who's posting here, representative users, or a self-selected group of Google followers?

Google can get plenty of advice from social media mavens, but that may be exactly the wrong source of guidance. Anyone experienced (or jaded) enough to complain that Buzz commits all the same mistakes as Friendfeed is someone vastly more experienced with, and invested in, social media than the average Gmail user.

My unsolicited advice to the Buzz PMs? Get out of the office. Sit down with a few people who look like the archetypal user and watch them puzzle through Buzz. Then go back to the forums, the blog posts, and other sources of information for whatever good ideas they might provide. Ultimately, you also need to insist on control over the feature list.

That strategy might run against the grain of Google's engineering-centric corporate culture, but Google is also a company that prides itself on being open to new ideas. Here's the next experiment: give PM the opportunity to collect real requirements, and the power to enforce them. See what happens.

[Cross-posted at The Forrester product management blog.]

Google's buzzkill

Yesterday, my reaction to Google Buzz was bafflement. Today, it's frustration, and I can see why some people are finding Buzz to be infuriating.

Product marketing flubs
The Buzz roll-out was not exactly a triumph of product marketing. Starting with the "Try Buzz Now!" entry page, It isn't clear what Buzz does, or is supposed to do, or does in some other part of the Gmail UI that you haven't found yet. Is this a micro-blogging tool? A first step into something like Facebook, with a lot of other Facebook-esque capabilities yet to be implemented?

The introductory video wasn't much help. It did make it clear that Google wants to be the place you consider the center of your social media universe, the place from which you see and link to everything else. For a lot of people, Facebook is that place. For others, it's Twitter. Now, Google wants to compete with them.

Whether Buzz is going to pull users away from Facebook or Twitter, or if it's going to attract people who don't really use anything yet as their social media hub, remains to be seen. As of today, there's not a lot of functionality in Buzz, so other than it being a tool that enhances your experience using other Google applications, it's not clear what Buzz's special value is.

On launch day, Google didn't make the basic use case clear. Are we seeing a failure of product marketing, or is the Buzz development team itself unclear about how people would use this product, or why?

Today, I may have an answer to that question. It's not comforting.

Product design gaffes
Some of the people using Buzz in the last 24 hours have discovered that, in an attempt to be helpful, it exposes the list of people with whom you regularly exchange e-mail. As the Silicon Valley Insider said, "Imagine a boss discovers a subordinate emails with executives at a competitor."

There's nothing in the Buzz UI that tells you, loudly and clearly, about the visibility of the followers list that it auto-generates from your frequent active e-mail correspondents. To make a bad situation worse, even if you learn about this problem, it's hard to fix it.

It takes a lot of digging to unearth the place in Google's UI where you set this privacy flag. Here's a quick list of logical places where I looked, but did not find that option:

• The Google Buzz Privacy Policy Page. Thank you for telling me that I have options. Why not also give me a link to the page where I can exercise them?
• A Buzz post. I thought it might be here, if there were some options at the post level about the visibility of that content. Who knows, it might lead to other security options.
• Your list of followers. Nope, nothing there about the visibility of the list.

Eventually, I found the option. Here's how you get there:

1. Click your picture. Why I would ever click there is unclear. There's no hover text about this being the link to my profile, but that's where it is. Perhaps I'm such a narcissist that I always click pictures of myself, just to see what happens next.
2. Click Edit profile. The Buzz profile is another exercise in obfuscation. It includes information you've already seen, such as your picture and the list of recent Buzz posts. In a very narrow strip of small text links, there's something labeled Edit Profile. That's the right one to click.
3. Click About Me. Huh, I saw another tab with the same name earlier, but this is where I edit that information. Why I can't jump to the About Me editor from the About Me page is unclear.
4. Check or uncheck, er, something. Earlier, I peeked to see if my followers list was public, and thankfully, it wasn't. However, this page tells me that I have exposed that information. What else would you conclude if you saw a check mark next to Display the list of people I'm following and people following me?I'm afraid to touch the Allow people to contact me (without showing my email address) option, since I'm not sure what it means.

Clearly, the UI needs work. It hides the existence of a privacy problem, makes it hard to find the page where you can fix it, and then confuses you about what happens when you check or uncheck an option.

Privacy in social networking isn't exactly a new issue. Why then did Google release Buzz with a big privacy defect? Probably because the Buzz team didn't see the problem, or didn't think it rose to showstopper proportions. 

Problematic assumptions
In a post earlier this week, I discussed the assumptions about privacy (or lack thereof) that many social media companies make. If your baseline user is a teenager or twenty-something, you might build a product that makes assumptions about privacy that work only within that population segment. Relative to other age groups, young adults don't mind sharing where they are, or what they're doing, or what they're thinking, throughout the day. As you grow older, you get a bit more finicky about your personal information. The appeal of a service that splatters your personal information across the Internet drops dramatically.

When I wrote that post, I had no idea it would provide a segue into a discussion about Buzz. Unfortunately, once again, we see a product designed for an archetype of the avid social networking user, a 23 year-old with lots of friends who are interested in how good the udon is at a new restaurant near the Ferry Building. In fact, some members of the Buzz team probably fit that profile themselves. Google prides itself on its ability to hire smart, young engineers who are brimming with ideas and enthusiasm. Left to their own devices, they'll build software that makes perfect sense to them. Unfortunately, many of their users are not like them at all.

In other software companies, the development team has an ally who can tell them when the design doesn't fit the concerns, work habits, and skills of users: the product manager. Google does not have strong product management, so there may not have been a gatekeeper to tell the Buzz team that the product wasn't ready to go out the door.

There's nothing wrong with focusing on young adults as the first adopters of social media, or even the vast majority of your intended users. However, what works for them may not work for other age groups. It may not even work for everyone in that age group, since there are plenty of young adults who don't like giving out personal information. From a product management and a product marketing perspective, it's time for some companies in the social media business to grow up.

[Cross-posted at The Forrester product management blog.]

Want innovation? Hire a good SE.

Service companies definitely understand business problems better than product companies. Case in point: I've been talking a lot lately to both kinds of companies about innovation. When you ask vendors the question, "How do you approach the innovation process?" service companies, on average, say something about business problems first. Product companies, on average, talk about technology.

By no small coincidence, many product companies are now trying to figure out the kind of solutions in which they might play a role. That question has two sides:

1. How do we fit into solutions where we already play a part? If we were to learn how customers really use our technology, we might have an easier time marketing and selling it to them. We might make better investments in our product roadmap, or in our larger portfolio.
2. How might we fit into other solutions where we could play a part? The path of least resistance for market development is finding new business problems to address in our existing accounts. But do these opportunities really exist?

While "technology in search of a problem" might sound silly, that's exactly the challenge that product companies face. They might genuinely want to understand customers better, but they're starting from a greater distance from the actual use of technology than service companies.

Happily, within product companies, there are shortcuts to understanding the customer better, and learning how to think about solutions first and technology second. In product companies, there are employees who deal with customers on a daily basis. They see how technology snaps into place as part of a larger solution architecture.

Many heads of PM teams have told me that sales engineers often make the best new product managers. They've been close to both the customer's use cases and the vendor's technology. They've learned how to speak the customer's language, and they've met the business and IT stakeholders who play critical roles in projects.

Therefore, if you want to hire someone who can help innovation start with customer problems, SEs are good candidates. Unlike support technicians, they participate in both the successes and failures. Unlike consultants, they have greater participation in the phases when the customer is struggling to figure out how the technology will be part of the solution. They have the technical bona fides to deal with the development team directly.

SEs also have a good sense of the features and capabilities that are essential to delivering value to the customer. Many good SEs can help filter enhancement requests better than someone who has not had as much direct experience with customers. For any tech vendor who wants the biggest bang for the smallest development buck, that's a pretty valuable skill.

[Cross-posted at The Forrester product management blog.]

Against a grand theory of PM, part 2

[You can find part 1 here.]

Most fields of study start with classification. The important precursor to any theory, middle-range or grand, is putting what you're studying into conceptual buckets that help organize the topic in meaningful ways. That's where the study of product management and product marketing started, and that's where it has stayed for the last several years. (For more discussion on that point, click here.)

Those conceptual buckets are important, for a variety of very practical reasons. For example, any theory of PM needs to exclude things that are not PM-related. As any of us who have been in the PM profession knows, defining the boundaries of PM has been difficult. The specialized consulting firms, such as Pragmatic Marketing and Sequent, have done a good business helping their clients sort out what their PMs should and shouldn't be doing.

It's a long stretch, however, from classification to grand theory. It took centuries for people studying the natural world to figure out that the classification of matter into four substances (earth, air, fire, and water) wasn't leading to any great insights into physics and chemistry.

On the other hand, when classification hits on something important, it can lead to important insights. The Victorian world's passion for sending researchers to distant lands, to add to the catalog of botany and zoology, led to Darwin contemplating the variation among finches in the Galapagos Islands, which led to the theory of evolution.

However, Darwin's short path from classification to theory is the exception, not the rule. In the PM world, it's important to recognize that someone needs to focus on requirements, and product managers, not product marketers, are the right people for that task. But how much work is necessary to do requirements well? What are the risks of doing a sub-par job with them?

And those are just the obvious questions. Here's a less obvious one: Is there a single correct template requirements? If so, PMs are just experimenting with different collections of content, until they collectively discover the equivalent of double-entry bookkeeping, the format on which all accountants standardized.

On the other hand, requirements might be a medium of thinking and communication that organizations use in whatever way makes sense to them, much as they treat e-mail. Some companies prefer to use e-mail sparsely, keeping more detailed discussions out of the message threads. Others like being chatty in e-mails, and expect their employees to contribute generously to these conversations. In the same fashion, some tech companies prefer detailed product plans to define the contents of the next release, while others create more minimalist documents, with other details to be found elsewhere (or not written down at all).

The answer to that question has profound consequences for the efficiency of development teams, the accuracy with which they guess what customers really want, and the larger organization's ability to bring new products and services to market. Peering into any periodic table of PM responsibilities, or roles, won't reveal the answer. That classification scheme, as useful as it may be, also does not how to measure PM's essential contribution to the company, which impediments put that contribution at risk, and how to resolve these issues.

[Next: So what kind of insights should we be trying hardest to achieve?]

[Cross-posted at The Forrester product management blog.]

Vote for the On Product Management blog

One of the best PM-related blogs around is On Product Management. I link to it frequently, I read it regularly--in short, it's Heretech-approved.

On Product Management is also nominated for the Canadian Blog Awards 2009, in the category of work-related blogs. If you share my high opinion of that blog, go here and vote for On Product Management. (Not that I mind another Canadian blogger getting an award...)

Against a grand theory of PM, part 1

When you're start working in an unexplored field of study, such as PM in the technology industry, it's tempting to propose the Grand Theory Of Everything (GTOE). It's also the worst possible time to develop a GTOE.

Opinion is cheap
Two years ago, when I started this job, I knew I'd have a full research agenda. Very few people took on the job of pundit, arguing for a particular vision of how the PM function should work. Even fewer had any hard data on how it actually does work, in practice. Before making any sweeping statements about the profession, I needed to fill in some big empirical holes.

How diverse is the PM job description, across companies? Which sort of requirements do PM teams give priority? Does moving from an on-premise to a SaaS model have an effect on the PM role? Moving at an Agile pace must have some effect on the rest of the company—but what is it? Without answering these questions, it's next to impossible to give advice.

For example, some aspect of technology companies has made the PM job description different across teams. Unless you understand the forces that have conspired against a consistent job description, there's little point in telling PMs what they should and should not be doing. It's almost as useless as your doctor telling you, "If you're not feeling well, just get better."

Research is hard
Nevertheless, as you're doing the research, you can make important observations specific to the topic that you're currently investigating. Sometimes, the answers are obvious. For example, when I was researching social media as a new source of customer and market intelligence, it was pretty obvious from the start that there was real work involved in using social media in this capacity.

Other times, it's harder to find the patterns. Sorting through the reasons why PMs in one Agile teams is the product owner, and in another team the PM and PO are two different people, took a lot of head-scratching.

You also discover that your initial hypothesis can be completely wrong. I had expected that the companies that invest in requirements tools would be bigger and older, and therefore relatively more capable of affording the purchase and implementation. Unfortunately, the opposite was the case: on average, it's the smaller, newer companies, who feel they can't afford not to invest in these tools, that lead adoption.

Important conclusions are still possible
Consequently, anyone trying to figure out how to make PM work in the tech industry is going to be working primarily on middle-range theory, not the GTOE. If middle-range theory doesn't sound important, it's worth remembering the significant role that this level of work has played in the hard sciences. Observations like, Gravity bends space-time, or, These hitherto unnoticed chemical sequences are the reason why you're a human and not an antelope, are major steps forward in our understanding of how the world works.

If someone can figure out why even the most meticulously written and reviewed requirements don't stop some tech companies from making products that their users don't like or can't understand, that's a big contribution to our little field of study. Best to have more middle-range theory before even thinking about the GTOE.

Next: The difference between theory and classification.

[Cross-posted at The Forrester product management blog.]

Open house on tech industry Agile adoption this Thursday

Welcome back from your long weekend of tryptophan-induced torpor! This Thursday, December 3, we're hosting our second open house for product managers and product marketers at Forrester's office in Foster City, CA. These are monthly informal discussions in which the usually blabby analysts take more of a supporting role, kicking off the discussion and dropping, where appropriate, insights from our research on the topic du jour.

This month, the topic is Agile adoption in the technology industry. Specifically, we're going to discuss the effect that Agile adoption in the development team has on the rest of the company. A few examples of the questions that we often hear include...

• How will QA need to adopt?
• Do we need to re-think product launches?
• What's going to happen to the structure, content, and schedule for requirements?
• How do Sales, Marketing, Support, and other customer-facing groups stay apprised with the product roadmap?
• What is the product roadmap, really?
• Will executive management's role in the development process change?

WHEN: Thursday, December 3, from 4:00 to 5:30.

WHERE: Forrester's office at 950 Tower Parkway, 12th floor, in Foster City, CA.

WHO: You, and anyone else you think might be interested. I'll be leading the discussion this month.

HOW MUCH: Free.

AGENDA: Before and after the official discussion, we'll have some time for informal conversation, getting to know your peers from other companies, etc.

RSVP: Not required, but it's nice to know who's coming. If you have a minute, drop Marsha Versen ([email protected]) an e-mail to let her know that you're attending.

FUTURE TOPICS: I'll be posting a preliminary schedule in the next few days. We live to serve, so it's important to tell us what you want to discuss. Here's a survey that we're leaving open indefinitely, so that you can indicate the topics that interest you the most.

Look forward to seeing you this Thursday.

[Cross-posted at The Forrester product management blog.]

I love you guys

I was extremely grateful to meet, in person, my fellow product management/product marketing bloggers who attended the PMEC 2009 event. What a great group, the Oceans 11 of PM blogging. April, Brian, Michael, Ivan, Ivan, Alison, Marsha, Gavin, Janey, and Ethan, don't be strangers. You're always welcome to pay us a visit at the Forrester office in Northern California, perched in the clouds above Foster City.

And many thanks, too, for AIPMM for organizing this event. Great idea, and nice work putting it together.

There can be only one!

Just a quick reminder that I'll be at the "Battle of the PM Bloggers" next week, as part of PMEC 2009.

Also, be warned, the intensity with which I compete is inversely proportional to the actual stakes.

Sad, but true.

Topics for future PM open house sessions

Last Thursday's inaugural "open house," an informal get-together in Forrester's Foster City, CA office , achieved what we had hoped: lively conversation on a topic of immediate interest for product managers and product marketers. We're definitely planning to do more of these events, so the critical question now is, What topics should we cover?

To the extent that the format drives the questions, here's what it means to do an open house:

• Somewhat unstructured conversation about the topic. (We'll continue to tune how much structure to impose.)
• Forrester analysts provide occasional data points and insights from our research to inform the discussion.
• Some time for attendees to talk with each other, outside the group discussion. (Something we didn't do last time, but definitely want to add to the next session.)

Here's a link to a Survey Monkey questionnaire where you can vote on some hot topics, or suggest other ones. There are always more topics that we might cover, so let your imagination run wild.

No cranky for you!

Apparently, the Cranky Product Manager won't be presenting at the Business of Software conference, alas. You can console yourself with this interview with Her Cranky Nibs from earlier this year.

Crankiness out of the closet?

In case you missed it, The Cranky Product Manager is going to give a talk at the Business of Software conference next week. Really.

By the way, I'm not speaking at that event, but I'll be attending. By all means, find me and say hello if you're also there.

Is "social product management" for real?

Here's an important rule of thumb, if you're a researcher such as myself: Don't name something unless it really exists. That sounds fairly obvious, but unfortunately, in the history of the technology industry, there's a sad history of failed neologisms. In some cases, these phrases exaggerated the importance or complexity of some relatively mundane aspect of the world. That's how the superheated usage of the term knowledge management turned into a four letter word. In other cases, people use neologisms designed to describe things that might (or might not) exist in the future as if they already existed now. I've heard some presentations about the Semantic Web that certainly fall into that category.

Therefore, when I use a phrase like social product management, believe me, I'm using it very carefully. Over the course of the last week, I've had occasion to use it on several occasions, most recently at last night's open house for PMs in the Forrester Foster City office. (Thanks to all who attended, by the way.)

Social product management passes the sniff test for neologisms because it describes something that's really happening: social media are changing the way that product managers and product marketers work. Here are a few manifestations, excerpted from the research I've been doing for the last several months:

• Social media figure increasingly in the to-do lists for PMs. Whether it's answering forum postings or monitoring "chatter" about your company on Twitter, PMs are spending more time using social media to get some aspects of their job completed.
• Social media demand new skills to master. It's abundantly clear that using social media, in either an inbound or outbound capacity, takes real skill. Unfortunately, not everyone has learned how to  spot the social media outlets where particular kinds of stakeholders congregate, or how to collect and interpret a representative sample of aggregate social media activity.
• Social media frequently require investment. It takes time and effort to figure out which social media channels are worth your attention. In some cases, new tools, such as listening platforms, can be a big force multiplier in these efforts.
• Social media require new attitudes to work. Everything falls apart if the company isn't ready to take social media seriously. Strangely, customers expect social media to be the place where conversations happen, instead of providing yet another brand of megaphone for vendors to announce their greatness. They also expect you to follow up on these conversations. Weird, but true.
• Social media foment professional crises for PMs. The natural consequence of the previous bullets are some tough conversations between PMs and their managers. Topics include How the hell do you expect me to do this in my free time to Why use these new sources of intelligence if we continue to make the same mistakes in the decision-making process? However these conversations turn out, the fact that they're happening at all means that social media are having a real effect on the PM job.

Let's be clear: I'm not saying that social media obliterate everything that PMs used to do. Far from it. In pretty much every aspect of the job where social media are relevant, they supplement existing PM tasks, deliverables, or resources. For example, as useful as innovation sites may be (users propose features, comment on them, vote on them), you still need to have occasional face-to-face conversations with people in customer organizations. If 5,000 people vote for a great new feature, Ion flux regulator, that doesn't tell you why it's important to them, how they expect it to work, and other critical details that bear directly on prioritization and design decisions.

Therefore, the phrase social product management does have weight and purpose, to the extent that social media are changing the way that PMs in the tech industry work. Me absolvo, it's not just another meaningless buzzword.

[Cross-posted at The Forrester product management blog.]

Reminder, open house on social PM is tomorrow

Just a quick reminder that the "open house" for product managers and product marketers is tomorrow at 4 PM PST at Forrester's office in Foster City, CA (click here for a map). As my earlier post explains, the intent is to kick off a series of informal conversations about topics of interest.

For this first open house, we'll be discussing how social media are changing the job descriptions, priorities, deliverables, and required skills for PMs. All are welcome, the event is free, just come on down.

Beastly blogger battle

The AIPMM has invited me to be part of its "Battle of the Bloggers" panel at the Product Management Education Conference two weeks from now.

Frankly, I'm torn. I like all the fellow PM bloggers that I've met. I can't imagine getting my jollies from crushing Brian Lawley or Alison Charter-Smith. On the other hand, I find it hard to resist my competitive urges, even if the stakes are nonexistent.

Or maybe I'll take this way out of the conundrum...

The PM blogroll

Saeed Khan has done us all a great favor by compiling this compendium of PM-related blogs.

The path to professionalism

I spend a lot of time talking about how the job of product management and product marketing may be becoming a genuine profession. This sort of change isn't unique—other roles, at other times, have experienced the same process of increased professionalization. Given my interests outside the technology profession, I naturally looked back in military history to find an analogy, and Voila! within a few seconds of pondering, there it was.

In modern history, the big tilt towards military professionalism happened during the upheavals from 1789 to 1815. As with any major historical shift, it would be a mistake to talk as if a single event changed everything, and military professionalism is no exception. Still, it's hard to imagine the process going as fast as it did without the French Revolution and Napoleon.

Roughly, here's the sequence of events:

• Before the French Revolution, officers in the French army came largely from the aristocracy. For them, generalship was an avocation, not a full-time vocation.
• As the radicals gained increasing power during the French Revolution, successive French governments purged the officer corps of aristocrats.
• Meanwhile, other military reforms helped create Napoleon's fearsome Grande Armée. Other changes, such as mass mobilization, made their contributions, too.
• After watching the French rampage throughout Europe (and often being on the receiving end of these rampages), other governments started to emulate the successful French example.

So, by the end of the 19th century, officers became full-time professionals, instead of dilettantes. They received specialized training at military academies, where they studied a college-like curriculum covering the "art of war." Specialized treatises, such as  Clausewitz's On War, formed the core of this curriculum, as did the best practices learned through hard experience in past conflicts.

So, how does this relate to the PM profession?

Skills define the profession
First, it's worth noting how military professionalism got started. One important reason was the growing awareness that technical ability mattered. Napoleon started his career studying artillery, probably the most technically demanding aspect of warfare at the time. At the siege of Toulon, he put these skills to good use, earning him the recognition that made Napoleon...Well, Napoleon.

PMs also have valuable technical skills—but not the type that many have thought were necessary to work in a technology company. Understanding how software and hardware work is, of course, necessary. However, the specialized skills of PM—the kind no one else in the company has, and which the company needs someone to have—have more to do with social science than computer science.

To the surprise and dismay of some PMs with MBAs, a business degree is not the sure-fire way to acquire these skills. The basics you learn in business school, such as the fundamentals of marketing, certainly have relevance. However, if you receive an MBA, you might have no idea how organizations adopt technology, which turns out to be a critical issue in this industry. (After all, car manufacturers don't have to convince their customers to use the cars they buy.)

Events create the need for these skills
The other important part of this analogy is the catalytic event. In the case of military professionalism in the 18th and 19th centuries, that catalyst is easy to identify, the eponymous Napoleonic Wars. Even the most hidebound countries, such as Prussia, reluctantly copied at least some aspects of France's military model.

In the technology industry, the stimulus is harder to identify. On the one hand, there has been a subtle, gradual shift from information technology (IT) to business technology (BT). The burden is increasingly on the vendor to demonstrate the business value of technology, instead of on the customer to figure it out for themselves.

Natually, the next question is, has the recession given technology companies the compelling reason for PM professionalization? It's probably too early to say for sure how much a difference the economic shocks of 2008 and 2009 have made, but certainly, they have played some role.

Technology companies have grown increasingly worried about the amount of waste and inefficiency in their businesses. You hear this concern echoed in the topics currently in vogue, such as the innovation process, portfolio management, and (most obviously) Lean principles.

Which begs the question, who in the company is in the best position to prevent waste and efficiency? Who, for example, is responsible for determining how to connect new ideas to genuine business needs? Certainly the people who write requirements, or craft messaging, are the best suited for this task. And if not them, then who?

There's a lot more to say about this topic, none of which will fit into this already overlong blog post. (For example, what are the essential PM skills?) The basic point, that we can use other instances of professionalization to understand where PM professionalization is going, and why, should be comforting to PMs living in the middle of this change. The path may be circuitous, bumpy, and even lead to the occasional wrong turns, but we know, once it starts, where it ends up.

PM open house at Forrester's Foster City office on 11/05

On Thursday, November 5th, from 4:00 to 5:30 PM, Forrester Research is hosting an informal discussion about product management and product marketing issues. This session is the first in what we hope will be a series of conversations about these topics, scheduled at Forrester’s Bay Area office in Foster City.

The topic for this kick-off session is how social media is changing the job description for product managers and product marketers. I'll lead the discussion on this topic, since I just did an all-day workshop about "social product management."

The operative word in that last sentence is discussion. If you want to be pummeled with PowerPoints, look elsewhere. We want to host discussions among product managers and product marketers. Our role is to provide insights from our research, and give you a chance to meet and speak with your peers.

We’re very interested in hearing what topics you’d like us to cover. Forrester’s analysts covering the tech industry can provide information on a variety of topics—from requirements to market development, from Agile to SMBs, from B2B marketing best practices to supporting the salesforce. However, we’re more interested in developing a series of informal conversations on the topics that matter most for you. Please send us your suggestions.

Please RSVP with Marsha Versen ([email protected], 650.581.3851) if you are interested in attending. All are welcome to join us, but we’d appreciate the RSVP so that we know if we’re going to run into space restrictions. If you have questions about the event, don't hesitate to contact me ([email protected], 650.581.3846).

Forrester's Northern California office is at 950 Tower Lane, Suite 1200, Foster City, CA. (Click here for a map.) 

How many personas?

Mark Lauden Crosley poses a great question: how many personas are enough? Or too many?

Since I have a fancy degree in political science, my own answer naturally comes from that background. Social scientists have been developing personas for as long as there's been something, self-consciously, called social science. Old Uncle Max (my endearing nickname for Max Weber) had one of the first, and one of the most useful definitions. Unfortunately, it's hidden behind a wall of academic verbiage. And to make matters harder, it's translated from the original German:

It is important to realize that in the sociological field as elsewhere, averages, and hence average types, can be formulated with a relative degree of precision only where they are concerned with differences of degree in respect to action which remains qualitatively the same.

In other words, personas (or, as Old Uncle Max called them, ideal types) are the product of two things. First, of course, there's the role that you're putting under the magnifying glass to study. That's what Crosley refers to in his post on persona development:

On the surface, it may appear that two customers in, say, legal services and construction management have little in common. But perhaps they have similar job descriptions and a similar set of problems in the area of financial planning and accounting, and perhaps these problems are especially relevant to the product you're creating.

You might have someone who behaves in the fashion of a Middle Manager, or Technical Professional, or Persnickety Auditor, in different types of organizations. That's definitely true, and it's the basis for a lot of creative market development, in which people look for problems in new markets that are similar to the ones they've helped address for their current customers.

However, there's another part of persona development, the question you're asking. In the rest of the same passage from Weber's "Definitions of Sociology and of Social Action," he goes on to say (to paraphrase), "Are you studying economic behavior, religious belief, or political organizations? The differences among two different people might not matter at all in one context, and a lot in another."

I faced this question recently when I was working on the PM job/department profiler. Are product managers and technical product managers different enough to create two different profiles for them? If we were looking at just their salaries, or their positions in the organizational chart, then the differences are pretty negligible. If, on the other hand, you're interested in what tasks they perform, or what skills they need to perform these tasks, there's a marked difference between them.

There are practical considerations, too. Again, here's Crosley:

So here's my answer: One persona is almost certainly too few for a commercial product/service, while more than a dozen (especially 37!) is too many. Four to six seems like a sweet spot.

You'll definitely need to economize somehow. That's probably a good rule to apply anyway, since decently smart people can tie themselves in knots, thinking about all the differences that might be relevant. But what's really an essential difference?

My only disagreement with Crosley is, you might not always be able to prune the list down to 3, 4, or even 10 personas. In some contexts, such as B2B technology adoption, you might have all kinds of characters playing significant parts. For example, while the individual salespeople might not be champions of a new SFA tool, they'll certainly be important influencers. And we haven't even yet identified who are the important champions, implementers, decision-makers...At a certain point, you have to just deal with however many personas really matter, even if the research takes longer than you had hoped.

The PM job calculator: validation

[Last in this series about the Tech Product Management/Marketing Job And Department Profiler. Previous posts cover its origins, the design decisions that went into it, and the job specializations it profiles.]

From my grad student years, I know that a lot of mathematical models fall flat on their simulated faces because they don't get the testing they should. In the case of the PM job calculator/department profiler, I had to apply three different tests.

The tasks are many and varied
Last year, when I did the survey research on the state of the product management/product marketing job in technology companies, I vetted the list of tasks with a lot of PMs. Using their feedback, I added tasks, rethought others, and even merged a couple. The resulting list represented everything that PMs might be doing, depending on where they work.

That was the easy part.

The tasks define the jobs
A major goal of the Profiler is, as I explained in an earlier post, classifying PMs according to their specialization. A requirements-focused PM is not a product manager, who is not a release manager, who really isn't a product owner, who can't find the spare time to also be a community manager...You get the idea.

Consequently, the next test involved showing these job categories—defined by the tasks these roles perform, and the priority each task receives—to people who run PM departments. That group included the heads of product management teams, product marketing groups, and combination product management/product marketing departments.

Since no one's job description for any of these roles exactly resembles anyone else's, the goal wasn't to find perfect agreeement among job categories as they're defined in particular organizations. Instead, I did a version of "ideal type" analysis: does this definition offend your sense of what's essential about this role? Over the course of several conversations, I managed to develop a set of ideal types that everyone found more or less acceptable.

The jobs define the department
When I started this project, the stretch goal was finding a way of using the job-level results to help define what mix of people you might need at a departmental level. Surprisingly, that stage of the project was easier to complete than the job descriptions.

Perhaps that's because every senior director or VP of a PM organization focuses first on the type of person needed to perform a job, steps back a bit, and then figures out how many people, at what level of seniority, need to appear in the group portrait.

The most important choice was, which variables mattered? There are dozens you might consider, from the type of product to the size of the company. While all of these variables have some influence, they don't all have the same weight in determining what kind of team you need to build.

Once again, tasks proved to be the right starting point for this project, for a variety of reasons. For example, the degree to which someone can focus on their core responsibilities has a definite impact on how many of those people you need.

This last stage of validation revolved around the question, "You put this information into the black box, and out comes this picture of the kind of department you need. Does this picture make sense?" The results had to be good enough, since a perfect calculation is probably not possible. (Again, many variables have relevance, but it's necessary to focus on the ones that matter the most.) Perhaps not all of these people in this hypothetical department, in practice, report into the same group, but they have to exist somewhere in the company to provide adequate support and leadership for the product or service under development.

Don't let the perfect be the enemy of the good
Even though perfect accuracy in the prediction of staffing needs—how many, in which roles, at what level of seniority—may be impossible, the "good enough" picture has definite value. For example, during the validation discussions, some PM department heads were interested in showing the results to their management to (surprise!) justify their staffing needs. Others spent time discussing the things they hadn't considered, such as tuning their organization to better support the sales team. Someone else spent a long time talking with me about where to shift particular tasks, if you take them off the shoulders of PMs.

In other words, the Profiler provides a starting point for a discussion about organizational changes. Without it, you might not be able to have that discussion, since the proverbial devil is truly in the details. Making a particular task, such as maintaining the product roadmap, a higher or lower priority affects other PM responsibilities. It also begs a lot of questions about skills, time management, deliverables, and compensation.

However, if you didn't have some kind of detailed portrait of what PM does and doesn't do, it's difficult to get to these second-order questions, such as professional development. If you don't force yourself to be specific about PM priorities, then there's always a case for something else to get added to the to-do list. Unfortunately, that often leads to the situation in which, if everything is a priority, then nothing is.

[Cross-posted at The Forrester product management blog.]

The PM job calculator: specializations

[Continuing the "behind the scenes" discussion of the Product Management/Marketing Job And Department Profiler, a.k.a. the job calculator. Here are the links to the first two parts, covering the origins of the calculator, and the design decisions behind it.]

As discussed in the last post on this topic, I decided to define product management roles through the tasks that those roles perform. The maxim, "You are what you do," made it easy to define different job categories for product managers and product marketers. A task -based approach also helped make a more convincing argument why particular specializations are necessary.

Tasks—what are people doing, and how much attention or emphasis does each task receive—make the difference between, say, the canonical product manager and the archetypical product marketer clear. Realistically, you never have enough time to do everything that's on the massive List Of Things For Which PM Might Be Responsible, nor are you necessarily good at all these tasks. Plus, if everything is top priority, then nothing is top priority.

From single-cell creatures to complex animals
If you add up the tasks that product managers do to ensure that a particular product or service meets its design and business objectives, you already have a pretty big list. Just working with the development team is going to consume a lot of time, without adding product marketing tasks like developing messaging, or even the project management tasks related to the development cycle, such as ensuring company readiness for a new release.

If you keep pushing the question, What should I be doing, and how important is it that I do it? it's easy to see the further specialization beyond just the product manager/product marketer distinction. I've already alluded to the separate job function of release manager, who's responsible for project management. There are also sales enablement specialists, whose job it is to support the customer- and partner-facing parts of the company. Sure, PMs have a role to play in sales enablement, but it's dangerous to have them spending too much time focused on the field. Even though the average PM crafts product strategy through the media of requirements and roadmaps, a user experience professional is contributing to the product's success in a different way.

In many companies, these roles report into different parts of the org chart. Whether or not they're centralized into the same PM organization is a question of execution.

Evolution creates new differentiations
In recent years, we've seen the emergence of other job specializations. The difference between product owners and product managers may not be completely clear, but the roles aren't exactly the same. (We heard that issue discussed a lot at the Agile 2009 conference. The role of PM in an Agile team turned into a much bigger research project than I ever expected, because there are no clear-cut right and wrong ways of defining it.) The explosion of social media has inspired a new job category, community manager, responsible for product management- or product marketing-like activities exclusively within social media outlets.

During the validation phase of this project, when I showed the calculator to heads of PM groups, no one blinked at these job specializations. It's clear that the day of the generic PM is over. What we call a product manager now is someone who is focused on product and service development. That person often works side-by-side, in the same group, with product marketers, technical product managers, release managers, and in some cases, even sales enablement. Or, these functions are scattered across the organization.

Nevertheless, the increasing specialization of product management and product marketing seems to be a fact of life. The to-do list—how big it is, and how much priority each task receives—has made that conclusion inescapable in any organization serious about the PM role.

[Cross-posted at The Forrester product management blog.]

PM is more than features

Jeff Lash makes an excellent point:

If you want to be a good product manager, realize that your job is much more than prioritizing features. Sure, a product manager needs to understand what features need to be added to a product to meet customer needs, though just focusing on collecting and prioritizing features is an extremely narrow view of product management.

Product managers need to have a much broader view, seeing and understanding everything from the underlying customer needs to the business model to the product roadmap to the go-to-market strategy.

While Jeff says that many PMs fall into this trap, under a different set of circumstances, other PMs find themselves spending far too little time on feature-related work. Sales enablement, marketing support, and project management are the usual distractions from feature work.

Balance is difficult, particularly if the organization doesn't fully understand what PM is, or does, or should be doing. When that happens, whatever becomes urgent elbows aside whatever else might be important.

I'm increasingly convinced, therefore, that PMs should craft an elevator pitch that reflects the need for this balance.  Something on the order of, "I'm the person who makes sure that technology contributes to our business, and business allows the development and adoption of that technology."

Social product management workshop coming soon

For anyone interested in using social media as a resource for product requirements, persona development, use cases, and other customer insights, the workshop on this topic is scheduled for later this month.

The goal is to give you specific, practical guidance that you can use the day after the workshop. Therefore, I'm asking attendees to bring examples of their current challenges in gaining customer insights, from either a product management or product marketing perspective. We'll use those scenarios during some hands-on exercises.

Here's the link to the workshop, if you're interested. Space is limited, and based on the number of questions I get about this topic, it should be a lively session.

[Cross-posted at The Forrester product management blog.]

The PM calculator: tasks

[Continuing the discussion of the PM Job And Department Profiler from the previous post.]

The most fundamental decision for the Profiler was the choice of how to depict the PM role. I might have chosen functional areas, such as Pragmatic Marketing's famous diagram of PM responsibilities, or something skill-based, such as Steve Haine's efforts to define product management and product marketing as a corpus of knowledge that people in that profession need to master. Instead, I decided to use tasks to build the picture of what PMs do.

There's nothing inherently wrong in the other depictions of product management, but they weren't the right raw materials for what I wanted to do. If I accomplished nothing else, I wanted to depict the volume of work that PMs do, and the degree to which that work is focused or unfocused.

The Pragmatic Marketing periodic chart of responsibilities tells you how to categorize the work, but the categories don't point directly to the amount of work. A skill-based approach tells you how many different skills you need to acquire, and might even suggest how challenging some of those skills are to learn. However, that doesn't tell you, in hurly-burly of daily work, how much time the tasks that require those skills will take, or (again) how challenging it is to juggle competing priorities.

From zoology to ecology
The closest analogy I can think of is biology. As my graduate adviser said, "Every science begins with classification." That's what the Pragmatic Marketing framework does very well: define the different species of responsibilities that constitute the family tree of product management and product marketing. However useful and necessary classification may be, it doesn't answer all the questions of biology, such as, "Why do these species dominate, and these other ones don't?"

To take this analogy further, job descriptions are like ecological niches. Many different species might fill each niche; not everyone is equally well suited to do so. (By the way, the number of niches keeps expanding, but that's a topic for another post.)

Tasks, therefore, are the essential traits that determine the success of a PM in each niche. If the PM is doing the wrong activities, or is too busy to perform the essential activities, then that PM won't do well within that niche.

The ecology of vital business activities
Classification tells us what species have evolved to fill these niches. Skills, like DNA, define what the species is capable of doing. However, if the question at hand is, What kind of PM should we have? the answer depends on what the PM is actually doing within a particular niche, a.k.a. job category.

Or, to look at it another way, classification of PM job categories is interesting, but it's not a very convincing argument for why a company should adopt one species over another. On the other hand, discussions of skills is sometimes premature, because it begs the question, What's the vital business function for which these skills are necessary? Tasks, as it turned out, were a better starting point for defining the vital business functions in a way that might lead to a fruitful discussion of, We need this many PMs in these specializations to do the job right.

Personas of interest

Christopher Cummings brings up an always-interesting topic: why people don't use personas as much, or as well, as they might. While persona certainly has a specific meaning in Agile, the same kind of deliverable—a profile of an archetypal user or stakeholder—exists in marketing and sales, too. It may go by different names, and people may develop and use these personas with more or less rigor.

Cummings cites three main pitfalls with personas:

• Dealing with objections about their usefulness. This seems to be the easiest object to handle. Even if someone doesn't officially build personas, they still develop a mental sketch of the average user. You might not like the conceit of writing a fictional profile, but that's just a question of style.
• Picking the wrong personas. People can get a bit sloppy about which persona they choose for a particular user story, use case, or requirements doc. For example, reporting features in a CRM system are really for sales managers more than account managers or telesales representatives, so choose wisely when you prioritize and design those reports.
• Dressing a feature in a persona costume. Naturally, product people like to talk about products, so it's hard for them to stay in persona-mode for too long. Unfortunately, the

The other pitfall I raise may be just an amplification of the "wrong persona" problem, but it's an important one:  When do you stop identifying ever finer distinctions  within roles?

For example, is the role developer enough, or should you make a distinction between development manager and engineer who's an individual contributor? Or should you go further, and define some very senior individual contributor role, such as architect, that's different from the rank-and-file developer?

It's a tough question to answer, since it depends  both on the role and the question you're posing. I've been surprised, for example, to see how different enterprise architects and application developers can be, when citing the sources of information they use to answer technology purchase and adoption questions. Therefore, from a marketing perspective, you need two different strategies to reach these different roles. (A quick, obvious example: Application developers really don't like calls from salespeople.)

In other contexts, these distinctions might lack a real difference. Would you design an IDE differently for rank-and-file developers versus enterprise architects? There might be some differences, particularly when it came to project management details. (Developers might be interested strictly in items related to their own to-do lists, while architects might want a broader view of the project.) However, the degree to which you tailor the product to fit these roles might be far smaller than the amount of custom-tailored marketing you need to do.

Which leads to another potential risk, duplication of effort in persona development. Just because a product manager didn't find justification for major differences in product design doesn't mean that the research into these roles is useless for product marketers. If I were a product marketer and someone were to tell me, "We didn't find any reason to change the product, but here's a lot of information about application developers and enterprise architects that might be useful to you," I'd be glad for the help. Not only would my colleague have saved me a lot of basic research work, but I might spot some marketing-related details in the information already provided.

Persona development requires a lot of patience to tease out the relevant details. However, the work is definitely worthwhile, since it can prevent a lot of costly mistakes. And really, there's no alternative, other than extremely unproductive arguments between people who have not spent time researching John Q. User, which one of them has the better understanding of this archetype.

[Cross-posted at The Forrester product management blog.]

The PM job calculator: genesis

The Product Management/Marketing Job And Department Profiler is finally, finally available (Forrester account required). This project was unusual in  a lot of respects, so it's worth spending a little time explaining it. You might also get some insight into how research gets done at Forrester, which might be a little mysterious to the outside world.

What is it?
Here's the short version: You enter the priorities for a particular PM, and you get a recommended job description. If you want to go one step further, you can also get a picture of what your department should look like: how many PMs, in which specializations, at which level of seniority for their positions.

In other words, it's a tool designed primarily for the people who run PM groups. The Profiler is also useful for rank-and-file PMs who might want to gauge where their priorities and skills are, and where they should be.

I'll get into more details about the tool and how it works in a later post, but let me first explain why I created it.

What inspired it?
Last  year, I ran a survey to find out what PMs were doing in their jobs, versus what they thought they should be doing. The results, released in the document "Product Managers Were Working On The Wrong Things," were very interesting.

For example, we saw in stark terms how product managers struggled to stay focused on their core work, helping the development team make good products and services, because they were pulled into many tasks that were not directly relevant, such as marketing support and sales enablement. At the same time, product marketers had their own version of "the urgent defeats the important" principle, with too many conflicting priorities and too few resources to address all of them.

Of course, the next question is, "Now what?" The point of this study wasn 't merely to commiserate, but to suggest a course of action to fix what is perhaps the core problem with product management and product marketing in the technology industry: vagueness about roles, responsibilities, skills, and deliverables. Research that dramatized the problem was necessary, but not sufficient to do more than generate broad recommendations (for example, run your department so that product managers can focus on their requirements).

Why this approach?
After having defined a problem area, the standard analyst response is to dig more deeply into each part of it. And, to a large extent, that's what I've been doing. Natural topics for further research included:

• How the development and delivery processes shaped the job description, which led to work on product management for SaaS products, and the role of the product manager in (or adjacent to) development teams that have adopted Agile methods. 
• What PMs produce, which inspired some work on serious gaming and product requirements.
• Where new opportunities to improve product management exist, such as the multi-part series on the role of "inbound" social media as a new source of requirements. Again, in this case, we circled back to the question of how the nature of the work—in this case, collecting information from social media channels—affects the definition of the job.

In fact, nearly everything that I've written points back, to some extent, to the roles and responsibilities of product managers and product marketers. Are they really two different roles, or one? If they're separate, should they be part of the same department, or different ones? What are the important adjustments in a PM's to-do list, based on the type of product they're working? How do these changes dictate the skills necessary to handle these tasks? What kind of authority should PMs have, over which kinds of product-related decisions?

Rough sketch, not paint by numbers
Even if I did the best job imaginable in each research document, I still felt that something was missing. Tech companies want baselines against which to measure their own PM organizations, and they want best practices for getting the most from these teams. Ultimately, however, they want a picture of what the PM team should be.

Individual pieces of research fill out some details. However, these details don't always add up to the complete picture. Or, to look at it another way, you need a rough sketch of the family portrait before you fill in the details for each person.

That rough sketch is vital for answering many common questions, such as the PM's relationship to an Agile team. If you choose the "PM as product owner" option, that won't necessarily tell you everything you need to know about the tasks that person performs, who takes care of the PM-like tasks that are now off that person's plate, and what skills and experiences the hybrid product manager/product owner needs to succeed. While a snapshot of the individual PM might be useful, a family portrait that includes other roles and responsibilities is even more helpful.

The Profiler provides that rough sketch. You won't find many (or perhaps any) tool like it, which is why it took a long time to build. It was worth trying to build one, even if the experiment turned out to be an utter failure.  If we know that you can't create the rough sketch, you'll continue working on separate pieces. It's then up to the reader to build a mosaic of the pieces, in no particular order.

On the other hand, if you can build the rough sketch, you can tell right away which areas will need the most attention, and how they affect adjacent pieces. If Rembrandt hadn't the whole composition of The Mill worked out in advance, he would have wasted time on sections of the canvas that, in the end, make the central subject as striking and interesting as it is.

[Cross-posted at The Forrester product management blog.]

Are PMs ready to focus on research?

Several forces are pushing PMs in the same direction: both product managers and product marketers are under increasing pressure to be good researchers. Here are a quick summary of but a few of those industry changes, and how they put greater stress on the research part of the job:

• Demanding customers. Even before the recession, customers wanted better explanations of a technology's value, and they were increasingly impatient about receiving that value post-purchase and post-implementation. Who's going to do the research about what these roles want, and how products and services can deliver them?
• Innovation. Tech companies realized the cost of making inventions that people don't want to use, or can't figure out how to use, or are not economically viable for the vendor to produce. From ideation to adoption, therefore, PMs are asked to get the information needed to decide whether to continue working on an innovation, and what direction it should take.
• Social media. There's a lot of user-generated content that's potentially relevant to making product decisions, but someone has to make sense of it. If you're a PM for a BPM product, you might get a strong read through different social media outlets that mobile support is important. But for which users? And what use cases? Are these requests coming from your part of the market?
• Agile.  Once product teams get into the pace of shorter iterations, they pose regular questions to help them make good prioritization and design decisions. PMs therefore need to be constantly on deck, ready to take a swing at each of these questions as they come in.

Normally, when I present a list like this one, I see a lot of nodding in the audience. The good news for both product managers and product marketers is, Congratulations, your organization sees the research you do as a strategic asset. For many PMs, the bad news is, You're going to have to give up some other tasks.

Of course, many are eager to do so. The biggest complain among PMs we've surveyed is, We don't have enough time to tackle everything on our to-do list. However, from talking to a lot of PM group leaders, as well as having being one myself, I know how hard it can be to detach PMs from one set of tasks to focus on another.

For some PMs, it's hard to give up on the excitement and glamor of many of the very same tasks that they grumble are distracting them from their core responsibilities. Sales calls are unpredictable and time-consuming...But for people who are interested in what people want to do with the company's technology, talking to these people hardly ever seems like a waste of time. Marketing support, such as staffing the booth at trade shows, carves out weeks from the schedule...But they also can be fun, and they're a way to peek over the shoulders of partners and competitors.

Some PMs have a harder time than others of letting go. One person who worked for me got addicted to questions from the field, the dozens of e-mails that flowed in, every day, and started with the same stock phrase, "I have a customer who..." We needed him to put more effort into product requirements, but it was hard to get him to focus. He hated to let any question go unanswered, or trust someone else to do as good a job of answering it.

Other PMs have a hard time letting go of bug meetings. If you see yourself as the voice of the customer, then Q.E.D., you want to be sure that the customer gets strong representation in decisions about bugs. If you never  do a better job of collecting customer insights and communicating them to the team, you'll continue to sit through hours and hours of bug discussions.

PM managers may worry that, as the demand for research goes up, their team has the necessary skill and talent. They should also worry about the force of habit, which as Thomas Carlyle argued, may be "the deepest law of human nature." PM managers need to think about the psychic rewards that research priorities can provide, as replacements for some old sources of job gratification.

More for the PM playlist

Based on some recommendations from friends of the blog, I've made some additions to the PM playlist.

Why everything needs a sanity check

Whether you prefer to call them private security firms or just plain old mercenaries, these companiesdo a terrible job at naming themselves. The connotation of Custer Battles is obviously awful. But how about Triple Canopy, a phrase that gained currency in the 1960s to describe the jungle landscape of South Vietnam? (Now that sets off a train of associations you don't want to follow: Vietnam, quagmire...) Or the new name for Blackwater, Xe, which sounds like our new alien overlord?

While I don't have a lot of sympathy for these particular companies when they choose stupid names, I do feel for tech vendors that seize on unintentionally silly or embarrassing names for their companies or products. Here are a few examples:

• Tsunami regularly appears, for reasons that escape me. Why would you choose a natural disaster as a moniker? Undeterred, companies continue to do it, including one enterprise software company that shall remain nameless, who chose it as a code name for a project not long before the 2004 tsunami killed approximately 230,000 people.
• Another recurring name is Rolling Thunder. It might make you think of an Apache warrior, but it's actually the code name for a human disaster, the failed US bombing campaign against North Vietnam. (Again with the Vietnam War!)
• Small companies seem to be especially prone to bad name choices, such as Gianus, Ebone, Wayne Kerr Electronics, Bookgoo, ISOARS Web Design, and ExchangeP.
• For every bad company name, there are 10 bad product names, such as iSmell, TheGIMP, Vergatorio (look it up), LappyMats, Popuload, and the Tonium Pacemaker (not what you think it is).
• And if you're not careful, your innocent-sounding name may make a disastrous URL. 

While these names are funny, they're also sad. People stake their careers on catchy branding, or they sink their life's savings into a business venture. And then, someone points out that your life's work is named Phartronics.

The moral of the story is, the technology business is like any business. The problem isn't that some people are so stupid that they should not be given naming authority, but that, unchecked we all have the capacity for stupidity. We all have our blind spots, and we all commit the occasional brain fart.

Pack a bunch of very smart people into a room, and they'll come up with something—a company name, a new product, the next market to pursue—that makes complete sense to them. However great that Big Idea seems, someone needs to do a reality check before committing a very costly mistake.

How an ISV uses "inbound" social media

In this week's Heretech podcast, I spoke with Alex Bender of Archer Technologies about the role the Archer community plays in the development process, all the way through the release. If you click the thumbnail shown here, you'll see their process in graphic detail. While Alex and I didn't get into all the specifics of how they do it, we did cover most of their "social product management" approach in the podcast.

Among other interesting aspects of how they use their community as a resource for innovation and adoption, the role of partners really stands out. Of course, in the governance, risk, and compliance (GRC) space, you have an ecology of partners who are experts in things like Sarbanes-Oxley and risk management best practices. They'll tell you in plenty of detail why your product isn't really doing the job it should as a GRC tool.

GRC implementers and advisers have a very explicit kind of domain knowledge. However, if you stop to think about it, almost any partner has domain knowledge that's valuable to ISVs. To cite an obvious example, how does the average organization implementing your technology define the project? What obstacles do you impose at the critical landmarks in the implementation?

We usually talk about communities as consisting of customers. However, I think it's worth including partners whenever you talk about your community strategy.

The PM playlist

Forrester colleague Oliver Young left last week to join Jive as a product manager. Oliver is a big music fan with eclectic tastes, so I thought I'd put together, in his honor, the product management/marketing playlist. If you were to make a musical version of what it's like to be a tech PM, here's what you'd put into the soundtrack. (Suggestions for additions welcome.)

Why these songs?

• "Build Me Up, Buttercup," The Foundations. The job is, at the end of the day, making sure that your company is building something of value.
• "If You Could Read My Mind," Gordon Lightfoot. Unfortunately, what defines value is pretty elusive. Figuring out what people really want is one of the trickiest parts of the job.
• "Quality Shoe," Mark Knopfler. Often, what they want is a lot simpler than what people in the development team assume. It's always safest to start with the basics.
• "Human," The Pretenders. In PM, you'll spend a lot of time talking about technology, in technological terms (features, supported platforms, bugs, integrations, builds, etc.). You need to be on top of these details, but you also need to keep enough perspective on the human elements of technology adoption. (And if you're not keeping an eye on both the technology and business factors, who is?)
• "I Need Some Money," John Lee Hooker. At the end of the day, though, you're building something of value for both you and the customer. Can your company make money, based on this idea? (By idea, I mean something as big as a product, or as small as a minor feature.)
• "On The Road Again," Canned Heat. Then you have to translate this value, for the customer and your company, into a roadmap that benefits both parties.
• "No Phone," Cake. As you march down this roadmap, you're going to face a lot of conflicting priorities, unexpected twists of fate, and other distractions. Still, you need to keep your wits about you, which often means you can't be as available to everyone who wants your time as they'd like.
• "Who Are You," The Who. You're also going to face a lot of confusion about your job description. What does PM do, anyway? If you don't take the initiative and define it clearly for them, other people will define your job for you.
• "Video Killed The Radio Star," The Buggles. Technology shifts are tricky to predict, and everyone wants to be at the center of these changes. You're going to have to decide how your company can best strike the balance between visionary possibilities and prosaic realities.
• "I Won't Back Down," Tom Petty. Your job as PM is, in large part, to remove a lot of this chaos and uncertainty. Your best tool in your arsenal are the facts. You're paid to have an expert opinion about markets, customers, competitors, technology trends, and other forces that shape your company's destiny. You are not paid to have just another opinion.
• "All You Ever Wanted," The Black Keys. Roadmaps will change. Projects will get new priorities. Some messaging will fail. Customers will disappoint you. Obviously, you need to be flexible, but you also need to keep the same destination in sight: Building something people want, and will make your company money to provide it.
• "Complicated Situation," Black Rebel Motorcycle Club. You're going to have to deliver bad news. Some stakeholder's pet idea won't pan out. A customer's bug is going to take longer than expected to fix. The big new market will prove to be a mirage. Deal with it.
• "Under Pressure," Queen with David Bowie. If you don't like these kinds of challenges, then PM isn't the job for you.
• "Working In The Coal Mine," Lee Dorsey. And yes, it's a lot of work. Frequently, you won't always be able to predict what the work will look like for the rest of the day, week, or month.
• "Three Little Birds," Bob Marley. But, as Bob Marley says, "Every little thing is going to be all right." Not every prospect is going to buy your technology. Dates slip, but not into infinity. You'll get bad, unfair press. You'll lose internal arguments. Good PMs know how to dust themselves off and move to the next task.

[Cross-posted at The Forrester product management blog.]

Hot off the presses: wargames, PM in the recession

Two of my research documents just went live on the Forrester web site:

• Wargaming for business leaders. Not the same as the kind of serious gaming that colleague TJ Keitt and I have discussed before, wargames are a more structured exercise that try to simulate possible business outcomes. The output is different than serious games, role-playing exercises, and other game-like tools. For example, in many cases, the goal is to help make smarter company-level decisions, not just product-level ones.

• Product management/marketing during the recession. A very short document that points to other research that we've done about the recesssion, and then puts it into context for PMs. What changes do PMs need to make in product strategy and positioning? Which markets are likely to bounce back first, and what do you need to know about them?

Product owner or product manager?

During yesterday's interview with Steve Johnson for the podcast, Steve gave an account of the panel at Agile 2009 that tried heroically to draw the line between product manager and product owner, but didn't reach a consensus answer. Today, I spotted this blog post about what it means to be a product owner. Even if this were the definitive job description for product owner, you still wouldn't be able to guess exactly where this job differs from product management.

By the way, if you have access to Forrester's research, here's the study I did last year on this topic. As I said during the interview with Steve, I thought it would be a bit of a lark. Instead, it turned into a real puzzler, trying to find the organizational algorithms that technology companies used to develop a variety of different PO/PM formulas. They're the same! They're different! They're different levels of seniority! They're the same! And so on.

Best practices for PM leaders

A few weeks ago, I mentioned that I had done some very interesting research on best practices for the people who run product management and product marketing organizations. Since we did the research for the Forrester Leadership Board (FLB) for that role, we couldn't share the final results beyond the FLB members themselves.

Good news: we have an excerpt available at this link (registration required to access it). We've anonymized the people we profiled, but their names and companies aren't the important details.

By choosing highly successful heads of PM teams, we got a glimpse into the future of PM. The thumbnail sketch of that picture: the profession is getting more clearly defined, because it is increasingly strategic. The PM role is making simultaneous progress as a profession, art, discipline, and the group with the broadest and deepest insight into the state of the overall business.

Big thanks to Steve Davidson for doing a lot of the work that made this excerpt possible. Steve is runs the FLB program for Technology Product Management (TPM) professionals.

[Cross-posted at The Forrester product management blog.]

Listening is hard

Both product managers and product marketers have to be top-notch professional listeners. Among other consumers of the insights that come from listening, the development team depends on product management to be the conduit of useful information from the outside world. Arguably,  listening to users, stakeholders, partners, and other "outsiders" is the supreme skill among skills for PM. If you fail to listen, every other PM responsibility falls apart.

Unfortunately, for professionals on the move, listening is inherently hard. There's always the next appointment, the urgent e-mail, the distractions from what you're doing right here, right now. To compound matters, there's the company's own agenda, or your personal agenda, that interferes with your listening ability. The mental HUD that overlays your conversations with customers puts bright and flashing circles around the statements you want to hear.

But don't feel too bad. Everyone struggles to be a good listener. In a Fresh Air interview this week, Lisa Sanders, who just wrote a book about the alarmingly high frequency of medical misdiagnosis, cited a study that found that doctors wait an average of only 20 seconds before they interrupt their patients' account of their symptoms. Even when the stakes are, quite literally, life and death, doctors can't shut up long enough to hear all the important details, even though any particular detail might be critical for the diagnosis.

Product managers and product marketers also struggle to listen. For instance, you might pay attention just long enough to hear an IT person say that your boffo collaboration tool should help them solve a particular problem. Unfortunately, for psychological and organizational reasons, you might overlook the critical qualifier, should.

For the same reasons, when the IT person starts talking about some of the obstacles they've faced when rolling out collaboration tools, you might jump immediately to the 101 sure-fire ways to  overcome these obstacles. Swallow those suggestions. At this point, your job is just to listen carefully, and to think about the other people in this organization, beyond IT, you might also need to hear—you know, the people who are actually using your tool, and not just implementing it.

Companies compete, products don't

Adam Bullied's recent post about competitive analysis is really good, but it's missing an essential point that technology companies frequently overlook: Companies compete, products don't.

That's not the same as saying that product comparisons are worthless. Of course it makes a difference that Product A can do more than Product B, as long as Vendor A and Vendor B are in the same market. Often, because of the complexity of the market, as well as its immaturity, technology vendors overlook the second part of that principle.

Similar products may not ever bump into each other because of accidents of geography. Ichitaro, the big competitor to Microsoft Word in Japan, has practically no international market. At other times, analogous products burrow into particular vertical niches so deeply that they never see each other. The specialized document management products you still find in the biotech, financial services, and legal markets theoretically could compete with one another, but don't.

Of course, a potential competitor might become an actual one, jumping across geographical or vertical boundaries. However, even if that were to happen, two companies in the same business might have radically different business models, in which case, the competition between them may be more apparent than real. For example, Singularity certainly has products to support Agile development, but they also do a brisk business in selling consulting and training.  (Their Agile approach to BPM is particularly interesting.) In contrast, VersionOne is more of a product company. Both are trying to serve Agile product teams, but to what degree do they really compete?

A competitive analysis that doesn't include the details about the competitors has very limited value. The real threat may be the vendor that has a weaker product, but has a greater ability to market and sell to your customer base. What profiteth a vendor that builds a superior product, but loses its market?

Immersion therapy

Friend-of-the-blog Adam Bullied has a great article on "industry immersion" in the latest issue of Pragmatic Marketing's magazine. The follow-up article should be, "Getting your company to give you the time needed, and reward you for doing a good job of it."

Follow that man!

If you're not following anyone on Twitter yet, and you're interested in product management and product marketing, start with Jim Holland (@Jim_Holland). For PM issues, he's the most active Twitterite on PM issues, and he's a good pointer to other PM-related Twitter activity.

Plus, there are a couple of tags, #pmv and #prodmgmt, that help you pinpoint tweets of interest.

Oh captain, my captain

Christopher Cummings agrees with Saeed Khan's assertion that the product manager is not the CEO. Saeed's original post is here. We also discuss this topic in this week's podcast.

CC proposes an alternative metaphor, captain, that may be marginally better than CEO, but not ideal. (He admits as much at the end.) At the very least, claiming captaincy is, politically speaking, more than a little dangerous. The product manager plays an increasingly strategic role in technology companies. However, self-coronation as captain, CEO, squad leader, capo, or anything similar invites backlash.

Primus inter pares? I'd only think of using that term because not everyone speaks Latin. Still, they could look it up, and claiming to be first among equals might also sound a bit insulting. Best to say that you have your domain, and I have mine. Sort of like the two different consuls in the Roman republic, which is more obscure than a commonly-used Latin phrase, and that much safer.

You're a PM poopyhead

Jim Holland draws some lessons for PMs from participating in a kindergarten class. I'll add one more similarity between PM and K-12 teaching: don't take the job unless, up front, the institution is ready to back your authority.

Product management and marketing mix it up

For people in product management and product marketing, organizational questions—for example, Where should we report? What specializations of the PM role seem to work?—are always high on the list of hot topics. That statement is true of this week's Heretech podcast, to be posted later today, in which Saeed Khan and I spend a good deal of the interview discussing these issues. It's also true of the research that I do, including a recent study that revealed some interesting results about the relationship between product management and product marketing.

A small chapter in a bigger story
Unfortunately, this latest research about these organizational questions puts me in a bit of a bind, since I'd like to share more of the results than I can.  Forrester always requires you to be a client to access our research, with minor exceptions. In the case of the just-finished study, "Best Practices For Product Management And Product Marketing Leaders," I'm really constrained. Members of the Forrester Leadership Board (FLB) for PMs asked us to do this study, which gets circulated among the FLB members, but not all Forrester clients. (It's one of the perks of FLB membership.) If there's a curtain between the general public and the typical Forrester research, there's yet another one between you, Dear Reader, and the FLB research.

Fortunately, we can always share a little bit of information from our research, even if we can't share everything. In this case, I'll share what we learned about one important organizational question: Should product managers and product marketers be part of the same department? Looking at successful PM teams, the answer is, Generally, yes.

What makes a successful team?
For this research, we deliberately picked successful PM leaders for our interviews. The adjective successful could mean a lot of things, and in our case, it meant...

• Tenure. The PM department heads whom we interviewed have been doing the job for at least a few years.

• Authority. These PM leaders handle important deliverables and activities, such as go-to-market strategy and product portfolio management.

• Accountability.  Along with real decision-making power over matters like product strategy, these PM groups bear responsibility for the business outcomes of these decisions.

In other words, you know you're successful when the company entrusts you with important things.

One group or two?
Since I started doing research on product management and product marketing, I've seen a lot of different organizational formulas. Sometimes, these two groups are separate. At other times, they're two sides of the same group. I've also seen these job functions broken down further, with the pieces scattered even more widely around the organization. We've also spoken with groups that have introduced new roles, such as solutions manager and community manager, that overlap with the product management and product marketing functions.

Therefore, when we reviewed our interviews for "Best Practices For Product Management And Product Marketing Leaders," we were genuinely surprised to discover that approximately 80% of our interviewees ran departments that combined product management and product marketing. That's a result worth italicizing.

These arrangements made sense, since product people look to the same information about business problems, use cases, personas, competitors, and other aspects of the market. This knowledge guides everything from broad-brush messaging to nitpicky feature/function priorities.

Of course, separating product managers and product marketers also makes sense. However, the habits of these highly successful PM leaders strongly imply that the unified department not only makes sense, but also works. There are lots of reasons why, including both external and internal ones. For example, if you're going to produce different content for different audiences—requirements for Development, demos for Marketing and Sales—that's ultimately based on the same customer and product knowledge, that process goes a lot more smoothly when you don't have two separate groups trying to stay in sync.

Two jobs, but what do you call the one department?
The success of the unified product management/product marketing model makes me wonder if there's a a good umbrella term for both of them. "Product professionals" doesn't quite do it for me, and we definitely don't want to confuse the two distinct functions, even if they wind up under the same management. I'm certainly open to suggestions.

[Cross-posted at The Forrester product management blog.]

Living in an Agile world

This short e-book by Steve Johnson, Rich Mironov, and Luke Hohmann nicely summarizes the issues for PM when the development team goes Agile.

The cringeworthy list

Stewart Rogers has started a list of words and phrases that make PMs cringe. I'm sure that you, Dear Reader, have at least one to add.

Making a SaaS of yourself

A recent post at SaaS University ("Where CEOs Go For SaaS Higher Learning") argues that SaaS companies don't need product managers. Here's a quick summary of the argument.

• Product managers maintain the prioritized list of features.
• SaaS applications can ask the users to vote, within the application, on what features they want.
• Therefore, product managers aren't needed.

This argument is based on such a rich smorgasbord of fallacies that it's hard to decide where to start. I'll just elbow my way into the buffet line of bad assumptions at the point where the features are spread out on the table, waiting for people to select the juiciest among them. Here's how Rick Chapman, the author of this post, depicts the process of defining and prioritizing features:

The tick list is traditionally gathered from the product manager's imagination, development's imagination, the CEO's imagination, competitive analysis, press reviews, and, most importantly (and often only theoretically) from user requests.  It is the job of the PM to collate these new features, prioritize them, and fight (persuade) development that the PM is accurately reflecting the wishes of the customer in terms of the added functionality needed by the next version of the product.

Which begs the question, How do you figure out if you're "accurately reflecting the wishes of the customer" if everything runs on autopilot? Letting customers vote on features is important, but it's no substitute for understanding what customers really need, or who among them you should heed.

Making yourself clear
Say you propose Feature A. The one-line summary reads, "Streamline the process of imanetizing the eschaton." Now, assuming that your customers understand what the eschaton is, even if they're using it every day in your SaaS application, you're still hardly giving them enough information to know what streamlining really means. Are you proposing to cut down the number of clicks needed to get through the imanetizing process? Make it easier to learn how to use the imanetization management features in your SaaS application? Make the application run faster?

Crafting a good design
If you think that I'm being unfair by making the original feature proposal too vague, let's assume for the moment that the customers completely understand the importance of this feature. How then do you decide what the design constraints are? What might seem, to the developer writing the code, like the best eschaton-imanetizing feature ever conceived, might turn out to be baffling to the end user, or perhaps not all that helpful. Without any clear sense of the use case, the business problem, and the user, you're as likely to make bad design decisions as good ones.

Listening to the right people
But let's even put that risk aside for the moment, and focus instead on the voting process. The people doing the actual eschaton imanetization might have very strong feelings about the need for streamlining it. Unfortunately, these users may also have no impact on the business success of your SaaS application. For every 10 end users, there may be 1 manager that wants a new report instead of the streamlined imanetization. The manager may be the one who makes the buying decisions, and may be royally POed if you don't give them what they want, even if they're in the minority of voters.

Going after a bigger market
And what about market development? Our hypothetical SaaS vendor has already attracted a particular kind of company--say, medium-sized eschaton brokerage firms in the continental United States. But is that the ultimate market that you, the SaaS vendor, want to reach? By following the direct feedback of current customers, you may be missing the features that are important for the next market you want to enter, where neither streamlined imanetization or improved reporting may be the cost of entry.

Letting PM focus on the customers
As startlingly naive as this view of enhancement requests might be, the bigger error of this post is its conflation of bad product management with all product management. Here's how Chapman describes the role of PMs as voices of the customer:

PMs are traditionally supposed to spend a great deal of time with customers learning what they like and don't like about the product they're responsible for. The reality is that in most companies, most PMs learn a great deal about how to manage a tick list, communicate the tick list, prioritize the tick list, fight for the tick list, write the MRD, revise the MRD, examine the PRD, fight about the PRD, etc., etc. This doesn't leave much time to spend with customers.

The companies in which Chapman worked may not have granted PMs the time to research customer use cases, market characteristics, buying behaviors, and other critical topics. However, that's hardly true of all technology companies.

For example, in the soon-to-be-published Forrester Leadership Board on product management best practices, a VP of product management describes how he writes time spent with customers into every PMs quarterly goals. Other PMs I've interviewed since taking this job as an analyst have similar stories to tell. Either they have taken the initiative to protect the time needed for their research, or their management has made it a bigger priority, fearing the bad consequences of misguided product decisions. Chapman's argument smacks of, "Well, we've never given the PMs the chance to do the most important part of their jobs, so we'll just get rid of them altogether."

Understanding PM's to-do list
Maintaining the prioritized feature list is hardly the only thing PMs do. The list of tasks that PMs perform may vary across companies, but it's always a big list. Sales and marketing support, training, release management, customer reference recruitment, social media outreach, press and analyst briefings, release management--someone has to do these sorts of tasks.

I might have my disagreements with particular approaches to teaching product management. However, Pragmatic Marketing, AIPMM, et al. don't limit their description of product management to "the tick list."

Since Chapman begins his post with the statement, "If you're a SaaS company with product managers and are considering sending your PMs to one of these courses, I wouldn't bother," it makes me wonder how much he really knows about these organizations, or the curricula they present. Nevertheless, even if these outlets for PM training were to prove completely worthless, that's not the same as saying that product management is worthless, too.

[Postscript: The role of PM does change in SaaS organizations, but it hardly disappears. If you're a Forrester client, you can read the complete report on what PMs actually do in SaaS companies here.]

These aren't the sales droids you're looking for

I especially enjoyed this post at The Cranky Product Manager, having experienced a similar bait-and-switch with Sales in a previous job. Plus, the description of the CEO is hilarious:

So, the CEO calls the Cranky Product Manager into his office.  After complimenting her hair and the way her jeans fit, asking her if she is still happily married, and trying to give her a George-W-style shoulder rub,  The Big Boss tells her to drop the price to the one the Droids are begging for.

Innovation's moment of truth

You just got out of the meeting with potential customers, and they're not big fans of your Big Idea. You were sure it was brilliant, but they just don't get it. Or they applaud the effort, but they think you're going approaching it from the wrong angle.

Here's the moment of truth when many projects go bad, and sometimes drag companies down with them. The crisis isn't unique to the technology industry--there's the cautionary tale of New Coke, after all, from a well-established industry that should have known better--but given the immaturity of the technology industry, and the plasticity of the work product, it happens quite often.

At this moment of truth, development teams choose from among the following responses:

• "These people are idiots. Let's go."
• "They're not idiots, but they're not our market. Let's keep setting meetings until we find people who can appreciate what we're trying to do."
• "Maybe if we talk more, they'll finally get it."
• "Maybe we didn't put enough into the first version. Let's go back and see what enhancements will make the product more appealing."
• "We've committed too much into this project to stop now. Forward! We'll work out the sales and marketing later."
• "Maybe we had a good idea, but we went about it the wrong way."
• "Maybe there isn't the market for this idea."

Adam Smith, meet Sigmund Freud and Niccolo Machiavelli
At moments like this, we can see why the simplistic economic model of the firm as a unified, rational actor makes zero sense. All of these responses might be the correct one. A rational,  unified actor should select among them impartially, based on their inherent risks and rewards. For example, if there really isn't a market for the idea, the consequences are dire. (If you were a game theorist, you'd work as hard as possible to prevent this kind of "nuclear option," even if the risks were low.)

Unfortunately, companies are not rational, nor are they unified. People have strong emotional attachments to their ideas, the people with whom they work, and the work itself. They also worry about the politics within their organization. For example, what happens to your reputation as a Wunderkind if your latest great idea turns out to be a flop? And what will the investors, or Management, think?

Market test early and often
This is exactly when the organization needs professional product management and product marketing, as long as you're serious about getting someone's honest assessment. Is the problem with the invention itself? If so, you need someone who can do an objective, credible appraisal of the problem, if it exists, with the product. Is the problem with your explanation of its value? If so, it's critical now to address that problem quickly and professionally, if you're going to build any market momentum, pre- and post-launch.

Inventors need product management and product marketing as early as possible. Unfortunately, in the history of the technology industry, that scenario doesn't happen as often as it should. Companies commit people and resources to an idea before it gets real market testing, or even a clear picture of who's going to use it, who's going to buy it, and why.

Innovation is more than just inspiration
Innovation--the art and science of converting inspiration into adoption--doesn't really start until someone performs these tasks. Therefore, the moment of truth depends on admitting the possibility that you don't know your target market as well as you should.

When the market feedback is disappointing, you need to establish some emotional distance from your idea. The invention still may have a bright future, but the consequences of being wrong might be disastrous. If you find yourself looking for reasons why you were right all along, without taking any time to question your ideas, or even the people with whom you're working, then you know you're setting yourself up for failure.

[P.S. If you're looking for other examples of this principle in practice, let's just say that the point is as valid in US foreign policy as it is in the technology industry.]

[Cross-posted at The Forrester product management blog.]

The Kobiyashi Maru test for PMs

I finally got to see the "rebooted" Star Trek this weekend. Among other references to the old Trek, the screenwriters resurrected the Kobiyashi Maru, the infamous no-win test for Starfleet cadets that only James T. Kirk ever "beat." It's a cute aside in the movie, but it got me thinking about (what else?) product management and product marketing.

If you're interviewing a candidate for a PM job (product marketing, product management, or both), the big challenge is gauging that person's interpersonal, organizational, and political skills. For example, can this candidate communicate and persuade a variety of audiences, both internal and external? And, when the going gets really tough, how deftly can the candidate handle PM's own version of the Kobiyashi Maru-like, no-win scenario?

I'm sure that you, Dear Reader, can devise just such a fiendish and instructive test. Please enter your no-win scenario in the Comments section of this post. The author of the best entry gets an all-expense paid trip to the pleasure planet of Risa.

To get the ball rolling, here's an example:

Tomorrow is a key analyst briefing for a brand-new product. The analyst is already skeptical about both your design approach and your company's ability to execute.

You've had a hard time pinning down the one potential reference customer whom you must cite during the briefing. It's mid-afternoon, and you had planned to call your IT contact to get the final details on their experience during the beta program. That information will then go into the slides for the briefing.

Surprise! On the phone is a bigger group than just the IT manager. Also on the phone is a very angry CEO, fuming about how his golfing buddy, your CEO, promised that testing this new product was going to be risk free. Instead, it managed to bring down e-mail and calendar for everyone in their company, effectively bringing their business to a standstill.

This is the first you've heard of any problems with the software, let alone something that goes off like a bomb in their data center. The last your CEO asked about the beta program, your response was, "So far, so good."