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