What Information Goes on a Product Roadmap?
What should you actually put on your product roadmap? It’s up to you, but here are some best practices from one PM to another.
A product roadmap outlines the direction and main features you’re planning to build for a product or a suite of products. It typically shows how you’ll implement the product strategy over a period of time.
Done right, product roadmaps help you align stakeholders, including product teams, executives, and customers, around the product vision and strategy. The process of product roadmapping helps you prioritize new product features so that you use development resources efficiently.
Cool—so what actually goes on the roadmap? What do you include, and what do you leave for the product vision, strategy, or release plan?
In this article, I’ll go through what you should keep on the product roadmap and what you should skip.
(Looking to learn how to display on a roadmap? Check out this post on elements of a product roadmap—it covers bars, containers, swimlanes, milestones, and more.)
What are the goals of a product roadmap?
A product roadmap will be effective when it does the following thing:
Communicates strategy. It should explain to your teams what you’re planning to build and implement your company’s product strategy.
Stakeholder alignment. You want your roadmap to help your teams get behind your plan so everyone works together more effectively.
Engage customers. Roadmaps can be useful to give to customers or prospects so they know what they can expect to see in your product in the near future.
Some of the above goals may be more important to you than others. That’s okay—it’s yours. Build your roadmap in the way that is the most useful to you.
What information goes on a product roadmap?
Product roadmaps are a bit like backyard gardens: they’re personal and flexible. Sure, there are some guidelines about how you plant it, but you can really make them whatever you like (there’s no HOA or Strata to worry about here).
So the main principle is this: include the information that makes sense to you.
Having said that, here is the information that’s useful to put on your roadmap to keep your teams, customers, and other stakeholders informed and aligned about your priorities.
Note: Some of these ideas overlap. For example, “Themes” are often structured as “Goals”. Again, that’s okay—include what makes sense to you.
In product management, themes are broad, high-level concepts that capture the essence of a number of features. They can help to group related features, initiatives, or goals together and provide a framework for prioritizing and communicating the product strategy.
When you structure your roadmap by grouping features or product ideas into strategic themes, you’re using a theme-based roadmap.
Themes represent broader objectives and can include several different product features. Source.
Examples of themes include:
Improve onboarding flow
Integrate product better with other apps
Each theme could have a number of different features associated with it.
Why include themes on your roadmap? Lots of PMs like using themes because:
It helps tell a clear story and answer the question, “Why are we building the product like this?”
It can make prioritization easier because it can be easier to identify which theme is more important than which individual features are most important
Themes help focus teams on bigger picture strategy rather than individual features
2. Goals, outcomes, or OKRs
Some people like to include business goals on their roadmap. When they do, they’re creating a goal-based roadmap (or goal-oriented roadmap—also sometimes called an outcome-based roadmap, although others say those are different).
Including goals, outcomes, or OKRs help you tie the features on your roadmap to your larger strategy. Source.
Examples of goals could be:
Acquiring new customers
Future-proofing the product by reducing technical debt
Why include goals on your roadmap? Including goals and outcomes has a few potential benefits.
It focuses everyone on the specific value a product will generate and helps reduce some conflict over the priority of individual features and make it easier to get buy-in.
It’s consistent with the objective and key results (OKR) framework, which is useful to many organizations.
When you focus your roadmap on features, it can be interpreted as a commitment to building those features rather than a high-level plan.
Identify the overarching strategic goals that drive the product's development. This helps provide context for the planned features and improvements.
3. Features and improvements
Features are the specific functionalities you could build into your product. Features are one of the most important pieces of information to include on your roadmap because they tell your Customer Success, Sales, Engineering, and Marketing teams what you’re planning to build next.
When the focus of a roadmap is on the features you’ll build, we often call that a feature-based roadmap or just a feature roadmap.
You’ll almost certainly want to put the features that you plan to build on your roadmap. Here are some features on an example roadmap in Savio.
You’ll probably want to list the specific features, enhancements, or bug fixes that are planned for the product. Provide a brief description and their priority so key stakeholders can see what's most important.
Examples of product features could include:
Connect to survey software
Add a user onboarding checklist
Create a sales forecasting model
Why include features on your roadmap? Beacuse it helps your teams know what features are coming down the pike.
Note: Feature-based roadmaps are sometimes criticized because they don’t encourage you to think of the larger product vision when you’re building. Instead, you can fall into being a “feature factory” where you prioritize shipping new features at the expense of making sure the features you’re creating are valuable to your users and fit your overall strategy. Your roadmap essentially becomes indistinguishable from your product backlog.
In my view, that doesn’t mean you shouldn’t include features on your roadmap—you should. Just make sure that they’re serving your larger product vision and strategy (and build those into your roadmapping or prioritization process).
Remember, the roadmap should communicate the why behind your feature choices, not just the features themselves.
4. Context and customer feedback data
For me, one of the biggest uses for feedback is to prevent conflict around which features to prioritize. That’s why I suggest that you include the background context that led you to choose some features for your roadmap over others. At Savio, we call this an “evidence-based roadmap”.