Product Roadmap Guide

True product leaders ensure that product management is not a black box. They don’t just share their plan — they rally everyone around a common vision for where the product is headed and why. And a well-defined roadmap is their communication tool of choice.

What is a product roadmap, you ask? Great question.
Product Roadmap: A Definition
A product roadmap is a shared source of truth that outlines the vision, direction, priorities, and progress of a product over time. It's a plan of action that aligns the organization around short- and long-term goals for the product or project, and how they will be achieved.

What is a product roadmap?

Unlike a traditional map, product roadmaps aren’t simply navigational guides. They also make clear:

  • The rationale for the product, including its target market and/or customer persona
  • The resources involved in developing the product, including people, tools, and time
  • The vision for how the product will serve your customers and help execute on your business strategy

Roadmaps tend to be more conceptual documents that illustrate the steps toward your product vision. They are often grounded with objectives—clear, measurable, inspiring goals aligned with specific outcomes you’re striving to achieve for your customers, product, or business.

In that sense, product roadmaps sit one layer above release plans, which are the execution-level plan of how you’ll deliver the work that you’ve decided to do and the timeframe when that work will be completed.

“A good roadmap is a strategic communications tool, a statement of intent and direction, and, done well, a way of rallying the whole organization around the key problems that must be solved to achieve your product vision.”

An excellent roadmap is a strategic and tactical communications tool. It states your intent and direction with key priorities. It’s a shared and up-to-date guide to where you’re going, why, and how you’ll achieve your product vision. 

An excellent roadmap shows outcomes or product user impact. Focusing on the “why” clearly communicates intent, direction, vision, and success. Teams align on shared goals supporting product strategy. 

An excellent roadmap creates functional alignment and collaboration. It rallies everyone around a common product vision and direction. It incorporates stakeholders’ insights and input, reflecting customer needs.

An excellent roadmap reflects customer feedback. It delivers value by supporting customer needs and concerns. 

An excellent roadmap is tailored to your specific audience. Different types of roadmaps work best with different stakeholders. You can choose which views best support how you want to communicate and rally your organization around your product vision.

 

diverse feedback white blue yellow red dots graphic

Who manages the product roadmap

Although the product roadmap will affect everyone in an organization in some way, it needs a central point of ownership in order to remain clear and consistent. This is really the domain of a Chief Product Officer, VP of Product, a product manager, or someone in a de facto product role if formal titles don’t exist in the company.

That doesn’t mean product roadmaps should be managed in a vacuum. The process works best when collaboration is at the forefront. This can mean starting with high-level input from executives and then reaching out to a line of business leaders for regular consultation and communication.

The roadmap owner is not only responsible for being as inclusive as possible, but for filtering all the input so that goals, features and timelines can all be changed as necessary. Then it’s a matter of sharing the roadmap at the appropriate time so that no one is taken by surprise on where a particular release is at.

Steps to start building your own product roadmap

Now that you have a general sense of what product roadmaps should do, let’s look at the four steps to take to start building your own.  

Step 1: Align on product vision, strategy, and objectives

To define a clear product vision and strategy, consider what type of long-term outcome and benefit you want to deliver to your users. This is a collaborative process where product leaders work with executives to translate company vision and strategy into a product vision and strategy.

When creating your product vision & strategy, it’ll be helpful to consider the following: 

  • What you want to achieve in the near-term, mid-term, as well as further into the future
  • Insights from prospects, colleagues, & customers 
  • Market trends
  • Technological trends
  • Competitive intelligence
  • The company’s business model
  • Unique differentiators

Once product vision and strategy are set, product teams can break them down into objectives to tackle over the near- to mid-term in relation to key date-based milestones (like when they’ll need to raise money again).

Product objectives should be high level enough to represent a worthy outcome for your customers or product, yet specific enough to help guide your prioritization decisions around which features to build next. They can be derived “top-down” from company objectives or “bottom-up” based on user insights you’ve received, market intelligence you’ve gathered, or your product strategy. Here are a few examples of good product objectives: 

  • Help users perform core job-to-be done X
  • Close core feature gaps experienced by user role Z
  • Expand customer base to three new regions

Step 2: Prioritize what to put on your roadmap based on desired outcomes

Once you align the product team behind a common product vision, strategy, and objectives, it’s time to prioritize the products and/or features that will go on your roadmap. The following inputs are a great place to begin: 

  • Insights from prospects, colleagues, and customers
  • Market segments that your product serves
  • Date-based milestones, such as conferences, industry events, or marketing campaigns
  • Capacity planning—what is the bandwidth of your team?

This step can become a little overwhelming given the sheer volume of information you’re working with, as well as the competing needs of stakeholders from both in and outside your organization. 

Support may want to focus on fixing bugs, for example, while sales is more interested in a new feature requested by a promising prospect. And though your customers are a valuable source of feedback, they tend to voice the solutions they think they need rather than their underlying problem. Despite the challenges, gathering and synthesizing these inputs changes your thinking from “I know what we should put on the roadmap” to “We’re putting this on the roadmap because of XYZ.” A product prioritization framework can help you take a more quantitative approach for assessing inputs. It can also be helpful to have a tool that organizes all of these insights in one place.

Check out The essential guide to prioritization to learn more about this step

Step 3: Build your roadmap to summarize your plan

Now it’s time to create a working draft of your roadmap that communicates the products and/or features you are building, when you will be working on them, roughly when they will be released, as well as why they are a priority vs. all of the options that were considered. To make your roadmap informative and easy to understand for your end audience, try including these elements:

Timeline. Even in the agile world, it is important to set expectations around when short-term, medium-term, and long-term features will roll out so other teams can plan around them. We’re not talking about specific dates or deadlines. Instead, show a general time, such as the month. 

Solutions. Communicate what features you want to roll out in the above timeline. You can be as high-level or as detailed as you want, just explain why you are including each feature to give context. 

Strategic context. Let all teams know where the product is headed and why you’re building these features next. Currently, only 52% of product teams are confident that their roadmaps reflect the strategic context behind what they’re building. If some roadmap decisions are hard for certain stakeholders to swallow, strategic context helps them to understand the rationale behind tough trade-offs, even if they don’t personally agree with it.

Step 4: Communicate your roadmap and rally the team

The final step is to rally everyone around the roadmap and empower them to get the information they need. For example, you can set up a regular meeting cadence or send emails updating the team about any product roadmap changes. Here at Productboard, we host a weekly product call that is open to the whole company where we look at a roadmap tailored for a large audience.

Provide product roadmap access to all members involved in the product lifecycle—from development to go-to-market. An easy way to do this is through a product roadmapping tool like Productboard, where stakeholders can view and track changes at any time with a consistent, single source of truth.

With Productboard, you can manage access to the roadmap and hide certain features based on roles and permissions—every stakeholder’s roadmap can be tailored to their exact needs. Once stakeholders have access, they can click on features and releases to learn more about the context, like what problem you’re trying to solve and which objectives you’re addressing. They can even see the customer feedback behind each feature or release. 

This self-serve approach is much more powerful than a static slide that’s quickly outdated and forgotten. Keep in mind that roadmap needs vary from stakeholder to stakeholder. Using multiple roadmaps tailored to different audiences can be extremely helpful. Here are a few common types you might want to try out. 

  • Use delivery-specific roadmaps with granular timelines for development teams that want to know the details. Communicate objectives, status/stage of development, areas of your product, and account for other work they need to support. Leverage dependencies and capture risks. 
  • Use an objective-led roadmap focused on broad timelines for senior executives and stakeholders and make sure you include information such as the market opportunity & profit & loss details. 
  • Use an objective-led roadmap with customer-facing teams like sales, marketing, customer success, and support to help them see what you’re delivering feature-wise to support your objectives and provide details on the target customer. Leave room in your roadmap for go-to-market activities. 

You can see how this approach benefits all teams—engineering knows what they are accountable for and when. Customer success can thrill and delight customers and be clear about what you are and aren’t working on. Sales can close more deals because they can share with confidence what’s likely to be done and when. Product marketing can communicate new functionalities with great fanfare. And support can let customers know when new features are likely to be launched. All without asking the already overburdened product manager!

Types of product roadmaps every product leader should know

The types of roadmaps you explore should be driven by the nature of the products you’re developing, the business outcomes you’re pursuing, and the kinds of stakeholders with whom you’ll be collaborating.

We’ve developed a comprehensive post on 7 types of product roadmaps which is worth reading in its entirety, but here’s a quick summary to get your research process started: 

  • Release plan: Many products are not one-and-done in terms of their development. SaaS products or even consumer mobile apps are expected to improve with successive versions. A release plan is a good way to plot these milestones at a high level without committing to a particular timeframe.
  • Sprint plan roadmap: If you’ve ever been exposed to the Scrum framework, you might be familiar with hour-long, timeboxed planning sessions where everyone agrees on the backlog of items to complete. More appropriate for product and development teams, sprint plan roadmaps clarify delivery schedules and keep people aligned.
  • Now-Next-Later roadmap: A Now-Next-Later roadmap can be used to manage the expectations of larger groups of stakeholders, including an entire company or even customers. Just make sure “later” isn’t positioned so far into the future that people wonder if the items there will happen at all.
  • Kanban roadmap: When someone asks, “What are you working on?” your answer probably falls into one of three areas: the backlog of tasks that can’t be ignored and the features or changes you’re planning or are in the process of developing. Kanban roadmaps work well for this, especially because you don’t have to commit to a specific timeframe. They’re more about giving visibility into your near-term strategy.
  • Features timeline roadmap: For many products, significant new features can drive increased usage, revenue, or both. That makes it well worth getting granular about key dates and what kinds of resources are involved in reaching feature milestones.
  • Objectives timeline roadmap: Companies may be known for the products they offer, but products ultimately are about executing on an overall strategic plan. This type of roadmap spells this out in detail, looking at what the work product teams do mean for customers, partners, and other stakeholders.
  • Release timeline roadmap: We started releases, but this time you’re putting dates to specific bug fixes, app versions, and feature advancements. The deadlines ensure strong cross-functional collaboration. A release timeline can also be a great tool for measuring progress.

What is an agile roadmap?

With its focus on requirements discovery and iterative work done by self-organizing teams, agile development has transformed organizations where previous approaches like Waterfall were the norm. 

Product leaders can achieve similar results with agile roadmaps because they combine rigor around timelines and responsibilities with an ability to change in response to unforeseen factors. 

Consider an agile roadmap if your organization is serving a customer segment that is often in flux, when you’re expanding into new markets or use cases, or even if you just want to bring greater clarity about how products are changing, and why. 

How to build an agile roadmap

Though agile roadmaps may look slightly different from one organization to another, some common principles should apply: 

  1. Know the “why — and lead with it: The first value in the Agile Manifesto is “Individuals and interactions over processes and tools.” In that sense, your agile roadmap should be focused on your overall product vision. This includes the problems you’re trying to solve, why those problems are important, and why your unique approach to solving them is the foundation for your brand identity. The way you execute on that vision may take many forms, so make sure your agile roadmap focuses on flexibility over following rules. 
  2. Think dashboard-level details vs. a deep dive: An agile roadmap is based on simplicity. You’re trying to create something that will serve a dynamic range of stakeholders, so getting deep in the weeds on every single bug fix probably isn’t necessary. Be a good editor and only include what will drive decisions and action. 
  3. Aim for near-term results: Companies like Amazon are often poster children for agile development in that they release new software every few seconds. That may not be realistic for your company, but an agile roadmap should look for shorter timescales that could range from weeks to months compared to a traditional 12-month product plan. 

Finally, remember that agile is not simply about working quickly, it is meant to reflect what customers are saying they want and need. Think about how you can build feedback mechanisms into the agile roadmaps you create, whether it’s from trusted customers or simply members from cross-functional teams. 

Interested in more on product roadmaps?

Check out some of our more popular blog posts on roadmaps.

Plan, visualize, and share your product roadmap

Productboard does more than building product roadmaps. It helps you decide what should even go on the roadmap.
No credit card needed, free 15-day trial.