Product Roadmaps 101: Complete A-to-Z Guide for Product Managers

Building a SaaS product roadmap? Here’s everything you need to know—what it is, how to build one, how to get your teams on board, and more.

What is product roadmapping?

Product roadmapping is the process of planning a product—deciding what features to build, developing a plan, and listing the resources needed.

Product roadmapping lays out:

• What you’re going to do
• Why you’re doing it
• When you’re going to do it
• Who is responsible

In the SaaS world, roadmapping means designing a strategy for how you’ll build your software product over a period of time. Product roadmaps give you the directions you need to get to your destination—a useful software product that your customers want.

What is a product roadmap

The roadmapping process often results in a “ product roadmap” which is usually a visual document that articulates your product vision and strategy so your teams are all on the same page.

Key elements of a product roadmap include:

• Product goals
• Features to build
• Dates or timeframes
• Metrics for evaluating progress on goals

Note: A roadmapping process also includes a bunch of strategic decisions and research that aren’t always necessarily visible in the resulting roadmap document. For example, your product roadmap might be informed heavily by your customer feedback, which may not be visible on your product roadmap itself.

Why is product roadmapping important?

Product roadmaps help your teams in a number of ways. Here are some of the primary benefits:

• Prioritization. Roadmaps help businesses organize and prioritize their product development efforts by identifying which functionality and initiatives are most important to their goals and customers and which to build next.
• Alignment. They align stakeholders by providing a clear, visual representation of the product's direction and goals. That helps everyone on the team understand the company’s vision as well as their own roles and responsibilities.
• Resource allocation. They enable businesses to plan for the future by creating a timeline of upcoming releases and milestones, helping allocate resources and budgets.
• Flexibility. Roadmaps help businesses adapt to change. They provide a flexible framework for updating as priorities shift and new opportunities arise.
• Teamwork. Roadmaps facilitate collaboration by creating a central, shared document that everyone on the team can refer to and provide input on.

The rest of this article provides a broad overview of product roadmaps—how they’re different from visions and strategies, their components, types of roadmaps, how to build roadmaps, and how to manage roadmap stakeholders.

Chapter 1: Product roadmap vs. product vision vs. product strategy vs. release plan

Product roadmaps are related to—but distinct from—product visions, product strategies, and release plans. Here’s what each is and how they’re different from each other.

What is a product vision statement?

A product vision is the why—the reason your product exists. Its purpose is to guide and align all the teams that are needed to make the product a success.

A product vision statement should describe the long-term goal or objective that you’re looking to achieve with a product. It should specify what the product should be in the future and how it will meet the needs of its users.

Read more: Product vision explanation and guide

What is a product strategy?

A product strategy is a high-level plan to accomplish the product vision. It’s the how—the rough approach you’re going to take. It’s not a list of features with deadlines. Instead, product strategies are broad enough to account for uncertainty and change.

Product visions aren’t product roadmaps. A product strategy is higher-level. It provides the main pillars for achieving the product vision. The product strategy guides decision-making and inspires the team, while the product roadmap provides a detailed plan for achieving the product vision.

Read more: Product strategy explanation and guide

What is a release plan?

A release plan is a document that outlines the key features you’re going to build and timelines for their release. It’s a very detailed look at who is responsible for which tasks and by when.

Product roadmap vs. release plan

Release plans aren’t roadmaps. Roadmaps are meant to explain why you’ve made the product decisions you have; release plans are more about exactly what you are going to build.

Roadmaps are also meant to build in uncertainty and so are open to change. That’s why they often don’t include hard dates or specific tasks. They actually show how a product might change over several releases.

Release plans are more rigid and include specific logistical details about how you’re going to build a product. It’s a zoomed-in view of what is going on in each release, step-by-step.

How to make a release plan

Make a release plan so your teams know exactly what they need to do and how their piece is dependent on others. To do it:

1. Establish your vision and strategy

2. Build your roadmap and prioritize features

3. Break each feature up into sprints for each team

4. Make a visual release plan document communicating the work and sprints.

Guide: How to Make a Release Plan

Release plan example

Here’s one example of a release plan.

An example of a product release plan with four different teams over four months. . Source.

How are visions, strategies, release plans, and roadmaps connected?

Product visions, strategies, release plans, and roadmaps aren’t the same, but they’re connected.

• The vision is the product’s true north and guides the product strategy
• The product strategy incorporates the vision and specifies—at a high level—how you’ll accomplish it.
• The roadmap is a shorter-term (1-year) plan, based on the strategy, that describes how a product will evolve over several releases.
• The release plan describes the execution details your teams need to build the next release.

Visually, you can imagine how they work together like this:

Chapter 2: Roadmap components

What goes on a roadmap? A well-designed product roadmap might include a variety of elements that help convey the product's direction and planned milestones. The specific elements can vary depending on the type of roadmap and the intended audience, but here are the most common elements.

Information a roadmap can include

• Themes or goals: Identify the overarching themes or strategic goals that drive the product's development. This helps provide context for the planned features and improvements.
• Feature requests and improvements: List the specific features, enhancements, or bug fixes that are planned for the product. Provide a brief description and their priority so stakeholders can see what's most important.
• Timeframe: Indicate a rough timeline for your roadmap, whether it's organized by quarters, months, or sprints. I suggest you avoid giving specific dates since these can change and stakeholders may understand these as a commitment rather than a plan.
• Status or progress indicators: You can use visual cues (e.g., color coding, bars, and icons) to show the current status or progress of each item on the roadmap.
• Dependencies or relationships: If certain features or improvements are dependent on others, these relationships can be indicated on the roadmap.
• Resource allocation: Indicate the resources required for each feature or improvement, including personnel, budget, or equipment.
• Milestones or deadlines: Some roadmaps include important milestones or deadlines, such as the launch of a major feature, product release, or other significant events.
• Feedback data: I recommend you include customer feedback, (e.g., number of requests for a feature and cumulative MRR) to demonstrate how your roadmap was driven by user needs. This lets stakeholders understand the rationale behind specific feature choices.

Savio roadmaps provide feedback data right on the roadmap so stakeholders can understand the context behind product decisions.

Remember that the key to a successful product roadmap is clarity and simplicity. Focus on including the most critical elements that will help convey your product's vision and direction, while avoiding unnecessary details that might create confusion or distraction.

Guide: What Goes on a Roadmap?

Design elements of product roadmaps

How can you convey that information? Here are some of the design elements that you can use to make your roadmap effective.

• Bars. Bars represent individual features or tasks on a roadmap, often displayed along a timeline. They show the planned duration of a specific item, from its start to its completion, and help in visualizing the sequence and progress of various roadmap elements.
• Containers. Containers are visual elements on a roadmap that group related items, such as features or tasks, together. They help in organizing and structuring the roadmap by clearly defining relationships between roadmap elements.
• Swimlanes. Swimlanes are horizontal or vertical sections on a roadmap that represent different categories or themes, such as teams, products, or strategic objectives. They help in organizing and visually separating different aspects of the roadmap for better readability and understanding.
• Dates. Dates on a product roadmap indicate the planned start, end, or due dates for specific features, tasks, or milestones. They help in tracking progress and setting expectations for the team and stakeholders.
• Timelines. Timelines are the horizontal or vertical axis on a roadmap that represents time. They provide a chronological view of the planned features, improvements, and milestones, helping teams understand when each element is scheduled to be completed.
• Milestones. Milestones are significant events or achievements on a roadmap, such as the completion of a critical feature, a product launch, or reaching a specific business goal. They serve as markers for progress and help teams stay focused on their objectives.
• Tags. Tags are labels or keywords assigned to roadmap elements, such as features or tasks, to categorize or filter them based on specific criteria, like priority, team, or status. They help in organizing the roadmap and make it easier to find and focus on relevant items.

Read more: Short Guide to Roadmap Components

Chapter 3: Types of product roadmaps

Product roadmaps are like family holiday traditions—while there are some similarities across companies, every team does differently. And that’s a good thing—you should create a roadmap that fits your specific set of needs and workflows.

Here, we showcase various types of roadmaps, organized according to their information presentation and visual design.

Types of product roadmaps by information included

Here are some different ways you can construct your roadmap depending on what information is important for you to present and your workflows:

1. Feature-based product roadmaps. These focus on outlining the planned features and improvements for a product, typically organized by timeframes. The focus of these are the specific features that are planned.

2. Goal-based product roadmaps. These center around the strategic goals and objectives of a product, illustrating how specific features or improvements contribute to achieving those targets.

3. Outcome-based product roadmaps. These are similar to goal-based product roadmaps, but slightly zoomed out. They focus on the behaviour outcomes you want to see in your customers, and the features you need to achieve those.

4. Portfolio roadmaps. These provide an overview of multiple products within a company's portfolio, showing how they align with the organization's overall strategy and objectives. This is useful for high-level strategic planning and resource allocation.

5. Evidence-based Product Roadmaps. These show features and improvements together with relevant concrete data, like customer feedback, user behavior, and market trends. This data—for example, the number of requests for the feature or the cumulative MRR—is included right on the roadmap.

Types of product roadmaps by workflow

These roadmaps are designed specifically for a given software development framework.

1. Agile Product Roadmaps. These are flexible plans organized by high-level priorities rather than specific features. They offer an elastic, adaptive approach that is well-suited to agile development environments.

2. Scrum Product Roadmaps. These are tailored to teams that use the Scrum framework. Scrum roadmaps usually include features and improvements organized into sprints, allowing teams to quickly adapt to changing requirements and incorporate user feedback to continuously improve the product.

3. Kanban Board Roadmaps. These are visual project management tools that use columns to represent different stages in a workflow. They help teams manage work items, improve communication, and identify bottlenecks by moving cards from one column to another as tasks progress through the stages.

4. Release x Features roadmaps. These organize features by planned releases and updates of the product. This type of roadmap is useful for coordinating release schedules and communicating them to stakeholders.

5. Waterfall roadmaps. Waterfall roadmaps are planning tools that follow the traditional sequential approach to project management. They’re useful in traditional product development environments.

Types of roadmaps by design style

Here are some different ways you can set up your roadmap visually:

1. Timeline-based Roadmaps. Timeline-based roadmaps present product features, improvements, and milestones along a linear timeline, giving teams a clear overview of the product's development schedule. This type of roadmap is useful for setting expectations and communicating deadlines to stakeholders.

2. Gantt Chart Product Roadmaps. These display the timeline and dependencies of features, improvements, and milestones in a horizontal bar chart format. This type of roadmap provides a clear view of the project's timeline and helps in tracking progress and identifying potential bottlenecks.

3. Next/Now/Later roadmaps. These are simple and flexible roadmaps that focus on high-level priorities in rough timelines. They categorize features or improvements into three broad buckets based on their priority: Now (what you’re working on currently), Next (what you’ve planned to work on in the future), and Later (features you might build someday).

Guide: Types of Roadmaps and How to Choose

Chapter 4: How to prioritize features

Roadmapping fundamentally includes identifying and prioritizing features. Here’s how to do that.

Guide: Product Roadmap Prioritization: How to Decide What to Build

Where to find new feature ideas?

First, make sure you’re collecting new feature ideas and feature requests from your customers. This is the best way to make sure you’re building a product your cusotmers need.

Guide: How to Handle Feature Requests

Other places to source new feature ideas include:

• Market trends
• Competitor analysis
• Internal team suggestions
• Ideas from your product team
• Your dev team for tech debt
• Your team’s strategic priorities (things customers aren’t asking for)

Guide: Where (and How) to Get Ideas For New Product Features

Savio’s prioritization framework

The hard part isn’t collecting feature ideas—it’s choosing which ones to actually build. My co-founder and I have developed our own framework for prioritizing features based on our over 30+ combined years of experience working at companies like Microsoft and ESPN. Super briefly, it’s this:

1. Set up your feedback tracking system. Identify feedback sources, choose a single repository to put it in, and then create a process to link the two. Also, enrich your feedback with customer data, like MRR. Here’s our big guide on how to build a feedback tracking system that works.

2. Identify the most important business goal. Figure out what you want to work on for that sprint or quarter. Increasing acquisition? Reducing churn? Expansion? Choose the most important one.

3. Filter potential features by impact. For example, if your goal is to reduce churn, figure out what your churned customers were asking for. Make a short list of the features most popular among your target customers.

4. Prioritize further by other attributes that matter. Do another priority iteration considering factors like effort and strategic alignment. Put features that are easier to do and better aligned with your product strategy closer to the top of the list.

5. Determine your development budget. Think about how many hours each feature would take and how many you have total. Put in your “big rocks” (the most expensive features) first. Then fit in medium ones and small ones. You might also break up your budget into customer requests, strategic features, and tech debt.

6. Do a sanity check with your teams. Once you’ve got a rough idea of the features you’re prioritizing—with customer data to back it up—do a gut check with your team and stakeholders. When necessary, advocate or justify your choices with customer feedback.

That’s the sound-bite version. Here’s a detailed, step-by-step version:

Guide: The Savio Framework for Prioritizing Feature Requests

Other common prioritization frameworks

We developed our method over years of trial and error, but you might prefer another one. Here are some of the most common prioritization frameworks for product managers.

Guide: 8 Common Prioritization Frameworks—and Their Pitfalls (Choose Carefully)

Value vs. complexity model

This model (also called the “value vs. effort” matrix) helps you identify high-impact features that require relatively low effort. You do it by plotting features on a 2x2 matrix based on their impact value (usually in terms of number of users affected or revenue potential) and complexity (usually in terms of development effort or time). Then, you can prioritize features that offer the best return on investment.

Read more: Value vs. Complexity Model for Product Roadmapping

Template: Value vs. Complexity Matrix Template (Google Sheets)

Weighted scoring

This method involves assigning scores to each feature based on multiple criteria, such as value, cost, risk, and strategic alignment. You can then calculate a weighted score by multiplying the individual scores by their respective importance. Features with the highest weighted scores should be prioritized.

Read more: Weighted Scoring Models for Product Roadmapping

Template: Weighted Scoring Model Template (Google Sheets)

Kano model

This framework classifies features into categories based on how they influence customer satisfaction: baseline features (must-haves), performance features (which have a linear relationship with satisfaction), and delighting features (features that, if you include them, will delight users.

The Kano model starts with you putting each of your feature ideas into one of the above categories. Then, you can start by building the baseline features. Then, prioritize performance features. And finally, differentiate your product with the delighter features.

Read more: Build a Great Product Roadmap with the Kano Model

RICE model

RICE stands for Reach, Impact, Confidence, and Effort.

This framework helps you prioritize features by considering the number of users they will affect (Reach), the degree to which they will improve the user experience (Impact), the certainty of the estimated benefits (Confidence), and the resources required for implementation (Effort).

RICE scoring—done well—can help you identify promising feature opportunities.

Read more: The RICE Prioritization Framework: Template and Guide to Avoiding the Pitfalls

Template: RICE Model Template (Google Sheets)

ICE model

Ice stands for Impact, Confidence, and Effort. It’s a lot like the RICE model, just without the reach! Like RICE, it’s easy to calculate and generates a ranked list of your features for easy prioritization. You just have to be super careful with how you estimate each of the scores that go into the formula.

Read more: What is ICE Scoring for Feature Prioritization? Overview, Guide, and Template

Template: ICE Model Template (Google Sheets)

MoSCoW model

This technique involves categorizing features into four groups: Must-Have, Should-Have, Could-Have, and Won't-Have.

By clearly defining these categories and assigning features to them, you can ensure that your product roadmap focuses on the most critical elements while considering other potential improvements.

Read more: Use MoSCoW Prioritization Model—Understand its Weaknesses

Template: MoSCoW Prioritization Template (Google Sheets)

Story mapping

This method involves visually organizing user stories (descriptions of desired product functionality) into a two-dimensional map that represents the user journey.

By identifying the most important user stories and placing them on the map, you can prioritize features based on their relevance to the overall user experience.

Read more: Creating an Agile Roadmap Ssing Story Mapping

Each of these prioritization frameworks has its strengths and weaknesses, so you may want to experiment with different methods or even combine elements from several frameworks to find the best approach for your specific product and organization.

Prioritization tips

Finally, here are some quick tips to keep you on the right track while you’re prioritizing your roadmap.

• Communicate with your teams. Check in early and often. The more you engage your stakeholders in the process, the more socialized they’ll be to the end product—and the better buy-in you’ll have.
• Establish objective criteria. Develop a set of objective criteria for evaluating features, such as potential revenue, user impact, development effort, and alignment with your product strategy. This will help you make more informed decisions and minimize the influence of personal biases.
• Regularly review and update your priorities. Roadmaps aren’t static. Your priorities will change over time as you gather new information, receive feedback from users, or encounter unforeseen challenges. Be prepared to reassess and adjust your priorities and update your roadmap as you go.
• Balance short-term and long-term objectives. While it's useful to address immediate user needs and quick wins, don't lose sight of your long-term goals. Strike a balance between delivering short-term value and investing in features that will drive long-term growth and success.
• Don't be afraid to say no. It's impossible to accommodate every feature request or idea. Be prepared to say no to some suggestions and focus on the features that will deliver the most significant impact and value for your users.
• Use feedback. Customer feedback helps you at every roadmapping step: understanding user needs, generating ideas, prioritizing features, and justifying product decisions. Develop a system of tracking feedback to make sure you’re not missing out on this critical source of data.

Chapter 5: Putting the roadmap together

So what does it mean to actually build a roadmap? Here’s what the process looks like from start to finish for a quarterly roadmap.

Guide: How to Build a Product Roadmap, Step by Step

Pre-requisites: Get your systems in place first

The first step is to get all your foundational pieces and systems in place first:

• Create your product vision. Your product vision is your north star—it guides the rest of the process. Get this firmed up first.
• Set your product strategy. Understanding the big strategy pieces is critical to understand what should go on your roadmap.
• Feedback tracking. This helps make sure you understand what your customers are asking for and that you’re collecting new product ideas.

Once you have those pieces, you can dive into roadmapping.

Steps for putting together a product roadmap:

1. Gather your product ideas. You probably already have these in your backlog or feedback repository.

2. Prioritize the features. We explained how to do this in Chapter 4.

3. Review with the Dev team. Your engineers can tell you what’s possible and realistic. Revise based on their feedback.

4. Review with other stakeholders. Listen to feedback and make any necessary changes. This step might require a few more iterations.

5. Get approval. 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.

6. Present the plan. You’ll share your roadmap with the appropriate internal stakeholders. You may also decide to share a version with your customers.

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.

Chapter 6: Roadmap stakeholders: Ownership, roles, and building consensus

It takes a village to raise a product.

But like any group project, the collaborative nature of product management can become a barrier. Indeed, one of the functions of product visions, strategies, and roadmaps is to make sure everyone’s aligned and pulling in the same direction.

Roadmap ownership and stakeholder roles

Product teams are typically responsible for the roadmaps, although in some organizations, they may not have as much power to decide as they might like (been there!).

Here’s who else is often involved in creating the roadmap and their precise roles.

Product teams

Product teams typically lead a product roadmapping process. They’re usually responsible for setting up a customer feedback system, tracking feature requests they receive directly from customers, and prioritizing those features to a roadmap.

Read more: The Role of Product Teams in Roadmapping

Customer Success teams

CS teams play an increasingly important role in product roadmapping—and that’s a good thing. They’re the customer experts and have the best view of customer needs.

In a roadmapping process, customer success teams are responsible for collecting and sharing customer feedback with Product, help prioritize features to the roadmap, and close the loop with customers when features are built. Read more about the role of product teams in roadmapping.

Read more: The Role of Customer Success Reams in Roadmapping

Customer Support teams

Support is similar to customer success (for many companies, these teams might have the same job.

Support should be capturing customer pain points, sharing feedback and feature requests, and participating in roadmap sessions. They should also close the feedback loop with customers that opened support tickets.

Read more: The Role of Customer Service Teams in Roadmapping

Sales teams

Sales has another critical role in roadmapping: representing the voice of prospects and lost deals. They should be collecting feedback, sharing it with Product, and participating in roadmapping meetings.

They can also share sales data and close the loop with prospects and lost deals.

Read more: The Role of Sales Teams in Product Roadmapping

Marketing teams

Marketers play a bigger role in roadmapping than you might think. They typically receive customer feedback from social media. They should send it to Product teams and use it to sharpen marketing copy and messages.

They should also collect and manage content feedback—feedback about marketing content and new content ideas.

Read more: The Role of Marketing Teams in Product Roadmapping

Executives

Executives own the larger business strategy, and that affects the product. In my view, they play a gut-check role and help ensure that Product has done its due diligence.

Yes, it can be annoying to have execs constantly asking for pet features. If your execs are challenging Product too much and too often on features, it’s worth thinking about building more evidence into the feature selection process.

How to achieve consensus on product roadmaps

You can see that a bunch of teams have a role in creating and using the product roadmap. Because of the team nature, part of the work of a PM is to build consensus on the roadmap.

Image source: Twitter

Here are some steps to help you build consensus and ensure everyone is on the same page:

• Involve everyone. Make sure that representatives of your key teams have a seat at that table—i.e. Are invited to your roadmapping meeting. Including everyone’s perspectives and insights helps you build a well-rounded and informed roadmap.
• Socialize everyone as you go. People are more inclined to agree to a roadmap when they’ve had input as it was being developed. Share early drafts with your stakeholders and take into account their feedback. That way, everyone’s seeing their feedback represented on the final version at the meeting.
• Establish clear objectives and priorities. Before you built your roadmap, you’d already developed a vision and strategy. If you followed our prioritization framework, you’ve already chosen business goals, too. Make sure everyone’s clear on those pieces before diving into specific features or improvements.
• Explain your prioritization framework. Again, you’ve chosen some method to identify the highest priority features. Explain the method you used, and why. This helps to create a transparent and objective decision-making process that stakeholders can understand and support. For example, maybe you chose Savio’s approach because it incorporates customer feedback and is more customer-centric.
• Share relevant data. Present the data that helped you make your decisions, including customer feedback, market research, and competitive analysis. This is the evidence that justifies your product decisions; sharing it helps build a shared understanding of the factors driving your roadmap decisions.

Savio includes key customer feedback data right on the roadmap so it’s easy to share the feedback you used to make product decisions.

• Communicate trade-offs and constraints. Be transparent about the trade-offs and constraints you face, such as limited resources, budget, or time. Explain why certain features or improvements are prioritized over others and how these decisions align with the product's objectives and priorities.
• Solicit feedback and iterate. Encourage open dialogue and constructive feedback from stakeholders throughout the roadmapping process. Be open to revising and iterating on the roadmap based on their input and new information that emerges.

Read more: Product Roadmap Alignment—Achieving the Vision Together: A Grey Literature Review

Chapter 7: Roadmapping software tools

Roadmapping is easier when you’re using the right tool. You can build a roadmap in just a few clicks.

Roadmapping tools: Looking for roadmapping tools? We’ve curated a big list of the top roadmapping tools with key features, pros, cons, and pricing. Check that out.

But super briefly, here are some of the tools you could use:

Savio

My favorite tool (surprise). Savio makes it easy to build quick, customized Kanban-style roadmaps. You can quickly add feature requests right from your vault, and develop different versions of the roadmap to different audiences (deciding what information appears—and what doesn’t).

Perhaps the best thing about Savio’s roadmaps is that they include customer data to provide context. You can see how many customers requested a feature, the cumulative MRR, and more. This data helps you justify and explain product decisions, making it much easier to get consensus among stakeholders on your roadmap.

Savio makes it easy to draw up Kanban-style roadmaps that provide feedback data as context for product decisions.

Spreadsheet tools (Excel, Google Sheets, etc)

We don’t love spreadsheets for product roadmapping. They’re limited with visual presentation, they’re not very flexible, and it’s difficult to connect them to your idea backlog. Still, they can be useful in a pinch for really simple roadmaps.

Slideshow software (PowerPoint, Google Slides, etc)

Again, slide presentation software isn’t really built for product roadmaps. They lack interactivity, they’re inflexible, they don’t connect to your feedback repository or customer feedback data, and they rarely integrate with your other tools.

But they are built for presenting to your teams or stakeholders. And you already know how to use them. They might be appropriate for simple roadmaps or for super early startups.

Project management software (Trello)

Trello is super flexible and can easily be used to create simple Kanban-style roadmaps. It’s well-designed and you can easily share it with your teams. Another benefit is that there are a number of powerups you can use to automate some of your processes.

On the other hand, it’s manual—you’d have to build each roadmap by hand based on your feature backlog. It also can’t easily pull in customer data from your source of truth (CRM or support software).

Issue tracking software (Jira or Shortcut)

Your Dev team might already be using a software tool, like Jira or Shortcut, to manage their tasks. Why not build your roadmaps there? Having one fewer tool is a plus, and it links directly with your dev workflow. Also, some tools, like Jira, have roadmapping capabilities built in.

One of the downsides is that it’s complicated to track feature requests in Jira. That’s because it doesn’t connect to your sources of feedback, like your support tool, Slack, or a feedback voting board. It also doesn’t let you slice and dice your requests to prioritize them properly.

Read more: Using Shortcut’s Roadmap Feature

Read more: Product Roadmapping in Jira

Chapter 8: Product Roadmap Templates

Here are some templates to help you get started with your product roadmap.

• SaaS product roadmap temaplate. This is a simple next/now/later product roadmapping template you can copy and use in Trello.
• Roadmapping template recommended by Lenny Rachitski and created by Andrew Chen, Product Manager at Facebook.
• An editable product roadmap template in Notion that will help you define the various tasks and projects that comprise your product roadmap.
• A downloadable template made by the growth tech advisory company York.ie that will help you guide your priorities for today without losing focus on the strategies of tomorrow.

FAQ

Should a roadmap have dates?

Usually no. Roadmaps should be flexible. Including dates makes it easy for stakeholders—especially customers—to feel like a roadmap is a commitment rather than a guiding document. Save dates for release plans.

How long should a roadmap be for?

There aren’t any hard and fast rules, but we like the following rules of thumb:

• Product visions should be built to last about 10 years
• Product strategies should be designed to last several years
• We update our product roadmap roughly every 3 months

How do I deal with constantly changing asks from management?

This one’s complicated.

It depends a bit on why the asks are changing. If you haven’t found market-fit, changing is normal because you’re experimenting. If you’re changing based on market research, then that makes sense. If execs just want a pet feature, it might conflict with your job as a PM—which is to understand your customer needs and provide the best product possible.

Dealing with pet features: My favorite strategy is to set up the system to support a decision-making framework. That means:

1. Agree with all stakeholders on goals and priorities for the product over the roadmapping period, based on your shared vision and strategy

2. Log customer feedback and feature requests enriched with customer data like plan, customer stage, and revenue

When you do those things, you can more easily justify your decisions because you can say things like, “This quarter our goal was to reduce churn. Feature A is the most requested among churned customers and has a higher opportunity revenue than Feature B, so that’s why we prioritized it.”

With the right data, I’ve found you can usually keep execs happy. The goal is something like this quote from Ant Murphy:

This may not be exactly accurate in practice, but I agree with the principle: Providing context can be a powerful way to manage stakeholders.

On the other hand, that’s not always realistic. Sometimes management just wants what they want.

Ultimately, your exec team gets to make some calls that you might not like—that’s part of their role. Hopefully, if you provide compelling data for the features you’ve chosen, they’ll see that, and agree with your plan most of the time.

I also actually talked about this in a recent podcast episode—feel free to check it out here.

What if I completely misestimate the effort of an initiative?

Try to get in front of it quickly and let your stakeholders know. Take responsibility, and then work to understand why you miscalculated. Tweak your system to try to avoid it in the future—maybe that means:

• Building in another gut check or consult with more people
• Writing product specs in advance
• Building in more uncertainty into your planning

Remember, scoping is one of the most difficult parts of planning—you might get it wrong sometimes.

How specific should I be on delivery dates?

Roadmaps typically don’t need a ton of precision about dates. You can give rough target dates with 2 to 4 weeks.

If your stakeholders are pressing you for more specific dates, err on the conservative side.

Should I share my roadmap with customers?

Big question. It’s your call.

Pros: You show them what’s coming, which might help acquisition and retention.

Cons: Customers often understand roadmaps as a commitment to build features, not as a flexible planning tool. If you change or get it wrong, you might create issues.

In general, we don’t love sharing roadmaps with customers. One exception is for enterprise products that have big customers—with them, you might want to give lots of information and context about what’s coming down the pipeline.

Tips: If you’re going to share your roadmap with customers:

• Make it general, including only the features you think they need to see.
• Be conservative with dates or timelines
• Give any disclaimers you need to

Note: With the Savio roadmap, you can easily include as much or as little on your roadmap as you need to so that your customers stay happy.

Isn’t roadmapping expensive and unnecessary?

If you have another planning process that works, great. Maybe you don’t need a roadmap.

In my experience, ad hoc product planning can work with smaller companies, but as soon as your team starts to grow, it helps having a plan to keep everyone aligned, on track, and understanding what’s coming next.

Last Updated: 2023-07-10

Want more articles like this?

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

Send me more articles like this

Unsubscribe anytime.