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

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.

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

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

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

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

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.

[Cross-posted at The Heretech.]

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

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