The tyranny of the tactical

Jeff Lash muses at length about the importance of rising above tactical product management work in this excellent post. Here's a juicy quote:

Think about all of the tactical activities in which you engage — documenting details, answering questions, describing functionality, responding to feedback, tracking down responses, and the like. How much of your time is taken up by these activities?

The aggregate answer we received from our recent survey (publication pending) is, "Way more than we should." Although every job imposes some time spent on seemingly unproductive or counterproductive tasks, the degree to which product managers feel misused is striking.

One major struggle may be the difference between how product managers see their jobs, and how other people in the company (including their own management) view product management. Jeff touches on this problem indirectly, and perhaps accidentally, in the following section of his post:

Every time you as a product manager are presented with a task, ask yourself these questions:

• Is this helping to advance the product strategy?
• Does this support one of the high-level goals for my product?
• Is there anyone else within the company besides me who can accomplish this task (e.g. answer this question, investigate this problem)?
• Is this something that has come up before or is likely to come up again?
• Is this a valuable use of my time?

Of course, not everyone else in the company assumes that the core task of product management is advancing product strategy or supporting the high-level goals for a product. Alternately, they might agree that these are the core job functions, but they have no idea how product managers actually carry them out.

As long as there's this mismatch between perceptions, product managers are going to be swimming upstream against a flood of requests that they don't see as necessary. For example, does booth duty at trade shows help product managers achieve their goals? Maybe.

The answer is nowhere near as obvious as, "Asking developers to man the booth does not help us make our release dates." Therefore, product managers may try to build barriers against requests to help Marketing, but the cracks of ambiguity and misunderstanding weaken the dam.

During any interviews with product managers, Ive asked how Forrester can help them. The same answer has appeared in close to 100% of the responses: "Help my company understand what I do." Until this perception gap closes, product management will remain focused on tactical activities--because that's what many other groups want from product managers.

The company is not totally to blame. Jeff Lash's post has an important subtext that every product manager should heed: You don't have to be involved in everything because you might add some value.

Leadership Board for product managers

Forrester is planning on creating a Leadership Board for product managers. What does that mean?

Here's an official description:

The Forrester Tech Industry (TI) Leadership Boards bring senior executives together to stimulate new thinking & encourage business growth. Each is a knowledge community, layered on top of Forrester’s research services, tailored to a specific role. The Forrester Leadership Boards (FLBs) help members succeed by offering member-driven content, unique deliverables, community interactions and a dedicated relationship team.

In other words, above and beyond the normal research and consulting, the FLB for product management may provide things like..

• Regular contacts with your peers in other organizations, plus the Forrester TI analysts who serve product managers.
• Access to research that the FLB members specifically request.
• Special events for FLB members, including mini-events at Forrester conferences like the upcoming IT forum.
• A little extra attention as a Forrester client, since there's an official FLB staff.
• Information about the questions clients are asking us, through the regular inquiry process.

Since we're a role-based company, we have to be sensitive to the needs of each role. Therefore, you tell us: What would you like to see, in a Forrester Leadership Board (FLB) for product managers? You can respond in the Comments section here, or send me an e-mail.

Product manager or evil overlord?

I had a good chuckle at this paragraph on the SugarCRM web site:

The Sugar Open Source Project and Community are at the heart of our mission. Creating an ‘architecture of participation’ where users from around the world can help to build a higher quality, more useful product is a superior form of development than the traditional Silicon Valley model of a few product managers dictating what features the world needs. The open source model embraces the world outside of Silicon Valley instead of keeping it at arm’s length.

If you ever doubted that there's a difference between product management and marketing, doubt no more. Memo to the marketing person who wrote this copy: some product managers might dream of having dictatorial powers, but, honestly...

[On the off chance that you have the power to mold people's wills to your own, call me. I might get you a part as the villain in the next Bond movie.]

PMs promptly pithed

John Mansour puts his finger on an issue facing successful product managers: product knowledge is a double-edged sword.

Okay product managers, what has all your down-in-the-weeds detailed product knowledge done for you and your company lately?  Entitled you to more phone calls and emails?  Turned you into first line customer support?  Allowed you to write endless pages of detailed specifications that are more painful than a root canal minus the Novocain?  It doesn't sound like product management.

Mansour argues that, for many core aspects of product management, product knowledge can be a liability for the product manager. Here's an example:

3.  Defining Business/Market Requirements & Business Cases - It's all about defining problems first, and product knowledge is not required to define a business problem.  Your target customers have the same problems today they had 100 years ago.  They just have them for different reasons.  Product knowledge is only required to suggest the most appropriate features for creating the solution. Detailed product knowledge = liability because it forces you more into "how" features should work instead of  "what's needed and why" from a business perspective.

There's one small problem here: your credibility as a product manager depends on your product knowledge. Developers and engineers can smell when someone doesn't know how the current product works, or what is technically feasible. Before you can convince them to take on work, or make mid-course adjustments to what they're building, you have to appear that you know what you're talking about.

Once you've established your cred, the company is happy for the PM to talk about features and functions, instead of the business perspective, for reasons far too lengthy to discuss here. Suffice it to say, your product knowledge is always going to be useful for sales, support, training, and other important activities. Getting strategic, when your daily schedule is filled with tactical responsibilities, is pretty tough.

Short of finding something in your high school biology notes that could tell you how to pith yourself,  PMs have only a limited ability to say no. You can't keep refusing to help with big sales opportunities and keynote demos.

Unfortunately, I don't know what the alternative could be. I've had my moments when my willingness to be an uncompensated sales engineer or documentation writer snapped. Until management understands the price everyone pays for this misuse of product management, it's a situation that's likely to continue.

Here's another reason why I wanted to study product management: no one doing product management can accurately depict these sorts of problems, across the industry, and calculate the costs to the company, not just the PMs. Companies have to reach the realization that misusing product management is like strapping a Saturn rocket to your minivan: Sure, it'll get you where you want to go, but there are far better ways to use these resources.

Sneak peek of the PM tools document

Many thanks to the good people at The Product Management View for the opportunity to talk about the tools product managers use. The presentation was a sneak peek of my upcoming research article about this topic. The View is a good forum for discussions of product management, so we had many good questions during the webinar. Thanks, too, to everyone who attended.

If you're interested (and you can brave seeing my picture again), the presentation is available in both Flash and MP3 format.

Brace yourself

My first official Forrester publication is on the web site. I thought I'd start humbly, with something titled, "The End of Product Development." Then we could fast forward a million years, when human beings are gone and cockroaches rule the world. Before we go there, it's worth pausing to note what the IT to BT transition means for product development in the technology industry.

As a friend and colleague said when I sent him the link, "Gosh, it's weird to see your picture there!" If you can get past the picture, I hope you find it useful.

Postscript: In case you're wondering about the research article about tools for product managers, it's making its way through the editing and production process.

The end of roadmap secrecy?

A long time ago, in a much different job in a galaxy far, far, away, we used to joke that there were three product roadmaps: (1) the customer-facing one, which was laconic to the point of uselessness; (2) the official roadmap for the product team; and (3) the architect's super-double-secret roadmap.

On the other end of the continuum, you have companies like Salesforce, which is willing to make its roadmap visible, to a very substantial extent, to anyone browsing the corporate web site. Salesforce won't tell you everything they're doing, like potential acquisitions or partnerships. However, the IdeaExchange drives product enhancements in a very transparent way.

Most technology companies aren't willing to make their roadmaps as visible as Salesforce's, but the percentage that are increases daily. Open source may have given a cultural boost: anyone with strong enough motivation could add new functionality to the project. However, the open source community won't convince a CEO that it's a good idea to make a commercial product's direction visible to everyone--including competitors.

I can't think of any product, including security tools, that have a good reason to hide every part of their roadmap. Both customer and vendor benefit from openness. For some executives, however, it may feel like they're walking around naked for a little while.

Requirements, shmequirements

Working on the PM tools research (drafted, in editing) has led to a recurrent question: what sort of requirements tool? Requirements definition? Requirements management? Something else?

Does it matter? The distinctions seem a bit arbitrary. The raw data is the same, regardless of the immediate task (collecting, analyzing, using them in a product plan, using them in feature or use case documents, tracking the progress of a release towards meeting these requirements, etc.). Why should these different bits of information be stored and managed in separate systems?

If you don't believe that having a shared repository of dynamically assembled requirements information, go work for a PM group for six months, and count the number of times you type the same information into multiple formats. For example, let's assume Friendly Customer Inc. wants a particular enhancement. A short version of that enhancement request may appear in a list of possible features for the next release. Friendly's use case might be important supporting documentation for the feature write-up. When the CEO demands to know how the company is responding to Friendly, one of the firm's best customer, the enhancement will appear in a slide. And son on.

While you might not want to try tackling every possible use of requirements data in the original application, the natural gravity of product management certainly tugs in that direction. Otherwise, why not just go back to using Microsoft Office, manually re-purposing the same information in new documents for different audiences?

You have to set some boundaries. Still, the borders are pretty wide. Atlassian, for example, has a product strategy that tries to pull all members of a technical teams--developers, QA engineers, product managers, and project managers--into the same suite of integrated tools. They're not requirements tools, in the strictest sense that some people prefer, but certainly the issue tracking part of the Atlassian suite, JIRA, has direct relevance to customer needs that may turn into features. Makes sense, just as much as automated test case generation from a requirements tool like Borland's Caliber DefineIt is a necessary byproduct of what PMs do when writing requirements.

Rather than worrying about how finely you can slice the requirements tools market, the real question might be, How big a collection of functionality should a requirements tool embrace?

Passion is no ordinary word

I was going to post a response to something I read on the Product Beautiful blog in the Comments section, but it got a wee bit too long. So I'm posting it here.

Product Beautiful asks, Does passion matter in product management? It all depends on what sort of passion we're talking about.

The unbearable lightness of being a PM
The unstated premise behind Product Beautiful argument is that you have to get really excited about a product to act as its product manager. The companies cited--Apple, Dell, and Amazon--imply a general-purpose solution, like an iPod, inexpensive home PC, or an online bookstore. You'll also note that these are very "horizontal" products, without specific "vertical" spins, by industry or role. (Or, at least, that's how they might appear on the surface...But that's another conversation entirely.)

If these sorts of products inspire and require passion, what doesn't?

Some of the most profitable products and services are those that don’t inspire at all - like cable television,  life insurance, and payroll processing.  No one is starting blogs about these products evangelizing for them, and they don’t have to.  They’ve risen (or fallen) to the level of “utility” in the consumer’s mind that doesn’t set off mental arithmetic to pay for...

Does inspiring passion matter?  If you are in a highly competitive market, and you need to charge a premium for a product that sells on non-functional aspects like GUI, you bet it does.  If you are selling groceries, not so much.

If I'm reading these passages correctly, Product Beautiful is asserting that passion is only possible when products are cutting-edge, or when you're in a market where the "coolness factor" matters. For the rest of you...Good luck with your dreary existences.

Before we consign the majority of product managers to Purgatory, let's stop and think about some other aspects of product management that may require passion, or squelch it. Not every cutting-edge, neat-o keen-o product is a lot of fun. Not every project involving cable television or life insurance needs to be dull.

Fun projects that aren't necessarily fun
Let's be honest about product management in the high-tech industry. If you're a PM who doesn't spend a substantial amount of time, regardless of the product, on drudge work like tracking release deliverables, triaging bugs, and answering product questions on an internal mailing list, you're leading a charmed life. Whisper not a word of it to your employers, lest they notice that everyone else in the PM biz handles these sorts of tasks. (Which tasks vary across companies, as my upcoming research article about jobs in the PM industry will discuss.)

And, to be brutally honest, the "coolest" projects are sometimes the worst places to work, as a product manager. Just as sweet fruit attracts yellowjackets, cool projects attract everyone's input. Or, the project is so cool that the company won't trust anyone but the architect/CTO/dev manager to make important decisions about it. You can get as disillusioned as a Hollywood intern.

A more durable source of passion might be better, something less dependent on the project, or even your co-workers.

Dull projects that aren't necessarily dull
Many of my interview questions for PM candidates were, overtly or covertly, all about motivation. Why are you a product manager? What sort of product or company excites your interest? And so on.

In hiring PMs, I had a bias towards people who got fired up to see real customers using their product. The more customers, and the more interesting the implementations, the happier this sort of PM would be. (And the company, too.)

That's the sort of durable passion that keeps PMs happy, when working on sexy products, like Wikis, or more prosaic tools, like records management solutions. I've worked on both, and found both challenges interesting--even if I'd never want to be a records manager myself.

Clausewitz on product management

Demian Entrekin at the IT Toolbox blog cites two problems in product management that, in my marginally humble opinion, are actually the same problem. First, there are the unrealistic schedules:

I have to admit that I have done this myself. I often put down a schedule that I know in advance is not exactly realistic. I call this the internal plan. Then there's the external plan. That plan is more vague and has something like a 50% pad built into it. Some people call this sand bagging, but I call it managing expectations.

And then there's "Information Uncertainty":

But from where I sit, Information Uncertainty is quite a different animal. In short, Information Uncertainty means we don’t know what will happen as an idea moves through the life cycle toward becoming a project and then launch. There is a tremendous amount of uncertainty. The idea may lead to substantial change. It may lead to incremental change. It may never make it to funding. It may be a great idea that we simply fail to execute.

Actually, these are both facets of the same problem. It's called friction, the tendency of plans to unravel as unexpected obstacles appear. If you were a CS major in college, you might not have heard that term. If you've ever gone through officer training in the US military, chances are that you have.

Friction, in this paricular sense of the word, comes from a classic work on military strategy, Carl von Clausewitz's On War. Military professionals have a lot of anxiety about plans that fall apart, since they usually involve people shooting at you. Therefore, people like Clausewitz, a Prussian veteran of the Napoleonic Wars, have a very strong motivation to understand why plans fail.

Everything is very simple in War, but the simplest thing is difficult. These difficulties accumulate and produce a friction which no man can imagine exactly who has not seen War, Suppose now a traveller, who towards evening expects to accomplish the two stages at the end of his day's journey, four or five leagues, with post-horses, on the high road--it is nothing. He arrives now at the last station but one, finds no horses, or very bad ones; then a hilly country, bad roads; it is a dark night, and he is glad when, after a great deal of trouble, he reaches the next station, and finds there some miserable accommodation. So in War, through the influence of an infinity of petty circumstances, which cannot properly be described on paper, things disappoint us, and we fall short of the mark.

Given the inevitability of the unexpected, no commander should ever base a strategy on everything going exactly according to plan. As another smart Prussian said, "No plan survives contact with the enemy."

While product development in the technology industry is a lot safer than military service, ignoring the role of friction is just as foolish. Go ahead and be aggressive--just be realistic. If you're worried about keeping people motivated, just remember that no one is motivated by doing a third rate job, or finding out that the original schedule was a crock.

Hire good people who want to meet deadlines, and assume that even the smartest people can't anticipate everything that might go wrong. If you ever catch yourself assuming that everything will go right, buy a copy of On War and smack yourself in the head with it.