How To Build A Roadmap: Guide and Tips
Ready to build your product roadmap? Here’s how.
It’s roadmap time, baby.
We’re ready to roadmap, y’all.
You’re a product professional—PM, product owner, etc. You’re building a game-changing product. (Or, at least, a product that is helpful for a specific audience in a constrained way… which is still awesome.)
And you want to boost the chances of success by ensuring that you’ve got a solid plan for building it and that all your internal teams and stakeholders are on the same page.
Your product roadmap is the main way you’re going to do that.
It’s the visual document you’ll share with your team members (and maybe even your customers) to keep everyone aligned and rowing in the same direction.
How do you actually put a product roadmap together?
Here’s your “explain it to me like I’m 5” guide, step by step.
Note: This is part of our ultimate product roadmap guide. Check it out for more on what a roadmap is, what goes on it, who’s involved, etc. This article is specifically about creating the roadmap—putting it together.
Roadmaps are planning documents, and you build a roadmap after you’ve laid some groundwork. Here are some steps to take before you start preparing your roadmap.
Define your product vision and strategy
Your product roadmap is the third layer of your planning. It should complement your product vision and strategy.
Your product vision is the foundation. It’s a clear, big-picture statement about why your product exists. It should describe the long-term goal that you’re hoping to achieve with your product. For example, Shopify’s vision could be, “Make it easy for anyone to create a beautiful and powerful online store.”
Here’s a statement template you can use to define your product vision.
Next comes your product strategy. Your product strategy is how you’re going to achieve your vision. It’s a high-level overview of your approach—the specific needs your product will address, the relevant market segment, the key features, and business goals.
Third is your roadmap. It’s the short-term tactical and detailed plan that you’ll use to implement your strategy. It tells your team what you’re going to build, and—critically—what you’re going to build first.
To make sure your roadmap is taking you to the right destination, I recommend you firm up your vision and strategy before doing anything else.
Identify your audience
Next, think about who the roadmap is for. A product roadmap can have multiple audiences, both internal and external to an organization. Some possible audiences include:
Product management and development teams. These core teams are responsible for designing, developing, and launching the product, including product managers, designers, and engineers. Roadmaps can help organize their work and know what needs to be built next.
Executives. The organization's leadership, including the CEO, CTO, and other C-level executives. Your product roadmap may need to be reviewed and approved by these folks. Also, they may provide strategic input or make decisions about resources based on your roadmap.
Sales teams and Marketing teams. These teams can use the roadmap to understand the product's direction and upcoming features. That helps them better position the product in the market and prepare promotional materials or sales strategies.
Customer Support and Success teams. These teams can use the roadmap to anticipate potential customer questions, prepare training materials, and proactively address issues related to upcoming product changes. They may also have ideas for features and feedback they’ve collected from customers.
Customers. In some cases, it might be useful to share a high-level version of the roadmap with customers to provide transparency, manage expectations, and demonstrate commitment to addressing their needs and feedback.
Other stakeholders. Sometimes other internal or external stakeholders, such as investors, partners, or suppliers, may have an interest in the product's development and performance. Your roadmap can be one way to quickly share your plans with them.
Select an appropriate type of roadmap
Knowing the audience is critical because it helps you understand what type of roadmap to use, what information you need to put on your roadmap, and what design elements make sense. But your choice also depends heavily on your development process and workflow.
For example, if your roadmap is for your dev and product teams, a Gantt chart might make sense, with each feature assigned to a person and given specific release dates, milestones, dependencies, and metrics.
On the other hand, if you use an agile methodology or it’s going to executives, you might want less detail. An agile product roadmap (say, a Kanban-style roadmap) with new features assigned to quarterly time frames might be sufficient to provide an idea of what’s coming without committing to deadlines.
Finally, if you’re making the roadmap public for your customers, you might want to only show some features (and not others). A next, now, later roadmap might be enough.
Choose your product roadmap tool
Finally, test out some tools before you start so you have a sense of the software you might be using. Check out our list of roadmapping tools for the best options.
Note: Savio’s roadmapping tool helps you build evidence-based roadmaps. It displays relevant customer data to help you justify your product decisions and alleviate some of the conflicts that PMs can face.
How to build a product roadmap
Once you’ve got those four bases covered, you can start getting set up.
Step 1: Gather your product ideas
This is usually just your product backlog or your feedback repository—the place where you keep all your feedback, new feature requests, and potential product initiatives.
If you use Savio, this is your feedback vault. If you keep track of your feature requests in a Trello board, it’ll be there. If you’re using spreadsheets, it’s the spreadsheet document where you keep all your feature requests.
Step 2: Prioritize until you get a rough draft
Now go through your roadmap prioritization process (Chapter 4 of our product roadmap guide). and build out a first draft of a roadmap.
The big challenge here is deciding what prioritization model or framework makes the most sense for you to use.
Some of the most common ones are:
The Value vs. Effort matrix. With this approach, you simply score each feature on value and effort and plot them in a matrix. You’d typically choose low-effort features that give a high impact first.
ICE scoring model. In this one, you score each feature on its impact, how easy it is, and your confidence in your scoring. Then you multiply the scores on the three factors together. Typically, you prioritize the features with the highest scores.
RICE framework. Like ICE, you score each feature on impact, effort, and confidence. But you also score it on reach. Then you use the following formula to calculate overall RICE scores: Reach * Impact * Confidence / Effort.
Weighted scoring. This is one of the most flexible methods. You choose the factors you want to score each feature on. Then you assign each feature a weight depending on how important it is to you. Then you score each feature, find a total score, and use that to prioritize.
The MoSCoW method. With the MoSCoW method, you first assign each feature to priority categories: Must-have, should-have, could-have, and won'thaves. Then you prioritize from within those categories. (In my opinion, this one’s not that useful).
The Kano method. This method assigns features to categories based on how users rate their need for each feature. I love that this method uses direct customer feedback to assign categories (but it’s quite a bit of work).
User story mapping. With story mapping, you first build a map of your features based on how your customers actually use your product. Then you prioritize logically based on how the feature fits into the map and what comes next in the story.
Savio’s prioritization model. Here’s the way we like to do it. First, keep track of what your customers are asking you, along with customer data like MRR and plan. Then look for the features that best accomplish your specific business goals—for example, if that quarter you’re trying to reduce churn, prioritize features your churned customers were asking for.
However you decide to do the prioritization step, make sure you finish the process with:
Your major product goals for the quarter
The features you’ve chosen to prioritize
How the features you’ve chosen help you accomplish the goals you’ve chosen (i.e. why you chose each feature)
Relevant data and evidence to support your choices to your colleagues (i.e. RICE scores, a value vs. effort matrix, cumulative MRR for each feature, etc.)
Step 3: Review with the Dev team
Great, you’ve got your draft prioritization set up on your roadmap. Now review the draft with the Dev team to ask for feedback.
Your engineers will give you feedback on your choices, especially with respect to the effort needed to build each feature. You need that second look to know what’s possible and realistic. Better estimates about the effort needed for each feature means better planning.
Your goals here are to:
Listen to better understand the costs of each feature
Understand which features may not be possible at the moment
Make decisions about tradeoffs—which features to keep and which to remove
Foster buy-in from the Dev team early in the process
Use the feedback from your Devs to revise your roadmap.
Note: Sometimes your engineering team will be hesitant to give precise time estimates for features. Instead, you may need to use rough time estimates and communicate that to other stakeholders or with roadmap disclaimers.
Step 4: Review with other stakeholders
Now, review this version of the feature roadmap with the other roadmapping stakeholders—everyone in the “identify audience” step above.
Listen to feedback and make any necessary changes. This step might require a few more iterations (because: teamwork).
Tip: How you do this depends on your organization and personal preferences. I often like to do this in a 1:1 format rather than as a group review. I find that people are more collaborative 1:1, whereas they can get more critical as a group. Then I take it to a group meeting for approval. But it’s your call.
Step 5: Sign off and approve
Once it’s looking solid and you’re confident you have the support of your key stakeholders, you can send them a finalized version to get approval.
Tip: I like to have everyone in the room at this step in a product meeting. It also lets us go through previous features to get status updates. But you could also send this out in an email and just get everyone to respond with “I agree” unless there are major disagreements (Gaurav Oberoi likes this latter method).
Step 6: Present the plan publicly
Finally, make the roadmap available to the audience you chose. That might be a single team, the entire company, or even your customers. Referring back to it should help each audience understand what’s coming up so they can perform their roles and functions.
Tip: Consider making different versions of the roadmap available to different audiences. For example, your internal teams and potentially even your customers—see the next chapter for more on this.
Revise your approach as necessary
There’s no perfect way to roadmap, although the process we included above is one that has worked for us for years. But like every process, your teams will have different needs and processes.
Modify it to suit your needs.
And then give yourself a pat on the back! As a product manager, you’re like the leader of a group project.
And you just built the guiding document that will help you actually get your software out the door. Honestly, sometimes agreeing on what to build is the most challenging part of the product development process.
Get it! 🙌
Kareem is a co-founder at Savio. He's been prioritizing customer feedback professionally since 2001. He likes tea and tea snacks, and dislikes refraining from eating lots of tea snacks.
Make product plans with evidence, not anecdote
Centralize product feedback, enrich and prioritize it with customer data, and create evidence-based roadmaps.
For B2B SaaS Product and Success teams.