This a great question, and something that took me awhile to master. As product managers, we have to communicate with many audiences in varying levels of detail. A high-level roadmap for a board presentation looks very different than a detailed features roadmap sharing status.
The first step is understanding the right level of information for your audience. Then you can choose or create the roadmap that best serves your needs.
I know this because I'm now lucky enough to work and speak with thousands of product managers who use Aha! Before that, I spent three years leading a product team at a SaaS company, where I needed many different roadmaps as the business grew and needs changed.
In that job, I used these roadmaps most often:
- Strategy roadmap (for board presentations and high-level planning)
- Release roadmap (for sales and marketing)
- Features roadmap (for product team updates)
While different organizations will use different roadmaps, here is a breakdown of common roadmap examples and how they are used:
It all starts with strategy. Before you start planning out features and releases, you should know what high-level goals and initiatives you want to accomplish. Your strategy roadmap guides the more granular roadmaps you use throughout the year.
Organizations with many complex product lines and products often use the portfolio roadmap, which allows you to communicate updates across several businesses, divisions, or product lines.
The more products and product lines that a team manages, the harder it is to stay in sync. As the product team and business grows, it can be more difficult to understand how each product relates to the overall business strategy and key initiatives. That is where the portfolio roadmap can be a real asset.
As you bring a product or new release to market, the releases roadmap can help you plan and manage work that happens across the business. This roadmap is also helpful when managing a suite of products that need to be released at the same time.
With a releases roadmap, teams working independently can see how product releases relate to each other and highlight dependencies.
This roadmap helps you communicate how the planned work will impact the high-level strategy. Because this roadmap is the most granular, I used it with my product team when tracking progress and dates. You might have a features roadmap for your internal team as well as an external one for sharing external dates with customers.
There is not one roadmap example that is one-size-fits-all. And a three-person startup will have to communicate very different information than a multinational corporation.
Product managers need many different ways to visualize their work, show what is coming next, and explain why their team is building specific features. Luckily, there is a roadmap that is right for the task.
Here are 16 common roadmap examples along with free Excel and PowerPoint templates. You can download the templates (without signing up or providing an email which is always nice) and then edit and use them however you like. The examples and free templates include some of the most commonly used roadmaps:
I hope this helps — enjoy!
Roadmaps.. fantastic topic, and one of the most important tools for a product manager.
Before deciding on a template, we first need to establish and understand what a roadmap is.
What a roadmap is:
A roadmap is a communication tool. As such, the litmus test for a good product roadmap is that it’s visual, accessible and clear enough for anyone to scan for answers to the following questions:
- What are we doing?
- Why are we doing it?
- How does this tie back to our OKRs?
What a roadmap is not:
A roadmap is not a release plan. A roadmap should not, at any point, outline dates for features that have not been spec'd out or had resources committed by your development team. There is no such thing as a 'technology' roadmap or a 'release' roadmap - these are all just other names for a release plan.
A release plan should only therefore include dates for features that have been validated, acknowledged, and spec'd out by your product team. A release plan is your development team's execution plan for the strategy outlined within your roadmap.
Why is this important?
As Teresa Torres said:
We need to let go of the idea that we can enumerate a list of features that represents what we’ll do in the future. This idea is absurd. Rather than sharing feature lists with the rest of the company, we should be communicating how we will make decisions.
What does a product roadmap look like?
If you haven't heard of theme-based roadmaps, you should check them out.
A theme-based map replaces the dates with time horizons, made up of three columns: Current, Near-Term, and Future. Slack uses in their own roadmap Now, Next, Later - but the same concept is there. Having time horizon's allow you to have a bird’s eye view of your priorities. Those are always subject to change – especially out in the future which you can’t meaningfully plan for today.
The point is to leave room to adjust to change. If something was current, but now you want to push it back, you can.
I could write an entire e-course about how to work with roadmaps (mind you - I have!) but for now I will leave it at that. Happy to answer any questions about theme-based roadmaps at any time.
This blog post I wrote talks about a product roadmap template and how to build it from scratch to meet your team's needs. Hope it helps!
We recently collected the best roadmap templates we could find and put them all in one place: https://usefyi.com/templates/roadmap-templates/
I hope my answer helps!