A Beginner’s Guide to Product Roadmaps

Product roadmaps are living, visual documents that convey the strategic direction of a product. These high-level summaries bring all the moving pieces involved with product management and product development together. They convey both aspirations (through the product vision) and plans (through initiatives) while also connecting product strategy to company strategy. When done effectively, product roadmaps communicate the “why” behind what you’re building.

However, that’s not the only objective of a roadmap. Effective product roadmaps help product management professionals and their teams achieve several things:

• Describe the product vision and strategy
• Provide a guiding document for executing the strategy
• Get internal stakeholders in alignment
• Facilitate discussion of options and scenario planning
• Communicate progress and status of product development initiatives
• Help communicate your strategy to external stakeholders (including customers)

Over the course of the next few chapters, we’ll walk you through the roadmapping journey and equip you with everything you need to roadmap effectively. But before that…

Roadmaps Aren’t Only for Product Managers.

It’s worth noting before we continue that product management professionals are not the only people who can benefit from a visual roadmap.

A few of the many examples out there include:

• IT teams can use roadmaps to plan and track architecture projects, software implementation, and various other projects.
  

• Marketing teams may use roadmaps for planning everything from their marketing strategy to their content calendars.
  

• Businesses and business operations teams can use roadmaps to plan scaling and other organization-wide objectives.
  

• DevOps may use roadmaps to better connect the various pieces of an org they are responsible for bringing together.
  

• Engineering teams may use roadmaps to plan sprints.
  

The possibilities are endless. While this guide is written primarily for product management professionals, people in other roles interested in learning about roadmapping may also be able to learn from the advice and insight we’ve provided here.

What happens before you prioritize, build, and share your roadmap is of equal, if not, greater, importance than the roadmapping process itself.

Setting the vision and strategic goals for the product — and, more importantly, getting alignment on these with your stakeholders — are the first steps to creating a successful roadmap. After all, if you don’t really know where you’re trying to go or why, how will you come up with a plan for getting there? And if you can’t get your team to rally behind the plan, how will you make progress toward it?

Furthermore, while products exist primarily to solve problems, they also (in most cases) need to make money somehow. So, business objectives also matter, and the roadmap needs to reflect consideration of them.

Connecting Product Strategy and the Roadmap

Embracing a top-down approach to strategic planning is a popular way to ensure your product roadmap aligns well with both business objectives and long-term aspirations for the product. It also helps define quantitative goals that not only measure progress but also help inform prioritization decisions.

The top-down strategic planning process is fairly straightforward. Start by defining your high-level product vision, then use it to derive actionable, measurable product goals. Your vision and goals then inform your product roadmap. In turn, your roadmap sits a level above your more granular release plan and backlog.

Let’s look at the two parts of the product strategy that come before the roadmap — the product vision and product goals.

Product vision

A top-down approach in the context of roadmapping means starting first and foremost with your product vision. Your product vision, often called a product vision statement or mission statement, is a concise, high-level, aspirational statement of why your product exists. It is a guiding light— out of reach in the moment, but a constant representative of the intended direction. Learn more about crafting a product vision statement.

Strategic goals

From the product vision you can derive product goals that will influence the initiatives that are on your roadmap. Coming up with product goals is the step that helps you translate your product strategy into an executable plan. Every organization’s product goals will be different. You can develop product-specific, company-oriented, or more generic goals.

Ideally, your goals should be measurable and readily tied back to trackable metrics and Key Performance Indicators (KPIs). It’s these types of goals that will resonate most with your stakeholders.

How often should you revisit product vision and strategic goals?

As with most things in life, particularly in business, strategies are rarely set in stone. Your product vision statement should be aspirational and high-level enough that it remains steady on the long term. However, product managers should be prepared to revise it (and even course-correct pivot) if necessary.

Strategic goals, business objectives, and KPIs, are generally also aspirational. But by nature, they will need adjustments, revisions, and resets in time. The cadence at which you make those adjustments will vary from organization to organization. What is important here is that you get into the habit of thinking ahead about how those will change in time.

Many organizations set different tiers of strategic objectives for different time frames. For example, they may set some benchmarks for where the business should be 3 years into the future, then break down those benchmarks into smaller milestones along the way and timebox those milestones in such a way that keeps them on track to meet the longer-term goal (i.e. quarterly check-ins). From those goals, many product managers find it useful to distill sets of more granular objectives and KPIs to be met along the way.

Get Consensus on Strategy Before Setting Sail

Before we go on to discuss how to plan and prioritize your roadmap in the next chapter, a quick reminder.

Armed with a powerful product vision and a set of strategic objectives that align with both, the vision and organization-wide goals, you can start thinking about the roadmap itself. Namely, which product initiatives belong on the roadmap and where they belong relative to one another.

It’s important to understand where to source the feature ideas to evaluate. Your list of ideas and proposed features shouldn’t be pulled out of thin air; you should do your best to put a system in place for collecting feature ideas and including as many sources as possible.

Let’s look at a few sources of ideas for new product features and initiatives.

Where to Find Ideas for New Features

Customer Feedback

Your customers know better than just about anyone what your product needs. Ask them for feedback, but remain aware that this is a biased data sample. And, don’t allow one-off feature requests to distract you from your overarching product vision.

Analytics & Metrics

Objective data is far more compelling than opinion. If you have real-world user data on your product or similar products, then you already have a great source of business intelligence to inform which ideas might be worth pursuing.

Dive into best practices for product management metrics with our Metrics & Data Email Course.

Competition

Your goal, of course, is to bring a unique and valuable product to the market. But competitors offer valuable data. Learn what customers like about competing products, what they don’t like, and what they wish they had. Just make sure to steer clear of copycat products by thinking strategically about differentiation.

Marketing, Sales and Customer Success

Look no further than other teams within your own company for valuable product intelligence. Your sales reps and customer success managers are in constant communication with prospective clients and customers. Ask them about common feature requests, usage trends, and complaints.

Analyst Research

Study industry reports about your category of product (i.e. analyst firms like Gartner and Forrester) to determine what types of products work, with whom, and why.

Reminder: As a product manager, you shouldn’t be expected to come up with every new product feature. Good ideas can come from anywhere. By the same token, bad ideas can also come from anywhere (including your executive team, your biggest customers, and your smartest engineer). Your responsibility is to decide which of those ideas should be added to the roadmap and see the light of day. And that’s where feature prioritization comes into play.

Prioritization is challenging. In our latest Product Planning Report, 32% of product managers said their biggest product management challenge is planning and prioritizing initiatives. Product professionals are continually balancing resources, expectations, customer requests, technical debt, and more.

As your organization’s central hub for your products, a defined prioritization framework can help make these tough decisions a bit easier.

Furthermore, having a defined prioritization framework is extremely useful when it comes time to defend your product roadmap. There will always be outliers and one-off projects, but when all prospective features get the same prioritization treatment, it makes it harder for one person or team to derail your product strategy.

In this chapter, we’ll address a few general pointers for roadmap prioritization and outline a few prioritization frameworks you may want to consider.

General Tips for Roadmap Prioritization

Regardless of the prioritization method you choose, here are some suggestions for thinking through which initiatives to include on your roadmap:

• Approach prioritization as a team activity. Not only does it create buy-in on the team, but also you get different perspectives. And, it’s also a lot more fun.
• Limit the number of items you are prioritizing. Focus on the biggest items rather than the small details.
• Categorize and group initiatives together into strategic themes (for example, “improving satisfaction” for a particular persona would be a good way to group).
• Before you begin prioritizing initiatives, it’s helpful if you understand the customer value for each initiative. The customer value should be rooted in evidence that you’ve gathered from customers rather than your opinions.
• Start with a rough estimate of the cost for each item. Even T-shirt sizing of “small,” “medium” and “large” will be helpful during the process.

Product Roadmap Prioritization Frameworks

Here are several other ways to quantify the many variables among the features, enhancements, fixes, and other items competing for the limited resources in your product roadmap.

Quantitative methods for prioritizing features

Quantitative prioritization methods are great for doing some initial prioritization on your own before presenting your findings to a larger audience. They can also guide your product strategy conversations so that it won’t be dictated by opinion alone.

Value vs. complexity quadrant

In the Value vs. Complexity model you evaluate every opportunity based on its business value and its relative complexity to implement. The matrix is simple: The initiatives that have the highest value and the lowest effort will be the low-hanging fruit for your roadmap.

Weighted scoring (or benefit vs. cost)

With weighted scoring you can use the Value vs. Complexity model, but layer in scoring to arrive at an objective result. By using a scoring method to rank your strategic initiatives and major features, product managers can facilitate a more productive discussion about what to include on the product roadmap.

Kano Model (customer delight vs. product function)

With the Kano model product managers can look at potential features through the lens of the delight a feature provides customers vs. the potential investment you make to improve the feature.

Qualitative methods for prioritizing product initiatives

Qualitative prioritization methods often represent great opportunities to work cross-functionally on prioritization. As you’ll notice, a few of the methods that follow lend themselves well to collaborative activities.

MoSCoW analysis

The acronym, MoSCoW, stands for four different categories of initiatives: must-haves, should-haves, could-haves, and will not have at this time (or sometimes “wish”). First, key stakeholders and the product team need to get aligned on objectives and prioritization factors. Then, group your list of proposed features into the four MoSCoW buckets. With such limited options, it usually becomes clear which initiatives are truly a top priority.

Buy-a-Feature

Buy-a-Feature is an activity you can use with customers or stakeholders to prioritize a set of potential features. The approach is simple but fun. List potential features and assign a “price” to each (based on a relative cost to develop it). Hand out a set amount of cash and then ask participants to buy the features. Some will place all their money on one particular feature they’re passionate about, while others might spread their cash around the room. The result is your prioritized feature list.

Opportunity scoring

Opportunity scoring is a type of gap analysis that comes from outcome-driven innovation. Without getting too detailed, the idea is to measure and rank opportunities based on their importance vs. customer satisfaction. To conduct opportunity scoring you ask customers to score the importance of each feature and then also score how satisfied they are currently with that feature. Your opportunities are those features that are highly important yet customers gave a low satisfaction score.

Affinity grouping

Affinity grouping can be a fun prioritization activity. The idea is simple: have everyone brainstorm opportunities on sticky notes. Then as a team, begin to group similar items together, and name the groups. Finally, everyone on the team begins to vote on or rank the groups.

Story mapping

Story mapping is a great way to document the MVP by organizing and prioritizing user stories. The idea, in‌ ‌a‌ ‌nutshell, to create task-oriented story cards, group them together, then arrange the cards in priority order for each group. The final step is to draw a line (often with tape) across all the stories to divide them into releases/sprints.

Three Things to Remember About Prioritization

Before we move on and discuss actually building the roadmap, there are three things you want to keep in mind about prioritization.

1. Your prioritization framework is always a moving target. While it’s important to define how you will prioritize, it’s also important to understand that it will most likely evolve over time.
2. Prioritization should be a team exercise. Your colleagues outside of the product department have valuable insights into your users and market.
3. Prioritization is only as good as your ability to communicate it. You should be able to use your prioritization methods to answer “why” and defend your product strategy.

Once you’ve settled on your product vision and prioritized all your initiatives, it is time to start building your roadmap. In this chapter, we will discuss a few best practices to keep in mind as you build your roadmap.

Visual

As a product manager, one of your key jobs is to be an evangelist for the product. A high-level visual presentation is a powerful way to help get buy-in on your strategy. This is one reason a visual product roadmap is a good way to go.

Here are some of our tips for effective visual roadmaps:

Use color. Color is a great way to represent how your roadmap ties to the product vision or strategic objectives. Color-code each item on your roadmap to help people make the connection between each initiative and how it fits into the big picture.

Use large fonts. People have a limited amount of time to digest your strategy, so use large fonts, especially if you are presenting your roadmap on a projector or in an online meeting. Think of your roadmap very much like a presentation and you’ll be ahead of the game.

Keep it high level. Remember that you are telling a story about how your strategy fits with the product vision. So tell the story in big, bold strokes rather than diving into the details. If you can, create logical groupings of initiatives to make the roadmap easier to grasp.

Collaborative

Building a product roadmap often has to be a fluid conversation—a compromise among different priorities. A common way to collaborate during the build phase is to enable each stakeholder to lead their own initiatives within their respective areas.

Let’s assume you are a product manager for a large software company. You could have a roadmap that shows all your User Interface (UI) initiatives; another roadmap could focus on all your Application Programming Interface (API) projects; and still, another roadmap could be driven by your architects, outlining your overall software strategy.

As a product manager, you have to stay in the picture on all those initiatives. But you can’t be an expert in or even own all those areas. It is your job, however, to set priorities. In order to understand the big picture, you need to be able to roll up all of those individual roadmaps into one portfolio plan and distill an easy-to-understand picture for the executive team to earn their buy-in.

Dynamic

A product roadmap is a high-level strategic document that reflects your long-term product vision. But a roadmap does not need to be set in stone. You have to be able to update your roadmap frequently if you need to adjust your direction.

In an agile world, you can no longer predict what’s going to happen years out. The reality is that you need to rapidly adjust to market changes, customer requirements, stakeholder needs, and other influences. Therefore your roadmap needs to be a living document and allow for changes.

How often you change your roadmap depends on how many details you include on your roadmap as well as the timeframe for the roadmap. For example, if your roadmap tends to be long-term (more than 12 months) and is at a higher strategic level, it may not change as frequently as a short-term roadmap with detailed features.

Build Your Product Roadmap With the Right Tool

Building a product roadmap that serves the needs of not only the product team but also the team’s various constituents can be challenging without the right purpose-built roadmap tool. We’ve seen product teams use anything from presentation software (i.e. Powerpoint), to illustration software (i.e. Illustrator), to spreadsheets, to project management software to build and share their product roadmaps. However, over the past few years, we have observed specialized product roadmapping tools increasing in popularity among product teams.

Our most recent survey of product managers around the world found that in 2019, dedicated roadmapping software is the tool of choice for the majority of product teams, followed closely by presentation software. Dedicated roadmapping software tends to have a benefit over tools like Powerpoint and Excel because it is built specifically for product teams and their unique needs.

Looking for a Product Roadmap Tool?

For this reason, it’s no surprise that our survey also found that the product teams most satisfied with their planning and communication processes were those who used dedicated software for roadmapping.

The first step in building a roadmap is selecting the appropriate style. Thousands of roadmaps have been built with ProductPlan, putting us in a unique position to comment on various formats. Even though the roadmap style permutations are endless, we see the following three roadmap styles most commonly: Timeline, Roadmap without Dates, and Kanban.

In this chapter, we will explain when and where these styles make sense and what some of the advantages and shortcomings are of each roadmap type.

Timeline-Based Roadmap

Every product manager has heard this question before: “What are you doing and when will it be done?” If your CEO asks you this question, a timeline-based roadmap can be a great tool for you and help you to respond to that question.

A timeline-based roadmap shows your initiatives relative to each other in the context of time. It visually communicates how long you intend to focus on certain initiatives and when you plan to complete them. Typically, you arrange your initiatives in a bar chart on a grid that represents a specific timeframe.

Although there might be dates on your roadmap, from a product management standpoint it is often a good practice to keep your dates high-level and not too specific. For example, show initiatives spanning a few months without designating exact start and end dates. You need to manage expectations with stakeholders, and the more specific the timeline, the more you are setting expectations for delivery of specific dates and capabilities.

Timeline-based roadmaps are great to visualize product schedules among the different tasks at hand. However, a common pitfall for timeline-based roadmaps is to focus on deadlines rather than emphasizing strategic priorities.

Roadmap Without Dates

Keeping in mind the saying, “It’s not the destination but the journey.” Removing date constrictions from your roadmaps allows you to better focus on modeling the process — how you can achieve your end goal. While there are a lot of commonalities between timeline-based roadmaps and roadmap styles without dates, the important differentiator here, as you can see from Figure 14, is that you do not associate any dates with your initiatives.

You can group similar items together in the same swimlane to better emphasize related initiatives. The length of each initiative, depicted as bars in the example roadmap above, could represent their strategic importance or rough effort level. Even though you don’t need to commit to a specific deadline, a roadmap without dates still allows you to order all involved initiatives sequentially. You can model the process based on what must get done first. Then, put your initiatives in context with everything else going on.

Kanban-Style Roadmap

Kanban is a project management framework that got its start in “just in time” manufacturing. It’s now frequently used to show a roadmap, priorities , and progress. Kanban matches the amount of work in progress (WIP) to the team’s capacity. Therefore, it gives teams more flexible planning options, faster output, clear focus and transparency throughout the development cycle.

A key tenant of kanban is to limit the amount of work in progress. WIP limits can highlight bottlenecks and backups in the team’s process due to lack of focus, people or skill sets.

For a Kanban-style roadmap, you want to show stakeholders the status and priorities for each stage of your development.

For example:

• Approved
• Validated
• Ready for Estimation
• In Progress
• Ready

Looking for roadmap inspiration? Check out our free roadmap templates.

In addition to communicating with stakeholders frequently throughout the product planning process, successful product managers know how important it is to share their product roadmap with internal stakeholders. Sharing the roadmap with different teams such as sales, executives, marketing, and engineering is part of the job.

If your audience is comprised of executives, your goal will likely be to get them to buy in to your strategy or green-light your plans. If your audience is some other segment of your organization, your goal will likely be to communicate product direction and build consensus.

In either case, you need to be clear and persuasive, so stakeholders walk away understanding your strategy and agreeing with your priorities.

And, as we mentioned in previous chapters, whatever format you choose to make roadmaps in, you should create and maintain multiple versions of your product roadmap. This way, you’ll always have quick access to the right roadmap view and the appropriate level of detail for a given audience.

You never know, after all, when someone will ask you to share your product roadmap with them. And when they do, you want to share the most relevant information in an easy-to-understand manner.

Here are some pointers for sharing your roadmaps with a handful of typical audiences:

Sharing Your Product Roadmap with Engineers

Your development team spends much of its time focusing on the ground-level details. They often have tasks set for them that only go a few days or weeks out—small stories, bug fixes, minor tweaks, testing, etc.

It’s easy for these teams to lose focus on the product’s bigger-picture objectives, and that can mean you’ll lose some of the unique perspectives these professionals can bring to your product.

So when sharing your roadmap with your developers, you’ll want to help lift their gaze up every now and then to see the big-picture strategic view.

Your developer-focused roadmap view should include some higher-level strategic information. But it also needs enough tactical detail that they understand what they’ll be working on in the near or medium-term.

Sharing Your Product Roadmap with Executive Stakeholders

On your executive-facing roadmap, you’ll want to provide a supplemental view to the big-picture work they’re constantly focused on. Give them the chance to see how the work that needs to be completed in the near-term will help to realize their long-term vision.

You might say to your executive team, “As you know, this is our five-year vision for the product. And we’ll get there. But let me walk through what we’re planning to accomplish in the next year. We are working both to generate revenue today and to move us closer to that longer-term objective.”

Of course, even with a one-year view, you’ll want to use details sparingly. Your executives probably aren’t going to be interested in hearing about your plans for resource allocation or dependencies among small initiatives. So keep the tactical details to a minimum here. Present just enough information to visually walk through the key milestones slated for the coming year.

Sharing Your Product Roadmap with Your Sales Team

Your sales team will always be focused on how your product is going to help them make sales. They won’t care about which development teams you assigned to which epics or features. Or how much initiatives are going to cost to develop. Leave these details out of the sales view of your roadmap.

Instead, when you share your roadmap with sales, you’ll want to focus on upcoming features. You’ll also want to include right on the roadmap itself your strategic reasoning for every feature you’ve prioritized.

One word of caution, though, is to be careful about dates. When you include a date on a product roadmap—even if you clearly explain it’s only an estimate—at least some of your reps are going to treat it as an implied promise. So be careful about including dates on your sales-focused custom view roadmap.

Ready to build beautiful roadmaps?