Principles of a good product roadmap
Principles of a good product roadmap
8 principles to keep in mind when creating or assessing your roadmap
The article Escaping the Roadmap Trap sparked some insightful discussions about software product roadmaps. It showed that the topic is hitting a nerve in product teams. Here are my three main takeaways from the responses:
There is no one size fits all solution when it comes to a roadmap. Different roadmap formats are suitable for different products, teams and companies.
Product teams would like to frame their roadmap more around outcomes rather than outputs. Few have successfully done so.
Product managers feel stuck between the agile software world vs. providing planning certainty for their business stakeholders. There seems to be a conflict in using one format to communicate both long-term strategic priorities as well as the short-term release plan.
It led me to think a little further about the topic: Can the characteristics of an agile roadmap be distilled into a set of universal principles? Taking a standard format off the shelf rarely works. Principles however help you assess an existing roadmap or create a roadmap with them in mind. The result is my attempt at defining agile roadmapping principles.
Principles of a good product roadmap
A good roadmap mediates between product vision, company goals, and customer feedback. A roadmap can be created top-down (based on vision and goals) or bottom-up (based on product discovery and customer feedback). A good roadmap balances these inputs.
A good roadmap is strategic. It's not just a collection of all stakeholder requirements. It’s a focused selection of the most important themes. As such, it provides clear priorities to the product team.
A good roadmap is framed around impact. It provides context such as the customer problems, satisfaction or business KPIs behind the roadmap items.
A good roadmap focuses on problems. It stays flexible on the solution, especially for the mid- and long-term horizon.
A good roadmap embraces discovery. Roadmapping is a continuous process rather than a one-off activity. It provides flexibility to act on new insights.
A good roadmap reflects the level of certainty in a problem or solution. It differentiates validated opportunities from rough ideas.
A good roadmap provides as much planning certainty as reasonable for other stakeholders. It communicates the opportunities the product team is working on as well as upcoming feature releases. When it comes to date commitments, it only contains high-integrity commitments the product team can deliver on.
A good roadmap is assessed retrospectively. It’s evaluated with regards to whether features have been shipped on time and desired impact has been met.
Those principles are intended for (1) agile software teams that are (2) building a product or portfolio of products ‘strategically’. They aren’t intended for stakeholder-driven software projects or hardware products. However, I believe there might be guidance for all types of product development teams in them.
Do these principles help you assess or create your roadmap? Which principles would you add? Which ones don’t work for you and why? Join the discussion in the comments below.
If you enjoy my articles...
...I’d appreciate it if you’d share them with someone who might find Product Crunch interesting as well. A growing community helps me capture more opinions and insights to write high quality content. I really appreciate the support!
Upcoming articles in the works
Stop looking at the customer through your product
Why Figma is winning: Strategy lessons from the evolution of design tools
Great post. Love the point, "A good roadmap is framed around impact." Easy one to forget. What is the value you are trying to create with your plan. Thanks for sharing!