Welcome to “Nils’s Product Management Template Book – Chapter 1”
Thank you for visiting this page and checking out the draft of the first chapter of my new book!
This book will give a complete, working template for product management data and process – the entities you need to capture, with their properties; a process for working with all these entities, in particular using them for analytical prioritization; some background theory on why all the information is here, and how to customize it for your own enterprise as necessary. It’s designed to be used either with a product management tool, like Aha, or simply (with some limitations) with a general purpose solution like Excel and a wiki.
The download below is the first draft of the first chapter (in PDF form), and this is the first time I’ve shared it with anyone. I’d love to hear your thoughts and comments. You can email me directly at firstname.lastname@example.org, or use the comment form on this page (which other visitors to this page will see as well). This page is semi-private – it’s only accessible to people who have the URL, although it’s not otherwise secured. In fact, if you have a friend or a colleague who you think would like to review this chapter, please send them the URL for this page.
Thanks for downloading! Read on for a bit more information on why I’m writing this book.
Why am I writing this book?
For a little more background… In surveys of product managers, one of their most common complaints is related to the lack of a central system of record. A system of record has been the hallmark of modernizing business processes since the double-entry bookkeeping system was invented in the court of Lorenzo di Medici in Florence in the 15th Century. Every other business process in the modern enterprise has a system of record – accounting, manufacturing, sales, marketing, human resources, engineering. Every business process except product planning, that is, where we still use Excel, PowerPoint, and sometimes if we’re lucky, wikis to manage our product planning information, from requirements to customer requests to release plans.
It’s been known for decades that a system of record for product planning can significantly improve product quality, product team efficiency, and customer satisfaction (see Leffingwell’s Calculating the ROI From More Effective Requirements Management, [PDF from an FTP site] from 1996). And over the years product teams have tried to implemented systems of record, with various levels of success. In fact, some of the most successful companies in the world do have a system of record for product planning, often a home-made one. But most smaller and mid-size companies have focused on automating their other business processes – the back office, manufacturing, sales, development, even HR.
This is a shame, because the product planning process is the one most responsible for creating value in a company. It’s a well-known truism that a successful enterprise makes up to 50% its revenue from products introduced in the last three years. With the flipside being that if an enterprise is not introducing successful new products, it’s likely on a downhill slide.
Given the importance of the product organization, why have so many companies not taken the steps to automate it, starting with a system of record? There are many reasons:
- Product managers are typically superstars, and keep a lot of information in their heads, and are cognitively capable of suffering through a less than ideal information architecture – meaning Microsoft Office or Google Docs and (if we’re lucky) a wiki and a bug tracking system.
- Until recently the tools that were available for product managers to act as a system of record have been limited. Many have been simply extensions of tools that have worked for other processes such as bugs, projects, or sales, and have tried to replicate their information architecture and workflow. These are just not rich enough models for product planning. On the other hand, some tools are based on a different usage of the requirements management process, more appropriate to a customer providing requirements to a vendor, and then tracking the vendor’s work against the requirements – this is not the way the product planning process works at all.
But even if you have a good tool there is still a question about how it should be configured, even to just get started. And if you don’t have a tool, if you are going to use Excel and a wiki, or the equivalent, it’s even harder. Excel is a blank slate, and it’s very easy to get into trouble and go down the wrong path, even while not actually capturing the information you do need to make good product decisions.
That’s what this book will offer. A default template that, if implemented, will make your life as a PM better. You can improve it and customize it over time, but it’s a concrete starting place that will provide value.
You can use the form below to leave me any comments you might have (or just send me an email at email@example.com).