Product roadmaps can be extremely helpful tools in any product manager’s arsenal. However, if used incorrectly or without intentionality, they could be potentially detrimental for you and your development team(s).
Creating a great product roadmap isn’t something to take lightly or create in haste. It takes time, patience, and clear communication to ensure you craft a roadmap that accurately reflects your team’s priorities to internal stakeholders, external stakeholders, and potential customers.
Product roadmaps are living documents that should never be thought of as ‘final.’ In an agile environment, the more that you and your agile team learn, the more changes the product roadmap will have throughout the product life cycle.
This should never be a document that is created near the beginning of the product development process and set in stone, but rather a document that provides direction to your team and stakeholders to get buy-in from everyone.
We’ve also created a product roadmap template that you can download and edit as you create your own product roadmaps.
What is a Product Roadmap?
An agile product roadmap is a document that communicates the strategic direction of a new product, existing product, or organization to align key stakeholders, marketing teams, sales teams, product teams, and sometimes even customers on what will be delivered. It’s part of the product strategy or product plan.
A great product roadmap communicates the ‘why’ and the ‘what’, whereas a product backlog communicates the ‘how.’ In order to deliver a great product roadmap, it must be: easy to understand, clear, abstracted from detail, and flexible.
No matter what type of roadmap you create, it should be centered around problems to solve, not solutions to those problems. It’s very easy to fall into a trap of creating a roadmap that’s solely focused on new features and when they’ll be delivered because that’s usually what makes stakeholders most comfortable. However, it removes autonomy from the team to find solutions to the problems that are outside of previously defined solutions.
Depending on how the roadmap is being used, you might create an internal roadmap or an external roadmap. Here’s the difference:
Internal roadmap: These roadmaps may be created for executives, the development team, or the sales team. Depending on the audience, the roadmap will focus on specific aspects, such as alignment with company goals, product details, or customer benefits.
External roadmap: These are created for customers, and as such should focus on the benefits of the product for customers.
What if my roadmap is dependent on other product teams delivering their work first?
Use your roadmap as a communication tool for alignment with that product team. If you’re dependent on their work (e.g., API development), ensure that’s part of the plan — either shown as a problem to solve in their roadmap, or by creating a higher level roadmap that encompasses all work across teams.
Types of Product Roadmaps
There are many different ways you and your team can build a product roadmap. Each type of product roadmap serves a specific purpose that should match the needs of your team, stakeholders, and customers.
The three types of roadmaps listed below are status-oriented, theme-oriented, and outcome-oriented roadmaps. There are a variety of other ways to create and orient roadmaps, but these three are the most helpful in my opinion, especially for generating alignment.
A status-oriented roadmap allows everyone to better understand where the team is currently at, without necessarily committing to any kind of time frame. The biggest benefit of this type of roadmap is its simplicity.
It’s organized into three columns that are based around the status of each deliverable — now, next, and later. It helps with prioritization, and there’s no question around what the team may be working on at any given time. It also gives room for the next and later columns to shift.
Here’s a quick outline of how a status-oriented roadmap could be structured:
Whatever the team is focusing on for the next couple of sprints.
This section should identify clear business objectives/problems and shouldn’t change.
Whatever the team should be focusing on several weeks out.
This section should be roughly defined and a little less likely to change than the “later” section.
As you can imagine, this is essentially what’s in the icebox for now (typically a few months out, depending on your sprint length).
This section may be the most loosely defined and subject to change.
Just because this version of a roadmap is simple, doesn’t mean it lacks intentionality. Each item (typically an epic) shown on this roadmap should align to a higher level organization goal or strategic objective (e.g., Increase ARR by 5%).
Another upside to this type of agile product roadmap development is that it’s easy to set up in virtually any tool that your team uses. Anywhere you can create three columns, you can display the information needed.
Theme-oriented roadmaps are a way to communicate the value that will be delivered to the users, without describing exactly what the team will deliver within that theme. Keeping a roadmap this high-level is particularly useful to stakeholders and teams to align on the direction of the product and the product vision without getting too far into the weeds.
These product roadmaps keep the team focused on solving the larger problem at hand, and anytime something else is brought up, it’s easy to ask one another if it fits into the theme of the current time period. Most of the time, theme-oriented product roadmaps are quarterly based.
Theme-Oriented Roadmap Implementation
An example of a roadmap item on a theme-oriented roadmap could be “improve the plant care experience” for a plant care app. However, before defining the themes, it’s important to understand the product strategy and overall short-term and long-term goals you need to be driving toward.
When creating the product roadmap, your themes should be aligned with the overall strategic roadmap of the organization.
Once your stakeholders align on those themes, you and the team can nest epics beneath those themes. For example, an epic beneath the ‘improve the plant care experience’ theme could be ‘Water Schedule UX Improvements’.
The nesting of epics beneath a theme allows the product team to get a better understanding of how the work ties to the larger business goals set out by the organization. A great example of an agile product roadmap tool that does this well is ProductPlan.
An outcome-oriented roadmap is very similar to a theme-oriented approach. Where it differs is what’s at the highest level; an outcome. An outcome is defined as “something that follows as a result or consequence.” By agreeing on the outcomes you and the team will be driving toward, it leaves full power to the team to define the solution.
Defining the solution before the problem is a big problem with most roadmaps we see these days. Instead, flipping it on its head can create not only a healthier environment for your team, but it will keep stakeholders happy as well.
Why Stakeholders Like Outcome-Oriented Roadmaps
Most stakeholders don’t really care about a specific feature you are working on implementing. Instead, they want to understand what problems the team is working to solve.
For example, an outcome that a product team may be working to solve could be, “Improve our day-7 app retention rate by 10%.” Then, it’s up to the team to figure out how to make that happen and define the work to be done.
This approach truly gathers alignment across the board (stakeholders, executives, team members), and while it’s not something you may always want to share with customers, that’s okay. Most of the time, sharing small updates of what’s coming is enough.
When you have full alignment for the outcome you’re working to move toward, you can avoid having the team work on product features that don’t move the needle.
It can also create quicker learning loops for your team by quickly understanding when something didn’t work so the team can dig deeper to see why whatever was implemented didn’t change user behavior.
How To Build A Product Roadmap
Agile product roadmaps often go awry when they’re not built properly. No matter the approach that’s chosen for your roadmap, there are some general principles that will ensure your roadmap is of high quality.
The steps to take when building an effective roadmap, generally speaking, look like this:
Understand the organizational/product goals
Communicate those goals to your team
Work with your team to determine how your product can help reach those goals
Create a draft roadmap that aligns your team’s approach with the organizational goals
Ask for feedback from team members
Present roadmap to stakeholders
As a product manager, you are there to help facilitate the creation of the product roadmap, not dictate it to your team. You can start by ensuring you have an in-depth understanding of the overarching organization/product goals that relate to the product you’re managing.
Then, facilitate several sessions with your team to determine how your product is going to help the organization/product reach those strategic goals.
Once your team aligns on a draft roadmap, sit on it for a few days to let everyone process. Once that period has passed, ask for feedback from the team one more time and make adjustments as needed.
Then, present the roadmap to your stakeholders. You’ll have the confidence to present, because your team has aligned the roadmap with the organization/product goals, which should, in turn, please your stakeholders.
Additionally, by keeping your roadmap at the right level of abstraction, you avoid going into too much detail on specific features that are or aren’t being addressed.
What To Not Put Into A Roadmap
There are many things that could be tempting to include in your roadmap, perhaps even some that are being requested by your stakeholders and/or customers. It’s important that you remain objective, advocate for the product team, and don’t set dangerous expectations for them. You want your product team to be happy, so that everyone else is happy.
Set the expectation early and often that a roadmap is not the same thing as a timeline. A product roadmap communicates the strategic direction the product is taking; it’s directional. Giving a general idea of time is okay (e.g., Q1 2021), but work to avoid giving exact dates. That’s a release plan and comes once you’ve nailed down a release and release dates. This ultimately gives the team the room they deserve to deliver the desired results.
Additionally, don’t worry about including ‘non-value’ items in your strategic roadmap. These items can include things like technical debt, DevOps work, bug fixes, etc. Hopefully, you’re avoiding a feature roadmap (though there can be a time and place for that as well), so this probably won’t be a problem.
It should always be assumed that a certain degree of your team’s time is being put to these non-value features. If one of your outcomes is to improve the performance of the app, then naturally your team will work on improvements your customers may never see (e.g., non-value features), so showcasing what exactly that work is within your roadmap isn’t important.
There are many different product roadmap tools out there that will help you communicate your roadmap effectively. No matter what, choose your roadmap approach first, and then find a tool that fits your needs.
For example, Jira offers the ability to create Jira roadmaps through the software, but those roadmaps may not necessarily fit your needs, so you might look for something that integrates with Jira and that better fits your needs. You might also create roadmaps in Excel or PowerPoint, but these will likely be more cumbersome to update as the product grows and evolves.
If you choose product roadmap software before you determine your needs, you’ll end up creating a roadmap for how the product roadmapping software you choose wants you to create a roadmap, which may not be best for you, the team, and/or the product.
It’s Your Turn
As you’ve seen within the above examples, there’s a lot of crossover between various types of roadmaps. That’s completely intentional — you can pick and choose elements from each to create your own version of a roadmap. Perhaps, instead of just a status-oriented roadmap, you combine that with an outcome-oriented roadmap because the timescale that matters most is what’s being worked on now vs later.
What are your thoughts on roadmaps? Are there specific areas that you’ve struggled with either in regard to roadmap creation or communication with stakeholders?
If you find yourself in a rut of only being able to produce feature-driven roadmaps, try one of the roadmap types I’ve listed above and see how that changes the dynamic of your team(s). I’d love to hear what happens when you unleash your team to solve problems, rather than just take orders.