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.

1. Themes

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
• Improve usability

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:

1. It helps tell a clear story and answer the question, “Why are we building the product like this?”

2. It can make prioritization easier because it can be easier to identify which theme is more important than which individual features are most important

3. 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
• Reducing churn
• Increasing engagement
• Future-proofing the product by reducing technical debt

Why include goals on your roadmap? Including goals and outcomes has a few potential benefits.

1. 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.

2. It’s consistent with the objective and key results (OKR) framework, which is useful to many organizations.

3. 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”.

Savio roadmaps let you display customer feedback data on your roadmap, including the number of requests for a feature, the MRR associated with it, and more.

For example, you could show metrics like:

• The number of customers that asked for each feature
• The cumulative MRR of customers that asked for each feature
• The cumulative opportunity revenue associated with each feature

Why include context on your roadmap? Because it allows you to justify your decisions based on customer needs.

Imagine you’re in a roadmapping meeting with your sales team and they ask you why you’re building calendars instead of better reporting. You can use the context from your roadmap to explain and justify the decision. You can show your colleagues that the features you chose have more requests and higher revenue associated with them—they’re more popular and valuable.

Read more: 8 Feature Prioritization Methods Designed for PMs

5. Timeframe

Most roadmaps include a rough timeline for each feature. Some stick with a very vague, “now, next, later” structure. Others provide full Gantt chart details with specific dates assigned to features.

Why include timeframes? Because stakeholders usually want to know when features will be built. It’s also useful for your internal teams—like Sales and Support—to understand how to talk about future features with customers or prospects (and if they should).

Tip: I suggest keeping time frames relatively vague rather than giving specific dates. The reason is that roadmaps are planning documents and can change. Stakeholders can sometimes interpret specific dates as a commitment and expect the features, rather than see them as a rough guide.

6. Status or progress indicators

You can use visual cues (e.g., color coding, bars, and icons) to show the current status or progress of each item on the roadmap. These can help communicate the current state of the roadmap and the progress that has been made toward achieving its goals.

For example, you could include:

• Progress bars
• Milestones
• Color codes

Why show status on your roadmap? Using status and progress indicators can be beneficial for several reasons.

1. They can help stakeholders quickly understand the current status of the roadmap and what progress has been made. This can help to build trust and confidence in the product development process.

2. Indicators can help to identify areas where progress may be lagging, allowing teams to take corrective action and ensure that the product roadmap stays on track.

3. Indicators can help to motivate team members by providing a sense of accomplishment and progress toward achieving the product vision.

7. Dependencies or relationships

Feature dependencies refer to the relationship between features or initiatives, where one feature or initiative may depend on another in order to be completed successfully. If certain features or improvements are dependent on others, these relationships can be indicated on the roadmap.

For example, a new feature may require changes to the underlying architecture of the system, so the feature would be dependent on the completion of those more foundational changes.

Why include dependencies on your roadmap? Visualizing feature dependencies and relationships on a product roadmap helps product teams gain a better understanding of the overall structure of the product and identify areas where coordination or prioritization may be needed.

8. Resource allocation

Some teams include information about the way that time, budget, and personnel resources are allocated to different initiatives or features on the product roadmap. Resource allocation information can be a useful way to ensure that teams are aligned around the product vision and that resources are being allocated effectively to achieve the product goals.

For example, a roadmap could include:

• Time allocation (development team hours) for each feature
• Budget dollar amount required for feature costs
• Required number of employees for each feature over a given time
• Story points for agile development frameworks

Why include resource allocation information on your roadmap?

1. Improved coordination and planning. Seeing the resource requirements for different initiatives or features helps teams coordinate and plan for the resources they need.

2. Better resource allocation. When you identify the areas where resources are needed most, you can allocate resources more effectively.

3. Increased transparency. Making resource allocation information visible to stakeholders helps increase transparency and accountability, which in turn can build trust and confidence in the product development process.

9. Disclaimers

Finally, you may wish to add disclaimers to your roadmap. Disclaimers are statements that clarify the level of certainty or accuracy of the information presented on the roadmap. These statements can be used to acknowledge the limitations of the roadmap and the inherent uncertainty of the product development process.

For example, you could include statements like,

• "This roadmap is subject to change."
• "The information presented is based on current knowledge and is subject to revision."
• "The roadmap should not be construed as a guarantee of future performance or results."

Why include disclaimers on your roadmap?

1. Managing expectations. Disclaimers can help remind readers that your roadmap is a plan and not a commitment. This can help to avoid misunderstandings or disappointment if the product roadmap does not proceed exactly as planned.

2. Acknowledging uncertainty. Disclaimers can help to emphasize that the product development process is inherently uncertain and subject to change.

3. Providing context. Disclaimers can provide context for the information presented on the product roadmap, helping stakeholders understand the assumptions or uncertainties that underlie product decisions.

What should you leave off the roadmap?

What doesn’t go on a roadmap? Here’s a short list of information you’re best kept to yourself.

• Speculation. Try to ensure that everything published on a product roadmap is realistic and based on current knowledge. Speculative or overly optimistic information that is not supported by data or analysis may create unrealistic expectations or lead to disappointment if the roadmap does not proceed as planned.
• Detailed technical specifications. This isn’t the place to put feature requirements or detailed specs. While it is important to provide enough information about the product to communicate its vision and goals, you don’t need a super granular level of detail for a roadmap.
• Operational details. While operational details such as team workflows, sprint planning, or individual tasks are important for the product development process, they may not be relevant or helpful for stakeholders who are focused on the overall product vision and strategy. You can leave them off.
• Proprietary or confidential information. You might be showing your roadmap to customers or other external stakeholders. In that case, do a quick check to make sure it doesn’t include sensitive information such as intellectual property, trade secrets, or confidential business strategies. You may even choose to show a small selection of your planned features, but not all of them—roadmaps can be a gold mine for your competition.

By being selective about the information that is included on the product roadmap, product teams can ensure that stakeholders are focused on the most important aspects of the product development process and that the product roadmap is clear, concise, and effective.

Product roadmapping tools

Ready to get started creating your product roadmap? Check out this list of roadmapping tools to scope out some options.

Up next: Elements of product roadmaps: How to display roadmap information effectively

(Thanks to these articles for inspiring some of the ideas presented here).

Note: If you are looking for another deep dive into the world of product management, take a minute to check Savio's Complete Guide to Feature Prioritization.

Last Updated: 2023-05-09

Want more articles like this?

Product Leaders from Slack, Zapier, and Appcues read our newsletter to delight customers, lower churn, and grow revenue.

Send me more like this

Unsubscribe anytime.