The product roadmap is dead: welcome to the age of problem roadmaps
Your product roadmap is one of the most important tools you will use to communicate with both internal stakeholders and customers to the direction of your product.
We commonly think of roadmaps as feature roadmaps. These are all the features your product will contain, from its humble beginnings to customer nirvana.
The fatal flaw
The problem with feature roadmaps is that they make us think about our product in terms of the functionality customers need — wait, that sounds good, right?
Not so fast — what we want to think instead about is which problems we want the product to solve for the customer and think about solutions when we have enough evidence.
Problem roadmaps are easier to think about, ensure your roadmap remains customer centric at all times and force you to think critically about the scope of the problem and the impact of a solution once all the evidence has come in.
The search for maximum utility
The issue with feature roadmaps is that everything is organised by focusing on the solution that will be developed rather than the underlying painful problem that needs to be solved.
By doing so, we may end up only treating the symptoms rather than making a diagnosis.
The risk is that subsequent feedback is retrofitted as support for the initial feature solution rather than being used to diagnose the underlying problem. Remember, its about building the best mouse-trap not the one we thought of first. Fall in love with your problems and not with your solutions.
The more that a product’s features overlap with a customer’s problem space, the more utility a solution provides. Problem roadmaps help you better understand the problems and then which features to build in order to create the maximum utility.
When you develop a solution for a customer problem, the problem never leaves the roadmap until there is successful field validation. Typically this means the customer used the solution, provided qualitative feedback or we contributed statistics to prove a quantifiable result.
If the solution was a flop, that failure only serves to add more context to the problem in the roadmap — perhaps we didn’t have a good understanding of the problem — and the solution can be discarded. But the problem lives on in our roadmap.
In this series, I’ll be discussing the implementation of Problem Roadmaps and explore how product managers can use them to help product teams (that means developers, designers and marketing — oh my!) to build and communicate for maximum utility.
