The Alternative to Roadmaps by Marty Cagan
Earlier, I thought of doing a 3 part summary of Marty Cagan's new book, Inspired 2. But I don't feel comfortable squeezing an entire book into a few short summaries. Marty covers a lot of ground in the book. Hence, I am planning to present my own reflection on individual topics that I strongly resonate with and feel is important for product community in general. As the title suggests, this post is on roadmapping. I myself have written a few posts before on this topic before.
Marty makes recommendation to rethink traditional roadmapping in the two chapters of the book, 22 and 23.
He says typical product roadmaps are all about output. Product roadmap is a prioritised list of features and projects your team has been asked to work on. The roadmaps are usually done on a quarterly basis, but sometimes they are a rolling three months, and some companies do annual roadmaps. In some cases, product roadmaps come down from the management, also referred to as stakeholder-driven roadmaps. And they typically include due dates or at least time frames for which each item is expected to be delivered.
Management has fair reasons for wanting product roadmaps:
First, they want to be sure, you are working on the highest-value things first.
Second, they are trying to run a business, which means they need to be able to plan. They want to know when key capabilities will launch so that they can coordinate marketing programs, sales force hiring, dependencies with partners etc,
Even though these are reasonable desires, typical roadmaps are the root cause of most waste and failed effort in product organisations.
The Problems with Product Roadmaps - The Two Inconvenient Truths
Even with the best of intentions, product roadmaps lead to very poor business results. According to Marty this is because of two inconvenient truths about products:
The first inconvenient truth is that at least half of our product ideas are just not going to work.
The second inconvenient truth is that even with the ideas that do prove to be valuable, usable, and feasible, it typically takes several iterations to get to the execution of the idea to a point where it delivers expected business value that management was hoping for. This is referred to Time to Money.
According to Marty Cagan, there is no escaping these two inconvenient truths. The difference is how product teams deal with the truth.
How Weak Product Teams deal with it
Weak teams plod through the roadmap they have been assigned, month after month.
And, when something doesnt work, which is often the case, first they blame it on stakeholder that requested the feature and then try to schedule another iteration on the roadmap.
How Strong product Teams deal with it
Strong product teams understand these truths and they understand them rather than deny them
They indulge in product discovery to fast iterate to an effective solution. Product discovery is the most important core competency of a product organization.
If we can prototype and test ideas with users, customers, in hours and days rather than in weeks, it changes the dynamics and gets your the results.
“The issue is that anytime you put a list of ideas on a document entitled “roadmap”, no matter how many disclaimers you put on it, people across the company will interpret the items as a commitment”
And thats the crux of the problem, because now you are committed to building and delivering the thing, even when it doesn't solve the underlying problem.
The Alternative to Roadmaps.
Roadmaps have existed for so long because they serve two purposes and these needs don't go away:
The first purpose is because the management of the company wants to make sure that the teams are working on the highest business value items first.
The second purpose is because they are trying to run a business, there are cases where they need to make date-based commitments, and the roadmap is where they track and see those commitments.
Addressing the first management driver - working on the highest business value items
In the new roadmap model, it is the management’s responsibility to provide each product team with the specific business objectives they need to tackle. The difference is that they are now prioritising business results, rather than product ideas.
I resonate with Marty Cagan's proposal that management/stakeholders must prioritise business results and let teams decide upon the roadmap that promises to meet the business results.
I had presented the following slide as part of my talk at MTP, Engage, Hamburg last year that summarizes the best practices followed in the industry on product roadmapping :
Addressing the second management driver - date based committments
This is done by the concept of making high-integrity commitments. Good product companies minimise these date commitments. But there are always some real commitments that need to be made to effectively run a company.
So, what needs to be done?
The key is to understand that the root cause of all this grief about commitments is when these commitments are made. They are made too early. They are made before we know whether we can deliver on this obligation, and even more important, what we deliver will solve the problem for the customer.
In the continuous discovery and delivery model, the discovery work is all about answering these questions. We ask the executives and our stakeholders to give us a little time in product discovery to investigate the necessary solution. We need the time to validate that solution with customers to ensure it has necessary value and usability, with engineers to ensure its feasibility, and with our stakeholders to ensure it is viable for our business.
So, the compromise is straightforward. The product teams ask for a little time to do product discovery before commitments are made, and then after discovery, we are willing to commit to dates and deliverables. Its important for the organization to get comfortable with making these high-integrity commitments.
Question for the readers
What is the kind of product culture in your organization? How empowered are the product teams to come up with their own roadmaps? How much is the roadmap influenced by the upper management?
I am running a poll on Twitter that ends in 24 hours. Please try to answer it here:
2. I am interviewing Marty Cagan in January. What questions would you want me to ask him?