The Heretech

The path to professionalism

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

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

Roughly, here's the sequence of events:

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

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

So, how does this relate to the PM profession?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

How many personas?

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

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

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

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

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

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

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

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

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

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

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

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

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

Frivolous Friday: Dinosaurs love updates

Today's Dinosaur Comics edition must be shared.

The Heretech, episode 25: Val Workman on the profession of PM

Val Workman of Ryma technologies talks about the professionalization of product management, by way of a visit to the metaphorical zoo. Oh, and Frank Capra is there, too. (You have to listen to the interview to understand.) Plus, for this week's review, I put my personal agony with a popular application on display for all to see. (c) 2009 Tom Grant

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

PMs know that requirements are flawed

The workshop next week, "Using Social Media To Make Smarter Product Decisions," was a good occasion for me to jump into the data we've been collecting about requirements in the technology industry. It's one thing to claim that there are problems that need fixing, and that social media can help fix them. It's another to put that claim to the test.

The requirements survey has produced a lot of interesting results that will see the light of day in a research document to be published later this quarter. The questions we asked build a composite picture of both the content of requirements and the process of creating them. For example, we asked, ""How much time do you dedicate to requirements work at each stage of the development cycle?" Doing a weighted average of the responses, here's the answer:

This picture should be familiar to any PM: lots of requirements work at the beginning of the project; less and less as the project proceeds. Which begs the question, how effectively can the organization make mid-course corrections? When does the "after action report" kind of analysis happen, when PMs look back on the work they just did to figure out what they could do better the next time?

While this spike of requirements attention at the beginning of a project makes sense in bureaucratic terms, it doesn't make sense in research terms. You might pretend that the requirements you build at the beginning of a project are everything that the development team needs to proceed, but at best, that's a comforting fiction. You always need to fill in gaps, provide more detailed explanations, and validate the results.

If requirements are the information that technology teams need to avoid making costly mistakes, then requirements gathering and analysis should be an ongoing activity. While that's certainly true in some PM teams that I've met during my time as a Forrester analyst, in the aggregate, these peaks and valleys of activity still define the requirements landscape for many PMs.

There are plenty of other signposts to deficiencies in product requirements. For example, there's a big mismatch between the skills needed to do requirements, and the opportunities to put these skills to work. While the rest of the story will come later, I thought this one result was interesting enough to now, instead of waiting for the final report.

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

The Heretech, episode 24: Ellen Gottesdiener on building better requirements

Ellen Gottesdiener of EGB Consulting tells us why requirements depend more on group dynamics than templates. On a related front, where are the cross-industry requirements blogs? (c) 2009 Tom Grant.

"Nice going, Maslow!"

Anyone in the research business should appreciate this edition of Dinosaur Comics.

PM is more than features

Jeff Lash makes an excellent point:

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

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

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

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

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

Social product management workshop coming soon

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

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

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

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

The PM calculator: tasks

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

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

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

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

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

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

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

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

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

The Heretech, episode 23: Catherine Connor on PM, CRM, and Agile

Catherine Connor and I talk about customer insights--how Agile adoption changes their significance, and how CRM systems can provide them. Plus, a review of one of the best little blogs about the best little innovations in the SaaS world. (c) 2009 Tom Grant

Drop the pilot?

Via Rocket Watch, do you need to pilot the roll-out of enterprise-esque, Web 2.0-ish collaboration tools? Michael Idinopulos of SocialText says no:

But social software is different from traditional IT. Traditional IT enables individuals to carry out well-defined, highly standardized transactions. Users go into the system to process transactions--to transfer funds, purchase supplies, track inventory, etc. The nature of these transactions, and the system's ability to enable them, do not vary much according to the number of people using the system. Whether 100 people are entering orders or 10,000 people are entering orders, the transactions themselves doesn't really change. What that means is that a representative small-scale sample is an accurate predictor of adoption and value at full scale.

Idinopulos starts the post by saying, "Get out your pitchforks, I'm about to commit Enterprise 2.0 heresy." If he detects the smell of torches, or the clatter of pitchforks, it's not because his argument is heretical. (As you might guess, I have a lot of sympathy for heresy.) Instead, his argument overlooks the adoption process for collaboration tools.

Idinopulos' argument breaks down at the following points:

• While "traditional IT" (ERP, etc.) focuses on transactions, social applications focus on interactions. If you have ever had to deal with a rejected expense report, or negotiated a deal with a client, or handled an internal audit, you'll quickly appreciate the lack of clear boundary between "transactions" and "interactions." In reality, work is a combination of well-defined tasks, such as closing the books on the quarterly financial statement, and the large amount of collaboration needed to get those structured activities finished.
• Collaboration is separate from "traditional IT." As the previous bullet implies, there's not a clear boundary between the two. In a business setting, people aren't collaborating for the sake of collaborating. Instead, they're trying to get work done. In a Microsoft shop, a SharePoint or Exchange administrator might not see these other activities, or the applications involved (CRM for sales, document capture for contracts, etc.). However, those files, e-mails, and other unstructured content are part of a larger business process, not the whole business process itself.
• Collaboration has no specific shape or form. "This is the way we communicate new releases to customers in this company" is one of countless examples of how institutional factors constrain activities. So, too, do individuals themselves, who have habits, preferences, past experiences, lessons learned, and a limited amount of time and patience for experimentation.
• Adoption depends on the tool. Idinopulos argues that some social applications, such as Wikis, require more up-front work to make them useful than, say, micro-blogging. However, that's hardly the only variable, and it's not necessarily the most important one. Sure, as a customer service rep, it's easy to post a thought about how to deal with difficult customers via the company's Yammer account. However, you can't put much into that thought, and certainly, for someone looking for advice, it's harder to sort through a bunch of micro-blogging posts than a well-organized Wiki. The business argument for using a collaboration tool, as either a contributor or consumer, is just as important a determinant of adoption as the difficulty of using the tool itself, or the amount of content needed to get it started.
• For a new collaboration technology to be successful, you need to start big. Idinopulos cites Metcalf's Law, which "famously states, the more people there are in that network...the more value that individual derives from participation in that network." And, Idinopulos argues, it's hard to predict from a small pilot how other individuals or groups will use the technology. Unfortunately, people are not Christmas tree lights: you don't just string all the nodes together, stand back, and say, "Ooooh, impressive." Some people may figure out the value of the tool on their own, but for those who don't, a few good business arguments and use cases discovered during the pilot can be very convincing.

The very fact that you can't always predict all the use cases for a collaboration tool is the very reason why, in many cases, you need some use case as an illustration, even if it's not your own. Collaboration tools don't manufacture use cases; they create the means to address these scenarios in new ways. For example, I'd love to stay in touch with everyone that I've ever known. LinkedIn and Facebook just make it way easier to do so.

Social networking, Wikis, blogs, forums, micro-blogging—these are great technologies to address human wants and needs in novel ways. In the workplace, the communications and activities they make possible are connected to business processes.

Of course, IT people can get in the way of projects, deciding on behalf of employees the "proper" use of collaboration tools. Of course, you can smother some projects by making them too small. You can also ensure the failure of the very same projects by making them too big, if you throw new technologies in people's faces and expect them to figure out the use cases, and work out all the kinks of your technology, on their own.

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.