Posted by Tom Grant on August 31, 2010
When it comes to home improvement, I'm barely competent. My biggest hurdle is ignorance: when I was growing up, no one in our family was a do-it-yourselfer. Unless I had the opportunity to watch the handyman, electrician, or plumber fixing a problem, and that person was patient enough to let me observe, I had zero experience with these tasks.
Fast forward to a couple of years ago, when I signed up for installing hardwood floors in our home. Friends had said that it wasn't as hard as it looked, and the staggering quotes from contractors provided the incentive for forging ahead, despite my ignorance.
After buying the tools and digesting the instructions, I started on the first room. My first attempt was a hilarious escapade, which resembled a horizontal variant of Jenga more than anything that you could describe as "home improvement." After taking a break for a few days, I figured out where the project had gone wrong, made adjustments, and finished the room.
My initial failure was the result of techniques, not tools. Although I started with a modest toolkit, I quickly made a couple of critical additions, such as the +5 Compound Miter Saw of Ultimate Puissance. Unfortunately, the instructions, such as they were, rendered my choice of tools moot. Not only were they incomplete, but the instructions didn't address some of the unexpected issues I faced. For example, what happens when walls do not always meet at an exact 90 degrees? Other challenges required some best practices guidance, instead of the sort of generic instruction you get from a manual or video. What's the best way of ensuring, once you've covered the rest of the floor, that there won't be an unexpected dip, however slight, at some point where the floor runs under the baseboards? (Something that you might not notice until you install the baseboards.)
To Get Started, You Need A Toolkit, Instructions, And...?
Whenever I see the word "toolkit," I'm reminded of experiences like these. The latest product management reference, The Product Manager's Toolkit by Gabriel Steinhardt, is exactly what the title implies, a collection of tools, primarily templates, that you could use to accomplish various tasks. Building a road map? You might use the template on page 159. Lack a clear value proposition that distinguishes you from the competition? The template on page 233 might help.
The instructions on when to use these tools, and how to adapt them to your circumstances, aren't really the topic of the book. The introduction makes some suggestive observations about the differences among engineering-driven, sales-driven, and market-driven companies. However, there's no path between choosing one of these models and using the provided templates. It's as if the instruction manual for an Ikea computer workstation had printed on its cover, "Want to be a web developer? Get started now!" Of course, you need the workstation to work. The connection between the tool (the furniture) and the outcome (a Web application) exists, but it's neither direct nor altogether clear. (More on the method behind the templates later.)
The introduction aside, the templates have the potential to be very useful. The author obviously has a lot of experience in product management. If an experienced PM sat down with a piece of paper and listed all the templates someone might use, that person would have a hard time producing a catalog as extensive as the contents of The Product Manager's Toolkit. The contents of each template are just as comprehensive.
That's Not How We Do Things Around This House
But are these the templates you would use? Yes, perhaps, but only to a point. To return to the workstation analogy, your workspace is not the workstation that you assemble, strictly following the Ikea instruction manual. The workstation, in practice, has additions, subtractions, and changes needed to suit the way you work. You might remove the bottom drawer from the workstation if you don't really need it. You may add a desk lamp, and you'll definitely need a power strip. Need to store papers somewhere other than the desk? Hanging file folders on the side of the workstation could help.
In exactly the same fashion, no PM template will be the same from company to company. The data model of any PM document, such as a product road map, is the result of negotiation among interested parties. Crafting the contents of requirements documents, which includes critical choices about the type and quantity of information, is an art that requires skill, creativity, empathy, and patience. Many teams never reach an optimal formula: the development team might complain that the first version of requirements lacks key information, while the second version buries them in unnecessary details.
I've Read The Instructions. Now What?
In short, The Product Manager's Toolkit has value to the extent that it provides useful advice on what content PMs might consider developing in their work. The book does not, however, tell you how to convince other people of its value. Somewhere in Silicon Valley, or Silicon Gulch, or Silicon Somewhere, a PM dreams of devising a better way of communicating the status of a product under development. I bet there's at least one template in this book that could help.
Unfortunately, you can't hand this book to the head of PM, the head of development, or other stakeholders and expect them to tug their forelocks in recognition of the wisdom contained in these pages. Before diving into the templates, Steinhardt explains at length the methodology intended for their use. The Blackblot Product Definition Team Model defines specific roles, such as lead developer and product architect, that are involved in specific tasks, such designing the product, using specific PM deliverables such as product requirements. It's a very familiar, sensible approach, in which concepts like the product life cycle and perceived value play important roles. But is it the approach that a particular company would adopt, either wholly or partially?
Even if the forelock-tugging occurred, there's many a slip betwixt principle and praxis, which is a good summary of my experiences installing hardwood floors and running a PM organization. The success of a PM organization depends on the team's deliverables, which in turn depend on the methodology behind those deliverables. However, everyone needs more than just the right tools (the templates), and the basic instructions for using them. Buy the book for help with what you might do and to get an introduction to Steinhardt, who may provide some valuable help outside the book itself. But don't hand this hefty tome to a colleague in the expectation of a moment of mutual epiphany. Your co-worker might just drop it on your foot instead.