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.

Categories:

Comments

re: The tyranny of the tactical

Jeff makes some really great observations in this post and elsewhere on his site. In particular, in commenting on my ebook, he found this nugget: "But just because the product manager is an expert in the product doesn’t mean no one else needs product expertise." Jeff adds, "The real reason that product managers are engaged in these activities is because they have done them in the past, so others assume they will do them in the future."I based much of the writing of "The Strategic Role of Product Management" on our years of qualitative and quantitative research combined with my personal experience with hundreds of product managers each month. Feel free to reference my ebook in your posts. Go to www.pragmaticmarketing.com/srpm to download the book.

re: The tyranny of the tactical

The military operates on three progressive timeframes: reactive, predictive, and proactive. Predictive is where you transition from reactive to proactive.If you are doing tactile, start thinking about how to tansform it into proactive as you drive home from work. Get some space to think. Improve your proceses at every turn. Soon enough you will only operate in the proactive.Release cycles are repetitive, so you should only be doing reactive work once, aka the first time.