How To Build A Roadmap: Guide and Tips

Pieces of leggo on a surface. Building a roadmap is like putting the pieces together.Ready to build your product roadmap? Here’s how.

It’s roadmap time, baby.

Boy in cowboy hat spinning around and making finger guns. He's excited to roadmap!

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.

So.

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.

Pre-requisites

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.

Guide: Where to get ideas for new product features

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.

Guide: How CS can best share product feedback so Product listens

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! 🙌

Up next: Product roadmap templates to get started

Last Updated: 2023-05-17

Kareem Mayan

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.

Want more articles like this?

Product Leaders from Slack, Zapier, and Appcues read our newsletter to delight customers, lower churn, and grow revenue.

Prioritize high-value Feature Requests

Centralize customer feedback from HubSpot, Intercom, and Slack.

Prioritize high-value features sorted by churned revenue or MRR.

Close the loop for Sales and CS by automating status updates from JIRA.

Learn more

Contents

Centralize, Organize, and Prioritize Your GTM Team Feature Requests

Centralize customer Feature Requests from Slack, HubSpot, Intercom, Zendesk, SFDC, Help Scout, and more.