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.]

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.]

Homonyms are not rebranding

Since a noteworthy portion of this blog's readership watches something on the network in question, I'll pass along the news that SyFy has made Time's list of 10 worst corporate name changes. It's not as bad as Blackwater's new name, Xe, which sounds like an alien overlord that you might see on the SyFy channel, but it's still pretty stupid.

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.]

Mardi Gras marketing

The Cranky Product Manager is looking for the worst company and product descriptions. Oh, what a rich bounty that will produce. Here's one of her examples:

Microsoft Office SharePoint Server 2007 is an integrated suite of server capabilities that can help improve organizational effectiveness by providing comprehensive content management and enterprise search, accelerating shared business processes, and facilitating information-sharing across boundaries for better business insight. Additionally, this collaboration and content management server provides IT professionals and developers with the platform and tools they need for server administration, application extensibility, and interoperability.

The most obvious problem with this summary is that it's too long to really be a summary. Try giving that elevator pitch in one breath without keeling over from hypoxia.

Where should the editorial chainsaw begin to cut? Certainly, this message should be cut in twain. If people trying to collaborate with each other receive the biggest benefits, then leave out the administrative stuff. If developers and administrators are going to be the happiest with the product, then amputate the end user stuff. You can always get to the additional benefits later.

Even if you cut down the number of sentences, the words in the sentences need improvement, too. If you were to recite this paragraph, as is, to a random stranger, they might think you were a dangerous maniac, rapidly rattling off a string of words whose meaning isn't exactly clear. If you reduce the number of words, congratulations, you've graduated from dangerous maniac to harmless crackpot. (Hmmm, yes, enterprise content management, and sharing across boundaries...Sounds very nice. I'd love to find out what you're talking about, but I think I hear my phone ringing.)

If you've worked in the technology industry, you know exactly how a group of very smart people devise this sort of rococo verbiage. You want to showcase everything that the customer might be able to do with the product, so you cram as many different facets of the product into a paragraph as you can. If the customer likes organizational effectiveness, they're going to love application extensibility!

A good term for this phenomenon is Mardi Gras marketing, which  bedecks your message with as many shiny verbal gewgaws as humanly possible. Of course, the whole point of a Mardi Gras costume is that you're dressing in a tongue-in-cheek, over-the-top fashion that would never work the other 364 days of the year. This is not the sartorial choice you want to make for your next job interview.

If your message starts with what the product can do, there's no logical stopping point in describing it, other than the end of the feature list. Instead, the first thing you should say is something vivid and compelling about the problem the technology addresses, which is the value part of the value proposition. You can get to the features later.

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

Product marketing and massive yachts

I might write a long post about how product marketers often fail to speak the customer's language...Or, I could just post the following skit from That Mitchell and Webb Look that I saw last weekend.

UPDATE: Since posting this video, I now have a yacht dealer as a follower on Twitter. What brave new world.

Beta's marketing focus

April Dunford posted recently about how to incorporate marketing objectives into your beta program strategy. It's a good post, well worth reading, assuming that you're a company that sees betas primarily as product quality exercises (find bugs, get user feedback on design, etc.).

I also know that there are companies who have the reverse problem: they use beta for marketing purposes first. They know that customers get nervous when you don't have any beta, even a pro forma one. However, the bigger marketing goal is reference customers, which presumably pop out of beta programs the same way that flowers might appear after a rain storm. 

In some cases, these companies have good relationships with a few customers who always have something good to say about the company. Even if the customer didn't actually give the beta version a good thrashing, they're willing to say something like, "We give a thumbs up to the product direction that we see in the next version." Beta, in this context, is a set of talking points for case studies, press releases, and other marketing materials developed for the launch.

If this is your company's way of handling beta programs, someone needs to be fired. On the product quality front, betas really do have value. Even the best QA team can't achieve the level of real-world testing that customers provide.

Even if you're not concerned about product quality, any company that treats beta programs in this fashion is taking two gigantic marketing risks:

• Ceding an ever-increasing amount of leverage to a small group of customers. Your go-to reference customers aren't stupid. They know that there's a quid pro quo, and they'll expect to be able to call in favors at some point. These acts of reciprocal kindness might take forms that damage your business, such as the prioritization of features that no other customer really wants.
• Confining yourself to a small market. What happens when you need a reference customer in the public sector, but all your go-to reference customers are in financial services? Or, what if you want to expand your portfolio, but none of the familiar reference customers are willing to recommend your ability to deliver value in a whole new technology area?

If reference customers are the flowers you want to prosper in your marketing garden, you'll have to suck up the amount of work it's going to take to cultivate them. Beta programs are one important step in the cultivation process, but the work is really ongoing—as your relationship with any reference customer should be.

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

Please take the Forrester Marketing Budgets 2010 survey

My Forrester colleague Laura Ramos is looking for tech industry marketing professionals to participate in a survey about their company's marketing budgets. If you fit the profile, here's the direct link to the survey.

The limited lifespan of many component technologies

As anyone who has worked on component technologies can tell you, the time in which you should treat your product as something that can stand on its own is limited. The tricky part is figuring out when that transition should occur—and that's where people in product marketing and product management can really earn their paychecks.

"Just give me what I want, even if I don't know what I want"
Collaboration-ish, social media-esque technologies will reach that point. But is it here yet? One company in this business, Jive, seems to think so. Their Social Business Software (SBS) suite bundles discussions, social tagging, blogs, and other capabilities in what used to be a smorgasbord of capabilities. Pass down the line and fill your plate with whatever components you want to consume.

Of course, this model presupposes that you know what you want. Unlike Swedish meatballs and macaroni salad, you may not know your own taste for dashboards, polls, and document collaboration, which may be as mysterious to some users as the menu at an Eritrean restaurant's lunch buffet. And if you can't decode the menu for yourself, you certainly can't be trusted to pick out the right components for other people.

That's the cue for some companies to switch their product strategy and marketing approach from products to solutions. Instead of the befuddling list of 100 items, just package related components into the Meat Lover's Special, or in the case of Jive, "solution architectures" like Employee Engagement.

"Give it to me when I want it, even if I can't tell you when that will be"
Without giving a thumbs up or down on Jive's specific approach, they provide a good example of how important this timing issue can be. If Jive were to wait too long with a solutions strategy, the market might pass them by. Competitors with inferior products might do a better job of explaining how to use them, which will attract users and customers like iron filings to a magnet.

On the other hand, Jive might jump too early into the solutions business, with tragic results. When you start thinking less about generic technology, and more about specific use cases, you make product roadmap and feature design decisions much differently. For example, if you want to capture the medical records market, you can't just build a generic approach to roles and privileges. You have to design access control lists and other security components in a way that will serve how practitioners and patients share information with insurance companies.

Unfortunately, back when HIPAA first started getting momentum, some companies tried to steal a march on their competitors, but they marched swiftly in the wrong direction. As it turns out, there wasn't a single correct way to conform with HIPAA privacy guidelines; instead, organizations had the latitude to figure out the HIPAA puzzle in their own ways. Instead of bringing to market a one-size-fits-all "HIPAA solution," these vendors had built themselves a one-size-fits-none straitjacket. Oops.

"In other words, your job depends on reading my mind"
Product marketers and product managers, therefore, are a key resource in technology companies for seeing over this horizon. Is the technology well-enough understood, and widely-enough adopted, that the shift to a solutions strategy is imminent? If so, which among several different solutions is the one that will generate the most business?

These are questions with huge ramifications, beyond just next quarter's sales. For example, a small company that has done a great job building a best-in-class component technology may be ripe for acquisition. Or, it may be kidding itself about the possibility of finding a buyer, if bigger companies don't see the kinds of solutions into which these components will fit.

Clearly, a group of smart people sitting around a conference table aren't going to reach the ultimate answers. Research into a combination of technical and business issues will be necessary--which, again, is the raison d'etre of the PM team.

[By the way, this week's podcast, to be posted soon, features an interview with Mike Marfise of Jive. We don't talk about this particular issue, but Mike has a lot of interesting things to say about a particular solution area, innovation.]

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.]

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 (mversen@forrester.com) 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.

Sometimes, you measure commitment by the hour

During a breakfast meeting this morning, someone asked a very sharp question: Are businesses really operating differently because of social media? I then jumped in the car, drove from San Francisco back to our Foster City office, and heard how Cisco has used social media to change product launches.

The obvious change, of course, is lowering the cost, if you're not renting out the Moscone Center for a big launch party. Slightly less obvious changes include the ability to reach more people in more countries. , the virtual launch also makes it possible to reach more people, in more countries, than Cisco could with traditional face-to-face events.

So far, we're just considering changes in capability. Doing product launches cheaper, faster, better is an important innovation, but it's not a sign that a company is operating or thinking in a significantly different way. You might buy a cheaper, better, and faster car, but you might not change your driving habits one bit, or take more care to follow the traffic laws.

Therefore, during this conversation with Cisco, the one change from going to virtual product launches that really stuck out was operational: the marketing effort continues beyond the big ballyhoo day. Cisco employees remain engaged in conversations with customers through social media channels.

Contrast that with the old Moscone Center-style launch events. Everyone shows up for the big photo op, and then they go home. Sure, leads get entered into the CRM system, but that's hardly the same as continuing a conversation with the people you met at the launch event.

Of course, that means that some people at Cisco have to dedicate time to that continued conversation, instead of racing off to the next big launch event. There's a business decision behind allocating resources in this fashion, based on a different set of assumptions and calculations than the "marketer with a megaphone" launch events of 15 or 20 years ago.

Are social media for real? Yes, when they effect how companies operate.

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

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.

I heart BPM modeling tools

No, I don't really love BPM modeling tools. I doubt that anyone does. If you're the exception, by all means, speak up, I'd love to meet you. Maybe we could talk about how long it has been since you had a vacation.

As April Dunford argues, technology doesn't have to be exciting to be useful, or even attractive for people to buy: 

I'm not saying that it's impossible to have successful products without inspiring people.  It's possible and I know it because I've done it.  I launched a product that generated $80 million in its first year that was as dull as paint and I couldn't find a single reference to it online outside of our own website.  It did useful yet really boring thing very well at a time when no other product did so people paid money for it.  I don't think believe that's changed and there will always be some markets where sheer utility works.

Sheer utility does have its own coolness factor, though. Exhibit A is the Eclipse IDE. For a lot of developers, once you start using Eclipse, you don't want to change, regardless of what competitive IDE your new employer has made standard in the development team. Ditto for people who graduated from computer science programs with an attachment with Vi and Emacs.

On the consumer side, sheer utility also has its appeal. Just visit your local hardware store this weekend to see how people can develop a passionate attachment for something as unlovely to the eye as a compound miter saw.  (I admit, I'm one of those people. I'm just like Hank Hill, but without the competence.)

Sure, there are pieces of technology that can arouse people's passions. But, if I forbid you to mention any Apple product, how many examples can you think of?

In fact, efforts to wow people with flashy UIs often fall flat on their faces.  For example, at bottom, users seem to want a webmail client that just makes it easy to write, read, file, and delete e-mail. Efforts to jazz up the web UI with Ajax- or Flash-based eye candy don't seem to make people fall in love with their e-mail client. E-mail is a necessity, just like your last visit to the DMV. Interesting architecture and expensive wallpaper won't make you want to hang around the DMV any longer than is necessary to renew your driver's license.

In fact, it might be worth pursuing the idea that "sheer utility" is, on average, the most important factor in adoption. Now, if you'll excuse me, I have to get back to importing some BPEL-based workflow templates.

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 (mversen@forrester.com, 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 (tgrant@forrester.com, 650.581.3846).

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

Workshop on "social product management" is done!

Had some great conversations with the workshop attendees on how PM teams are incorporating social media into their customer and market intelligence (including, but not limited to, requirements). Thanks to all who attended.

Interestingly, we spent a good deal of time talking about the type of questions people ask. In trying to make sense of both social media and PM deliverables, I made a distinction between problem-centric questions, which center on the customer, and product-centric questions, which (as the name implies) focus on the vendor's products and services.

In the technology industry, people are far more used to posing product-centric questions. Gradually, companies are learning the importance of the problem-related questions. However, it's easy to slip from one into the other. It reminds me of how I used to struggle with guitar fingering. As a novice player, I would concentrate for a while on keeping my fingers straight on the frets. Inevitably, as I started to think about other things (strumming, rhythm, etc.), I'd start to roll my fingers slightly to the side, which made it harder to hit the notes I was trying to reach.

Problem-centric questions are a lot like good fingering: it takes time, experience, and discipline to reach the point when you shake free of the bad habits. Obviously, there's a time and a place for product-centric questions, but not every time.

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

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.]

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.

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.

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?

Polishing the Chrome

This weekend, I saw two commercials for Google Chrome, one on regular live TV (during the bizarre Packers/Bears season opener), and the other during some Internet-based TV watching (yes, I'm one of those mutants who actually watches a fair amount of broadcast content through my browser). Clearly, Google is spending a sizable amount of money to promote the Chrome browser.

There's a temptation to leap to a conclusion that, because a company spends major coin promoting a product, it's therefore taking it seriously. (Why else would it spend money on promoting it?) However, Google takes many other products seriously, such as Google Apps and Gmail, which are pitched at a consumer audience, too.

Unlike these siblings in Google's product portfolio, Chrome is a platform, not just an application. The whole reason Google built Chrome was to run Web applications better, including, obviously, Google's own applications.

But how convincing will this advertising be? Clearly, the Thurber-esque cartoon characters in the ad won't change what IT departments put into officially approved desktop images. Corporate or government decision-making about which browser people should be using has nothing to do with cute advertising, or even Google's image as an innovator.

However, what gets included by default on the desktop is a major part of the story of how Microsoft beat Netscape. People didn't flock to Internet Explorer because it was more cool, or even more fun to use. Nor did IE win because it cleaved to standards better, or even had greater usability than Navigator. At a particular point in time, IE may have been a better browser, according to some measures (say, speed), but that's not necessarily the reason why users choose Hamburger B over Hamburger A.

Microsoft won because it got more people to use its browser. While that might sound tautological--they got more people to adopt IE by getting more people to use it--it's not. Microsoft might have found clever ways to get people to try a browser, but they don't necessarily convince someone to keep using it. Instead, Microsoft made IE appear as if it were a natural part of the desktop application experience, by being bundled with the operating system, and being the default browser for its ubiquitous Office applications.

That implies a different path to make Google Chrome a success than advertising. Still, it can't hurt to increase awareness of the Chrome option, since most people haven't heard that Google has a browser. The next step, going to the Chrome part of Google's web presence, isn't necessarily a deal-clincher. Most people aren't going to read the "Why we built it" page all the way through, let alone make it the decisive argument for switching browsers (something the average person doesn't do very often). The entries on the feature page, such as "dynamic tabs" and "simpler downloads," are a mixed bag of capabilities that the average user might find attractive, and others that the average consumer might not even understand.

Which is all a long, roundabout way of saying, if Google wants to break out of the niche of "interesting new browser option," advertising might be a sign of seriousness, but not necessarily success. There's a long way to go from 1-2% of the browser market share to IE's 78%.

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?

That was the week that was, part 2

The other big project this week was a detailed analysis of a company's corporate and product marketing. We have a specific methodology, called a Vendor Positioning Review (VPR), that measures the ability of a company's publicly-available marketing materials to speak to both technical and business audiences. We also assess the connections (or lack thereof) between the corporate and product marketing content. We put these details into a tool, and out pops an assessment that suggests some important changes that may be necessary.

The VPR is based on what Forrester calls the IT to BT shift. In this shorthand, IT (information technology) delivers value only if the right combination of business and technical experts, working in tandem, can figure out whether there's any business value in it. BT (business technology) delivers value more quickly, because its creators design and market it to address particular business problems that plague people in particular jobs.

We see the effects of this IT to BT shift all the time. In a way, it's a congratulatory message to the technology industry: "Good for you! You've become an integral part of the lives and work of billions of people!" Unfortunately, that also means that the self-same billions who now rely on this technology have strong opinions about whether or not it works for them, and significant power to determine its purchase and adoption.

Many companies in the technology industry struggle to speak the business user's language. Some of them act like the "freaks and geeks" crowd hanging around the fringes of a high school dance, uncomfortable with talking to anyone outside their circle. Trying to make the astronomy club sound cool might not be worth the effort, particularly if you feel that you're doing fine with the crowd of people who already understand you. (By the way, I was in astronomy club, and it was pretty cool.)

Others might be more aggressive about discussing their favorite arcane pursuits, which may hold no appeal for most other people. Going out to the desert with your buddies, getting blind drunk, and chasing jackrabbits with your three-wheel ATVs might seem awesome to you, but not to the young woman you're trying to impress.

Unfortunately, you do need to explain the value of technology to people who might otherwise not care to hear it, even if it's the most "techie" of all technology. If there are no business benefits, then why should someone spend money on it?

I'll use the JSR-168 portal standard as an example. If you go to the web site of a vendor who supports this standard, chances are you'll find some relevant product marketing materials.  This finely-crafted material might be as gripping as the last season of The Wire...For a purely technical audience. Rarely will you find a statement of business value as straightforward as, If you buy technology that supports this standard, you'll spend less time training people on integration APIs, or maintaining your portal, etc.

And if you still think that the ability to speak in both business and technical terms is unnecessary for your product...Well, I guess you're a happier person than me, since you've probably missed the great economic implosion of the last year or so. Cling to your child-like innocence for as long as you can.

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

Beware of the naked man

Christopher Cummings makes a good argument for skepticism about many overheated claims about social media. You'd think that any overheated claim would inspire skepticism, but that ain't necessarily so.

In fact, you might write a history of the last century's overheated claims that never came to fruition, from Soon we will all be living in the dictatorship of the proletariat to In a generation we'll have permanent colonies on the moon and Mars to Dotcoms have re-written the rules of economics. People hope that the people making these overheated claims are visionaries, not idiots, or just opportunists exploiting the latest enthusiasm. Sometimes, they're actually right.

Obviously, we're going through a hothouse phase in the development of social media, when all kinds of speculation grow like kudzu. Chris takes special issue with the idea that social media will replace most face-to-face connections, or should replace them. For product managers, the risk is relying too much on social media for insights about customers.

Yes, social media done correctly in the PM sphere can help us hear about customer pain points, monitor the competition, and engage key influencers in the marketplace. But it comes at a cost that few seem willing to talk about.

I'll disagree slightly with that statement. Chris' target may be the claim, certainly overheated, that social media will entirely replace the traditional forms of requirements. If that's the case, we're not in disagreement at all. I'm a strong advocate for adding "inbound" social media to the requirements mix--heck, I wrote a three-part series on the topic--but I don't think that new media will elbow the old media out of the picture.

A lot of the traditional requirements sources were just as impersonal as a blog, discussion forum, or social networking site. In fact, they were even more impersonal, and in many cases, even more misleading. If only the specificity about enhancement requests in "I have a customer (IHAC)" e-mails matched their urgency. (If only you could have confidence in the urgency.) If only the enhancements recorded in the bug database were less cryptic.

In fact, if you were to replace the phrase social media with e-mail, you'd get something that a product manager might have written 15 years ago.

Face-to-face contacts aren't all they're cracked up to be, either. They have a very important place in requirements. In fact, they're irreplaceable. Any executive who thinks that you can do product management without face time with real users, buyers, and stakeholders is an idiot. Worse, the executive in question is contributing to the mistakes that cost technology companies time, money, and good will.

But executives are right in pressing for cost-effectiveness in requirements-gathering. If you have the opportunity to get supplementary information at a lower cost, why wouldn't you take it?

The big issue is how requirements gathering via social media should work. It's a new discipline, which is another way of saying, "It's going to take effort, time, and skill to do it right."

Here's one part of the discipline that's critically important: social media habits change by demographic. You certainly can't project your social media habits onto those of car dealers, research scientists, and accountants. By demographic slice, people participate more or less, have different goals, and vary in how much they participate in certain activities (contributing, commenting, collecting, etc.).

Therefore, if your requirements research depends on finding a lot of automotive engineers hanging around Facebook, you're out of luck. They don't "hang around" anywhere, in the physical or the electronic world. An automotive engineer who spent the day exposed to social media would be a major oddball, on the order of the title character of Randy Newman's old song, "Naked Man."

However, automotive engineers do use social media in other ways, so learning the inbound social media discipline is hardly pointless. I can tell you from both personal experience, and observing people trying to make social media work in this capacity, that it's damn hard to do right. But so is spending a day digging through the bug database for all the enhancement requests you've ignored during the last two releases.

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.

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.]

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.

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."

PMs and PFCs

Here's just the sort of diagram that you might find in a book about product management. Or maybe it could be something that the VP of Product Management presents to other groups in the company, to explain the PM team's strategy for understanding customer requirements.

OK, I lied. It's not a diagram from a product management or product marketing presentation. Here's the real version of the diagram, which comes from an article in the Small Wars Journal, the magazine for people in the business of fighting guerrillas and terrorists. The article's title is a bit of a mouthful: Intelligence, Surveillance and Reconnaissance Collection Management in the Brigade Combat Team during COIN: Three Assumptions and Ten "A-Ha!" Moments on the Path to Battlefield Awareness.

It's no accident that you can change a few words in a presentation about fighting IEDs in Iraq and have something that seems like a credible approach to understanding customer requirements. In the early years of the war in Iraq, the US military confronted its failure to fight the varied insurgent groups effectively. Among many, many other problems with the occupation, the military didn't really know much about the insurgents, and had a hard time understanding why Iraqis supported or tolerated them.

Slowly, painfully, military and civilian officials had to admit that conventional military approaches weren't working. The traditional "general's war," such as Operation DESERT STORM in 1991, depended on a top-down approach to intelligence, strategy, and execution. Lower-level commanders, at the company, platoon, or battalion level needed some degree of "local initiative" to make DESERT STORM a success. However, the overall effort fit how the US military was organized, trained, and equipped.

A decade later, American officials had to recognize that the general's war didn't fit the war in Iraq. What was needed, instead, was a "captain's war," in which intelligence, strategy, and execution often flowed from the bottom up. In the new Iraqi battlefield, understanding and monitoring life in a particular Baghdad neighborhood was the key to success--not something you get from a headquarters hundreds of miles away from that neighborhood.

The authors of the article describe changes they had to make to their information management approach that will sound pretty darn familiar to PMs:

As we began to centrally consolidate our IRs from all of our intelligence soldiers who received
them, we saw the need for some sort of organized matrix. So, we put them all into a basic collection plan (ref. FM 34-2) and tried to tie them to the generic priority intelligence requirements (PIR) that we had adopted from the unit we replaced. We inputted these IRs into an
Excel™ spreadsheet and distributed it through e-mail, but soon found out that e-mailing 27 versions of the latest matrix to 200 plus requestors and 50 plus asset managers became impossible to track!

When confronted with the miscommunication resulting from this chaos, we decided to upload the spreadsheet onto an HTML SharePoint Portal (not an FTP folder), as a central depository where everyone could look at what everyone was asking and see what had already been answered. When we decided to do everything online, we quickly realized that we didn’t know
where our own information was, never mind attempting to direct other people to our own products.

They also had to admit that their focus on the competition was far too narrow. The enemy was part of a larger social fabric, as complex as, oh, say, a lot of decision-making processes that B2B marketing people struggle to understand:

Common wisdom-–also doctrine—dictates that if a group of IRs are answered, thereby fulfilling a commander’s PIR, then the commander should be able to take action at the DP tied to the PIR. That is the “magic” of intelligence, surveillance, and reconnaissance (ISR). We had the IRs tasked and we were collecting on PIR but our magic pot refused to boil. We asked ourselves, “Is our Intel section really helping this Brigade’s operations?”

We looked at our priorities of effort, our PIR list, and the first “A Ha!” hit us with, “Hmm, they’re all anti-enemy, but most of our operations are pro-Iraqi.” Additionally, most of the phone calls we get are questions about ‘this local leader’, ‘that entrepreneur’, ‘the other doctor’, ‘the sewage lines’, or a hundred similar issues.

Read the article to find other parallels to life in the technology industry.

At Forrester, we like to talk about the shift from information technology (IT) to business technology (BT). Now that technology is deeply intertwined in how people work, it's no surprise that users demand real value from the technology on which they depend.

Vendors need to change their intelligence, strategy, and execution, to adapt to a changing marketplace. Victory doesn't go to the biggest battalions, or the largest feature list. Therefore, the people at the top of the company have to give their subordinates more "local initiative." The people closest to the target need the authority and resources needed to develop strategy from the bottom up.

Since both product managers and platoon commanders should have no trouble understanding the previous paragraph, it's clear that technology professionals should pay attention to some of the lessons learned from military professionals.

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

Nuts to negative solidarity

Phil Montgomery's recent post, "Hatred Is A Bad Business Driver," is definitely worth reading and taking to heart.  Here's the money quote from Phil's post:

I remember being at Novell in the late 90's and feeling absolute hate emanating towards Microsoft.  This was despite us all using many of their products internally - including Windows - Microsoft has some extremely good products (Excel is a case in point). Novell's hatred of Microsoft caused them to go on an irrational buying binge to assemble products (Wordperfect, DR DOS et al) and compete head-on with Microsoft. As we know, this didn't work - nobody can beat a bigger adversary by attacking them head on.  Hatred created a flawed strategy that led to failure.

Of course you have to observe your competitors carefully. Frequently, you'll need to react to what they're doing. However, that's not the same thing as shadowing their every move.

Tribes go to war
Usually, companies kick off these "Kill [Insert Competitor]" campaigns for internal reasons. They need to rally their organization around an initiative that's easy to understand, and plays to their employees' competitive instincts. The academic term for this behavior is negative solidarity, which all societies, from the most tribal to the most advanced, depend on to some degree to define and maintain their boundaries, and to motivate their members to defend the larger group.

Not surprisingly, negative solidarity is only useful to a point. While it's easy to define whom you're against, what exactly are you for? When the stakes are trivial, such as a soccer game or the Miss Universe competition, rooting for yourself against others seems pretty harmless. When you invade another country to distract the citizenry from the problems within your own borders, negative solidarity gets pretty nasty.

PMs get trampled
Since I've been interviewing product managers and product marketers for Forrester, I've seen a definite pattern. The more these groups focus on the competition to the exclusion of their customers, the weaker the PM group, and the less effective the PMs are in doing their jobs. Here's why:

• Competitors are easy to figure out. For technology companies, the competition is the point of reference in the market most like themselves. Understanding the feature list of a competitor's product is far easier than understanding the behaviors, attitudes, and quirks of users. Competitors are people like you; users live very different lives than software and hardware engineers.
• PMs have less to offer for competitive analysis. That's not to say that there's no value in having someone approach the task of competitive analysis professionally. It's also worth having people who dedicate themselves to staying on top of the market. However, competitive intelligence is relatively easy to collect, and easy for Development and other groups to interpret. Therefore, PMs primarily act as a collector of competitive data, not as an interpreter of what it means.
• Competitors can distract from the problems with your own strategy. Any reasonably clever simian can craft a product strategy based on matching the competition step by step. However, that approach makes two courageous and often dangerous assumptions: (1) The competition is following an intelligent product strategy; (2) However good or bad that strategy is, it works for your company.
• Excessive competitive focus undermines PM's ability to say no. For PMs to craft product strategy, they need to be able to veto ideas that don't contribute to that strategy. When the company gets too fixated on competitors, PMs get into a situation that resembles an argument with a Roomba over the finer points of cleaning your living room: It's programmed to respond to particular cues, impervious to whatever logic you try to apply.

This unhealthy dynamic undermines PMs role in the organization, which is a good measure of how well or poorly the company is responding to its customers.  Competitive analysis is critical, but it's not a replacement for your own company and product strategy.

Postscript
On a personal note, Phil's post caught my eye in part because I worked at a company that tried a "Kill Novell" strategy for a while. The source was the salesforce, which was complaining that they were running into Novell's file management products in their accounts. At one quarterly sales meeting, the salespeople were eager to get as much competitive data, plus our responses to the competitive threat, as we could provide.

Three months later, at the next sales meeting, Novell had disappeared from the radar. Meanwhile, we were the same company, slogging through the same sales process with the same products, and often the same customers.

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

What's your mandate, and who's ready to carry it out?

I've been doing a fascinating set of interviews with the successful heads of product management and product marketing organizations. Since the topic is, "Tell us your best practices," the interviews are the perfect occasion to probe many issues that vex people in this profession.

Whenever we got to the part about running a PM team, I inserted a question about the type of person who makes a good product manager. As seen in some of the research I did last year, product managers come to the profession from a motley collection of previous jobs. (No surprise there.)

However, it's clear from these interviews that the people who run PM departments are pretty unhappy with this state of affairs. Frequently, they've taken deliberate steps to fix it.  Sometimes, this means an agonizing reappraisal of whether the people in the team today have all the skills and experiences they really need.

Of course, that presumes the senior directors and heads of PM organizations have a clear mandate, which then implies a certain kind of person capable of doing the job. There's more clarity about the job than I had expected to find. Perhaps that's why these people are successful in the first place: they and their company have arrived at a specific set of responsibilities and deliverables, instead of a murky concept of PM like, "Go be a champion for your product."

[It's Friday, it's sunny out, so I'll stop there, for now, and come back to this topic later. Meanwhile, enjoy the weekend.]

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

Marketing didn't start in the Fifties

Saeed Khan's recent series of posts about social media started with a video that purports to explain the new rules of marketing in which social media play a critical role. This video repeats a familiar argument: old-style marketing went one direction, from the vendor to the customer. The consumer, presented with a smaller number of choices than they have today, based their purchase decisions on a variety of motives, both tangible ("Costs less!") and intangible ("Be more attractive to the opposite sex!"). Vendors created their own messages and transmitted them through normal advertising and marketing channels, in the hope that they would deflect consumers in their direction ("We cost less, and we'll make you look even better!").

The video uses a familiar motif, a campy Fifties aesthetic, which is more than just an aesthetic decision. This isn't the first time that someone has used the Fifties as the baseline for measuring changes in modern marketing. Unfortunately, it's wrong to assume that we're the period of change, and the Fifties were a fixed starting point. The Fifties were also a period of social and technological transformation, to which the marketing professionals of the time struggled to adapt.

Ward Cleaver wasn't normal
The demographic story of the United States in the 1950s is by now familiar. After World War II, the US represented an unusually large amount of the global economy, on both the production and consumption sides. Post-war prosperity generated opportunities that American families followed in their exodus across the map of the United States. (As first-generation native Californian, by the way, I'm a child of that post-war migration from East to West.)

This exodus from one region to another, to jump from one job to another, had other aspects. Americans moved, in large numbers, from both the cities and the countryside to the rapidly-expanding suburbs. Ironically, as the suburban sprawl increased, people living in their newly-constructed tract homes felt more isolated from one another. The back yard replaced the front porch; the cul-de-sac replaced the neighborhood.

Simultaneous with these economic changes were major leaps forward in communications technology. Television may have been the iconic medium, but it was hardly the only one. Mass communications in every form, from the car radio to the morning newspaper, provided a wealth of  marketing and advertising activities, pitched to an audience enjoying a period of prosperity, opportunity, and even leisure time. This consumer society was open to suggestions about what to buy, including goods that previous generations might not have given as much consideration, from new homes to European vacations.

You usually don't have to look very hard to find some degree of condescension in depictions of this period. The Ozzie and Harriett-like nuclear families appear oblivious to anything but the quest for an increasingly middle-class existence. Consumers appear less like informed buyers, and more like credulous primitives excited about the shiny objects dangled in front of them.

Rod Serling wasn't abnormal
However, many Americans in the 1950s were all too conscious of the changes that had occurred, and the effects it had on mass behavior, often in dark and dangerous ways. A generation of social scientists saw this shift to a highly atomized society as dangerous for democracy. C. Wright Mills blamed the rise of a "power elite" on the emergence of a "mass society," which created a power vacuum that political and business power blocs were all too happy to fill.

In fact, this "mass society" was the cornerstone of many popular explanations of the rise of fascism and communism. Economic and social upheavals had sundered the lasting bonds of family, neighborhood, work, and voluntary organizations. Fearful of the future, and without other places to turn, citizens flocked to nasty political movements that promised to take care of them.

You can pick apart these theories of capitalist democracy and totalitarianism, as decades of scholars have. However, the important point here isn't to debate their merits. Instead, it's worth nothing them as signs that, not only were the Fifties an unusual time in American history, but people at the time were aware of how unusual it was.

Marketers in the Fifties recognized a good opportunity when they saw one. The unusual circumstances of the Fifties fostered the one-way communications between vendor and customer, because the audience was unusally receptive, and mass-scale communications channels made it easy to transmit their messages.

The marketing acumen of yesterday...today!
Product marketers today should not be congratulating themselves on how much smarter they are than the Don Drapers of some mythic marketing past. Instead, we should take a humbler view of how the marketing discipline adapts to current exigencies. That perspective makes it easier to understand why some traditional elements of the marketing mix, such as direct mail, haven't withered in the light of social media.

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