Product roadmap: a term every product manager has a love-hate relationship with.
On the one hand, a product roadmap helps communicate your product vision and strategy to the world. It’s one of the few tangible outputs a product manager can produce without the help of a designer or an engineer.
On the other hand, a roadmap is often mistaken for a promise. And when you can’t fulfill it, which happens most of the time, frustration among stakeholders and customers follows.
No matter what your experience with product roadmaps is, they are an integral part of any product manager’s job. The ability to craft a good roadmap is an essential PM skill.
There are countless debates within the product community on which roadmap format is the best. The truth is that none of them is perfect. The best format will depend on your organizational culture, company stage, team setup, and the nature of your product.
In this guide, I’ll walk you through the anatomy of a product roadmap, the different formats it can come in, and some general guidelines on picking the right format. I will also share a customizable template you can download and use when building your own roadmaps.
What is a product roadmap?
Before diving into how to create a good roadmap, let’s define what a product roadmap is.
A product roadmap is a strategic document that informs your team about where you are going and the steps you’re taking to get there.
Although there are many ways to create a roadmap, here are a few non-negotiable principles you must follow for it to serve any purpose beyond just a fancy PowerPoint slide:
A roadmap is a living document
As much as everyone hates to admit it, no plan can ever withstand the test of time. Your user needs evolve, business priorities change, and estimations are always wrong.
There is no point in having a roadmap if it doesn’t reflect the latest reality. Update it when necessary.
A roadmap is not a release plan
How detailed your roadmap should be will always depend on the context, but there is a certain level of granularity you should not go past.
If you include every single bug fix and small improvement on your roadmap, then it becomes a release plan. A release plan is tactical. A product roadmap is strategic.
A roadmap is only a part of your strategy communication
A roadmap alone is not enough to communicate your product strategy. It has to be bundled up with other documents and forms of communication.
Many product roadmaps provide zero or negative value because their audiences don’t understand how they are supposed to be used. Therefore, it is a good idea to always attach a simple manual of sorts as part of your roadmap presentation to explain these principles.
Now that we understand what a product roadmap is, let’s talk about what it should look like.
What should a product roadmap include?
Every product roadmap has three elements:
- The “when”
- The “what”
- Categories
Each element can come in several variations. Let’s review them one by one:
The ‘when’
This is the horizontal axis on a roadmap that indicates the timeline of your initiatives. It can be displayed in the following formats:
- Calendar (monthly/quarterly)
- Now-Next-Later
Calendar (monthly/quarterly)
Mapping your initiatives on a calendar is the most common way of visualizing a roadmap. The calendar should be either quarterly or monthly. Any longer unit will be too broad, and any shorter unit will be too unrealistically precise.
The benefit of using a calendar-based roadmap is that anyone can understand it without further explanation. The downside is that whenever you give people a timeline, it will be treated as a promise, no matter how much you insist it is not.
Now-Next-Later
The Now-Next-Later roadmap was invented by Janna Bastow, co-founder of Mind the Product. The idea is to remove the false certainty of absolute dates by replacing them with relative timeframes:
- What are we working on now?
- What will we start next?
- What are we saving for the future?
A Now-Next-Later roadmap can help your organization escape the certainty trap. Instead of wasting time discussing when things will be done, it forces a discussion on what is more important.
However, while the idea of omitting dates makes sense in theory, it’s not always practical.
If internal stakeholders are always asking, “How long are we talking here? Weeks? Quarters?” — you might want to rethink whether the Now-Next-Later roadmap is bringing more focus or confusion.
How long should your roadmap be?
In most cases, your roadmap should focus on the upcoming six to 18 months.
It is very rare for a product team to produce a meaningful plan any further into the future. If you ask 10 product managers how long they tend to stick to their roadmaps, nine of them will tell you less than three months.
What about deadlines?
Generally speaking, you should avoid committing to deadlines because software product development is full of uncertainties. There is no point making promises when you can’t fulfill them.
Unfortunately, the real world has constraints we can’t bypass, which sometimes makes deadlines a necessary evil. Don’t be afraid to impose deadlines if you have to, as long as you understand that they are the exception, not the rule.
The ‘what’
These are the core items on your roadmap that represent what you will be working on. They might include:
- Features
- Non-feature initiatives
- Problems
- Outcomes
Features
A product team’s main responsibility is building features users want, so it makes sense that features make up the bulk of product roadmaps out there.
However, if you think features are the only thing that should go on a roadmap, then you would be wrong.
Non-feature initiatives
There are many activities that a product team has to perform to facilitate the creation of new features, such as user research, tech debt cleanup, internal tool implementation, design system creation, and product launch.
Including these non-feature initiatives on a roadmap can increase transparency and help educate the rest of the company about why a seemingly small feature can take so much time.
Again, this doesn’t mean you should put every task on the roadmap. Make sure to only include initiatives that offer strategic alignment.
Problems
A feature is a solution to a user problem, but you often don’t know what the best solution is ahead of time.
If you are not sure what features to commit to, it is best to simply state the problems you want to solve on a roadmap. This leaves you with more room to explore different solutions and gets everyone to focus on the core problems.
Outcomes
In addition to stating the problems you want to solve, you can also describe the outcomes you want to achieve on a roadmap.
These outcomes can be either user outcomes (e.g., “Users can find what they want easily”) or company outcomes (e.g., “Increase conversion rate by 50 percent”).
They don’t have to be written as quantitative metrics, but it always helps to have some objective criteria by which to define success.
Below are examples of items that might be included in a product roadmap:
Can you mix and match different items on a roadmap?
It is perfectly fine to combine multiple approaches on the same roadmap.
For example, you can:
- Share concrete features you will soon build and high-level problems you want to solve in the future
- Pair initiatives with the outcomes you hope they’ll achieve
Categories
You can use categories to group initiatives on a roadmap. They can be displayed as either swimlanes or tags.
Here are some common dimensions for categorization:
- Product area
- Nature of product work (feature, growth, product-market-fit expansion, scaling)
- Strategic pillar
You should not group initiatives by more than two dimensions on a given roadmap. After all, categories are there to help internal stakeholders digest your roadmap. Introducing too many concepts will do the opposite.
If you really have to, you can create different versions of the roadmap for different audiences.
How to pick the right product roadmap format?
Remember, a product roadmap needs to be tailored to your specific context. Blindly following what other companies (especially FAANG) do is like wearing an outfit tailored-made for someone else — it will look sloppy.
I wish there were a formula that any product manager could follow to put together a perfect roadmap, but unfortunately there isn’t one.
However, I will share some general guidelines:
- If your organization is culturally more traditional, has complex dependencies across different teams, or offers a time-sensitive product, sticking to a calendar-based roadmap will be your best bet.
- If your organization is still small or has a product-led culture, a Now-Next-Later roadmap could be a good option.
- If your product is in an established category where features don’t differ much between competitors, having only features on your roadmap is likely enough.
- If the nature of your work requires more solution exploration (e.g., growth or innovation teams), having problems or outcomes on your roadmap will give you more flexibility.
- If you work on a product so large that shipping a meaningful feature could take months or even quarters, you might want to break your work down into smaller chunks and include non-feature initiatives (e.g., user research) on your roadmap.
- If your audience cares more about how you are balancing your bets, you can group your initiatives by product area, size, or type of product work.
- If your audience cares about how your plan contributes to higher-level goals, group your initiatives by objective or strategic pillar.
- If you are a product leader managing multiple sub-teams, your audience will likely want to see initiatives grouped by team.
Customizable product roadmap template
Now that you understand the basics of product roadmapping, here is a customizable template you can use to craft your own bespoke roadmap.
Pick your preferred version and make a copy:
Focus on the substance of your roadmap
Although I’ve just spent the entire article talking about the “presentation” of product roadmaps, the most important aspect of a roadmap will always be the substance — the actual strategy and plan it is based on.
Shreyas Doshi, former product leader at Stripe and Twitter, put it well:
If you know where you are headed, a roadmap helps rally others (team, xfn partners, execs, customers) towards that journey.
If you do not know where you are headed, a roadmap will take you everywhere, and therefore, nowhere. https://t.co/L6Boxlvdw8
— Shreyas Doshi (@shreyas) September 16, 2022
I recommend that you spend the majority of your time perfecting your strategy — which is a big topic on its own.
Once you have a solid plan, figuring out how to present it will be a much easier task.
A version of this article was originally published on LogRocket’s blog.
