A product roadmap is a strategic document that defines the product vision and aligns teams and stakeholders on the direction of the product. A product roadmap is a guiding document that should be updated with new and relevant information based on the latest customer research, internal and external feedback, etc.
Usually, product managers are responsible for creating the roadmap and keeping it up-to-date with the latest developments. The goal of the product roadmap is to set priorities across the organization and ensure teams work towards common goals.
Many times, a product roadmap is mistaken for a backlog of tasks or features a team wants to build and deliver. This is one of the biggest misalignments of creating a roadmap, and where many product roadmaps fall short.
The difference between a backlog and a roadmap is in their focus. A backlog is centered on a short-term plan, whereas a roadmap tells a bigger story about what the product team is doing to achieve a set of key objectives and outcomes. Depending on the organization, a roadmap might feature initiatives by many different teams, all working towards the same vision. Both internal and external stakeholders are involved in the process of creating a product roadmap and setting product goals.
In this guide to product roadmapping, we'll look at the difference between feature vs. theme-based roadmaps, how to build your first product roadmap, how to prioritize items, and how to use and update your product roadmap. Let's get started.
Product roadmaps come in many different shapes and sizes. There are different types of product roadmaps, and though they might look the same at first glance, they tend to differ in some important aspects. Let’s look at two common types of product roadmaps, feature vs. theme-based roadmaps, and understand the advantages and disadvantages of each.
A feature roadmap is the most common type of roadmap that organizations create. They offer a clear output of the exact features that will be released and usually include a defined timeline.
Generally, most departments in a company, such as marketing or the C-suite, prefer feature roadmaps because they offer clarity around launch dates and set clear intentions for the product strategy.
On the other hand, feature roadmaps are usually determined in advance—most are yearly- or quarterly-based—so they tend to produce expectations about the features that will be released and when. As such, these types of roadmaps don’t allow for much flexibility or creativity, and introducing changes after a feature roadmap is created becomes difficult.
Feature roadmaps can often lead to frustration and stress as the product and development teams struggle to deliver a feature-set before a deadline. Feature-based roadmaps don't account for the reality of the product development process when edge cases start popping up, increasing the amount of work required to get it done. This usually results in deadlines getting pushed, leaving expectations unmet and lowering team morale.
On the other hand, theme-based roadmaps are based on strategic themes the organization wants to tackle in a given time period. A theme is a problem area the business organization wants to work on. Theme-based roadmaps are specific about what the problems are, but leave room for creativity on how to solve the identified issues and what features would address them.
An example of a theme is: “Improve the first interaction our users have with our platform and increase activation.” Based on a theme like this, features will still be planned, but compared to feature roadmaps, teams have more flexibility and space to think about the problem and figure out the best solution.
A theme-based product roadmap allows for flexibility and is driven by customer feedback, creativity, and has room for change, while still addressing the most important themes the organization needs to work on. Later in the guide, we’ll see how a theme-based roadmap interacts with timelines by using the Now, Next, Later framework.
Let’s now look at why having a flexible, theme-based roadmap is advantageous, and how to build your first product roadmap.
A product roadmap should serve as an alignment tool for stakeholders across your organization, inspire your team, and help you showcase your product vision and strategy. You should be able to adjust your product roadmap as you uncover new learnings.
How do you achieve this flexibility? By creating a theme-based, agile product roadmap to begin with.
Building software is hard. Rigid roadmaps with strict dates tend to create a lot of stress and high expectations. For this reason, product managers that are able to create flexible roadmaps while still setting a clear product strategy will have an easier time managing key stakeholder expectations and delivering value to the customer.
A product roadmap should be a living document that evolves as you and your team do. When you gain new insights from customer feedback or product experiments, you should be able to bend your roadmap to include these new findings. A good product roadmap shouldn't hold you back when you need to change or adapt. Hopefully, it even inspires you to do so.
Changing your roadmap is not a bad thing. Prioritizing what the team should work on based on new customer findings is one of the key responsibilities of the product manager.
Things evolve fast in tech. We’re able to push new features faster than ever, rapidly adopt new development frameworks, and we’re always evolving the processes of building products.
When it boils down to it, shipping customer value is what counts. And that’s where flexible product roadmaps help.
Creating a roadmap is no easy task. There’s a lot of work that goes into researching what the team should work on and what the product strategy should be. As a product manager, you’re constantly trying to prioritize the highest-value, low-effort initiatives to get your team and internal stakeholders to achieve their goals.
To kick things off, let’s run through a five-step framework of the discovery process we use at Maze that will help you to fill in your roadmap with high-impact initiatives.
First, you should start by understanding the business goals and objectives that have been set by the organization, such as the company mission and strategy. Understanding the long-term vision will help you to clarify what you need to do in the short-term.
Additionally, if your organization has already set business objectives that need to be reached by the end of the year, it will help you to define the product roadmap and prioritize the product plan. Getting clear on the company objectives will give you clues on where to focus during product discovery.
These objectives are usually set at the founder or executive level, so involving stakeholders early in the process is a must. This means taking a top-down approach to product development by understanding what the business set out to achieve.
However, don’t assume that just because the company vision has already been set, there’s no room for adjustment. Here’s an example from the previous Head of Product Management at Asana, Jackie Bavaro, on how they included both top-down and bottom-up initiatives across their organization:
“At Asana we wanted to get the best of both worlds: a clear strategy where everyone can connect the dots from their daily work to the company mission, and a collaborative process where the people closest to the work can influence our direction.”
As product managers, we want to build with intention, which means knowing what our desired outcome is so we can model our actions against it, and work our way backward. Starting with the desired outcome, usually a strategically-chosen and measurable objective will help you create the product strategy: the plan that executes on the product vision.
Let’s take a concrete example, one I actually tackled when I was a PM at Typeform: reducing customer churn. When we know the desired outcome, we can plan our product roadmap accordingly, and explore solutions to tackle this issue. Usually, we set a period of time, such as six or twelve months to get to that outcome.
Now that we know the outcome we want to achieve—reduce customer churn—we need to figure out what customer behavior drives change to the desired outcome. When I was at Typeform, we analyzed internal data and found out that customers who integrated Typeform with other apps through Zapier were less likely to churn.
With this in mind, we identified the behaviors we needed to encourage to get to the desired outcome. According to the data we had, the behavior we needed to encourage was integrating Typeform with other apps. This process is by no means easy, and it might take a while to nail it, but it’s worth it.
Once you have an understanding of the behaviors that drive your desired outcome, you can start looking for customer problems that impede those behaviors. It could be likely that users are experiencing issues or don’t find value in a particular feature. In the Typeform example, the problem was that we didn’t offer native integrations. So, we looked at the issues people experienced integrating via Zapier. This ended up being a starting point for the next Design Sprint when we tried to figure out the simplest way to get people to integrate Typeform with their favorite apps.
We now have a lot of information to start coming up with ideas to tackle the customer problems we identified, helping us to reach our goals. At this point, we need to start doing user research and product discovery. Customer interviews, surveys, prototyping, experiments, and user testing are among the methods you can use to understand customer behaviors and get user input.
Depending on the resources you have at your disposal, these methods can be quick and iterative, or you can spend a defined period of time testing and validating hypotheses. The result of this discovery work, combined with the company strategy and the product vision, should give you all of the building blocks to create a strong product roadmap.
Here’s the TL;DR of the process from start to end:
1. Understand the business's strategic objectives. Learning about the company vision and objectives will help you pinpoint the themes for your roadmap, and create an effective product roadmap that addresses all stakeholder objectives.
2. Define a measurable outcome. In the example above, our desired outcome was to reduce customer churn. By starting with your goals, you’ll be able to work backward to build your product roadmap.
3. Map the behaviors that drive that outcome. To achieve a particular goal, you need to identify the customer behaviors that will drive it. In our example, we found out that customers that integrated Typeform with other apps were less likely to churn. This was an important behavior that helped us achieve our goal and create our roadmap accordingly.
4. Discover the problems that prevent users from adopting those behaviors. That means understanding what’s stopping customers from adopting the behaviors you want them to. A great place to start is mapping out the funnel where these behaviors occur, and analyze each step carefully. Questions you might ask are: Is there a large drop-off somewhere in the funnel? Why is that? You explore that further by talking to customers who went through that funnel but didn’t behave how you expected them to.
5. Hypothesize and research to get customer input. Throughout the process, you need to run customer interviews, surveys, refine the problem, and do usability testing to uncover the problems your customers are experiencing so you can define potential solutions.
When you figure out the goals of your customers and what's stopping them from achieving those goals, that’s where great product roadmaps and solutions are born.
A product roadmap usually consists of themes or features lined up in sequential order, and a timeline of some sort. Prioritization is important because it helps you create a product backlog you can act on now, while also setting the big picture to achieve your company goals.
In this section, we'll look at how to prioritize items in your product roadmap to make it as effective as you can.
One of the most clear-cut ways to prioritize items on your roadmap is to look at the potential impact an initiative can have versus the effort the team will put in. There are many different frameworks to prioritize, but one I recommend is the ICE framework, which stands for Impact, Confidence and Ease.
Start by quantifying the Impact on a scale from one to 10. For example, if your desired outcome is to increase new monthly recurring revenue to 100k, the scale will look like this: 10 would equal 100k, five would correspond to 50k, and so on.
Next, map the Confidence score according to the scoring system defined by Itamar Gilad. Finally, map the Ease score by equaling 10 with less than a week’s work, and one corresponding to more than 26 weeks. With these examples, you can map out everything in between.
When you have a number for each you multiply them to get the ICE score.
[Impact] X [Confidence] X [Ease] = ICE Score
Once you have everything set up, it’s time to get to work based on the Hypothesize and Research step mentioned above. Collect lots of ideas from stakeholders, data analysis, customer research, etc., and start running them through the ICE framework. Use back-of-the-envelope estimations to calculate the impact an initiative could have, and prioritize accordingly.
Instead of having a rigid timeline with fixed dates, a better way to set timeframes in the product roadmap is to use the Now, Next, Later framework. According to former SVP of Product at Foursquare, Noah Weiss, this methodology provided the company a simple way to prioritize work without the drudgery.
Now is the most obvious category, and includes what the team is working on at the moment. Next is where a list of initiatives, themes, or features that have been well-researched are included. Later is the category where all long-term plans are set, but that might change in the future.
Here’s how to determine what goes into each category.
A great way to keep the product roadmap updated is to use it during team meetings, regularly discuss it with stakeholders, and keep it on-hand during the development process. Here’s two other things you can do to keep your product roadmap updated.
Updating internal stakeholders on a weekly or bi-weekly cadence on what has changed and what has stayed the same is key. During meetings, the product roadmap acts as the guiding document that aligns everyone on what is happening right now and what’s coming next.
The format of the items on the roadmap is important because it defines the work your team will do, and the amount of flexibility they will have. You can use a thematic approach when defining the product roadmap items, such as Improve the signup flow.
Or, you can create cards that go into more detail about the feature, e.g., Implement Google's one tap signup. Each approach has its own pros and cons; finding the one that works best for you is important.
One way I like to approach creating items is by placing thematic items in the Later column, as discussed above. Once an item moves into the Next or Now category, they start to become more granular and actually describe the features the product team will develop.
Other properties you can add to your cards are:
Now you're ready to create effective product roadmaps that will deliver value to your customers, and keep everyone in your team aligned on the product strategy.
Remember, product roadmaps should guide your work and be of use to you and your team throughout the product development process. For this reason, creating agile, flexible product roadmaps will help you incorporate customer feedback as it comes in, and adjust the roadmap accordingly is best.
Keeping your product roadmap updated is easier from a centralized place. This is where Slite comes in: a home for all of your product requirements documentation and your roadmap. You can link the features on the roadmap to pages of research or other information that's useful to have.
We've included a product roadmap template for you to start building a product roadmap in Slite.
Senior Product Manager, Maze
Over the past seven years, Arjen has been obsessing about building great products in a diverse range of start-ups. He started his career in a bootstrapped startup in Amsterdam and moved to Barcelona a couple of years later to work at Typeform, and later N26. Now he’s working fully remote at Maze, on a mission to make user testing affordable, easy, and accessible to all product teams in the world.