As a Product Manager you are often asked to create and maintain a product roadmap. In this post I provide 5 tips that will help you build a successful product roadmap.
1. Understand Why it Exists
First question you should ask yourself is why a roadmap is needed. Different organizations use roadmaps differently and many of them use them in the wrong way: as a sales tool.
Some people advocate that a product roadmap is useless because you cannot predict how your customers will use the product in the future and hence it is a futile exercise.
I disagree with that. I think Product Roadmaps are actually very useful when built and used wisely.
The Product Roadmap is a tool to establish alignment across the organization of our current view of where the product is headed and the initiatives we expect will get us there.
The Product Roadmap only makes sense once you have achieved product-market fit. Before that you are still in search of a direction for your product that will make it successful. Therefore don’t waste your time planning what the future may look like. Just focus on the current experiments, test them and decide the next step based on the findings.
Make sure you spend time helping everybody in the company understand why the Product Roadmap exists. If someone has other needs not covered by the Product Roadmap you should explain to them why the Product Roadmap is not the right solution and maybe finding another tool that will address those needs.
2. Set the Vision for the Product
The Product Roadmap should set the vision for the product. Dedicate a few of sentences to briefly describe who is the target audience for your product and what is the ultimate value it will provide to them. This helps set the context for what is coming in the roadmap.
3. Focus on Outcomes, NOT Features
Many Product Roadmaps are just a list of features. This is generally a terrible idea.
Products exist to generate revenue from solving a problem and / or delighting its users.
When you talk to users of your product you can identify opportunities for solving a problem or delighting but you most likely don’t know what solution to that problem or opportunity you can provide. Even more, opportunities change slowly but the way to address them evolves constantly based on rapid changes in technology and new things you learn along the way.
Therefore, forget about specific features, focus on the benefits for the user. There is even a great framework to help you focus on that: Jobs to be Done. Features are product-centric, outcomes are user-centric. And I don’t need to convince you that user-centric products are more successful, right? This approach gives you freedom to decide at the right time how to solve a problem.
As much as possible, tie the outcomes to specific metrics so that you can prioritize them and also use those as a benchmark to compare whether you met the KPI objectives, learn in the process and iterate as needed. For example, I like expressing each item in the roadmap in the form of an Objective and Key Results (OKR).
4. The Roadmap is NOT a Release Plan
Release Plans specify what features, improvements and even bug fixes will be delivered at specific dates date as part of new versions of the product. In essence they are a sort of project plan for the next versions of the product.
If you read the previous tip you will immediately realize that Product Roadmaps don’t contains features. They can’t set dates either since they we don’t know yet how we will achieve the desired outcomes and hence we don’t know how long they will take.
I like to structure roadmaps in three sections:
This section lists the what the team is working on and whatever has been already defined and planned for development. In this case you can make an exception and be more specific about the features that will support the desired outcomes. The timeframe that would be covered would depend on the complexity of your product and how far ahead your team plans the work. It could be anywhere from a couple of weeks to a couple of months. 100% of the items listed in this section are expected to be delivered since they have already been scheduled.
- Under Consideration
This list the outcomes the team plans to work on next. Since you have already identified you want to work on these opportunities, you probably have a good reasoning behind that you can share as part of the roadmap. The timeframe covered by this section will again depend on the product. I try to imagine that we would work on those opportunities sometime in the next 9-12 months. Based on my experience, about 75% of the items listed in this section get actually addressed.
- Future Ideas
This section lists broad and bold initiatives you want to address in the future. This helps you share across the organization what you think the future looks like based on all the information you have now. Things not listed here are also important since it gives an indication of large initiatives the team is not even considering for the long term. If you don’t have any plans at all about the distant future, just remove this section; don’t waste time making it up.
5. Evangelize the Roadmap Across the Organization
For Product Roadmaps to be successful you need to keep your organization aligned around it. Make sure you spend time evangelizing your Roadmap and your Product across the organization. You explain to your colleagues how great your product is today and how awesome are the things to come. If you keep the rest of the organization aligned and you get them to buy into your vision and roadmap they will support you and your team to make it a reality.