Introduction

Product roadmaps serve as strategic guides to help keep a company aligned and on track with plans and goals for the products they’re building.

Imagine a product team develops a high-level vision for a new product, presents the vision to the key decision-makers, and receives approval to move forward. Now what? Can the Product Manager simply create a list of features and ask the Development Team to build them? Will that list convey to the Developers why they’re building these features? And on what basis will the Product Manager prioritize which functionality gets built into the first version of the product?

To address these and many other strategic questions, the Product Manager needs a guiding document to help capture, prioritize, track, and share the plans and objectives for the product. That guide is the product roadmap.

A roadmap is an invaluable strategic resource for another reason as well: It’s one of the documents that many stakeholders across an organization rely on to stay aligned and current on the company’s strategic plans and goals. Sales pitches, marketing plans, and budgeting documents tend to stay within their respective departments, whereas the product roadmap often serves as a uniting strategic blueprint that keeps these disparate teams steering in the same direction.

And although crafting, maintaining, and sharing a product roadmap successfully is a skill that Product Managers can learn, it’s not always an intuitive process. In fact, many product teams find effective roadmapping to be one of the biggest challenges they face.

When we surveyed hundreds of product professionals around the world for craft.io’s 2023 State of Product Management report, many told us that they’re frustrated with their product roadmap process for several reasons.

 

So, we’ll dive into features, types, and examples of product roadmaps to give you an in-depth view and guide to how composing and maintaining the right roadmap can help you drive and reflect better product decisions across your entire product portfolio, and create better products more efficiently.

What is a product roadmap?

A product roadmap is a strategic document that helps a Product Manager visualize a high-level plan for a product, share that plan with relevant teams and key decision makers, and provide everyone with an ongoing reference they can review anytime to make sure they’re executing according to plan.

You can think of a well-built product roadmap as a single source of truth helping to keep stakeholders aligned around the current plans, priorities, and strategic thinking related to the product. While this is the goal, it’s extremely difficult to execute properly, but we’ll get into that later.

A product roadmap is one of the core tools a Product Manager uses to drive a product successfully to the market and monitor continuous work on its evolution. If you build and share it properly, your product roadmap will help you:

• Plan and prioritize what you’re building
• Communicate your vision to decision-makers and other stakeholders
• Generate enthusiasm among your company (and even users) for your product
• Articulate the strategic reason behind each item on the roadmap
• Give everyone a reference point to make sure they’re moving in the right direction
• Track and share an estimated timeline of what’s to come

Who is responsible for the product roadmap?

For companies that follow best practices, this is a simple answer: The Product Manager owns the product roadmap.

It is the Product Manager, after all, who is ultimately responsible for the success (or failure) of the product when it reaches the market. That means the strategic document that the entire organization uses to guide the development, marketing, sales, and continuous improvement of the product — the roadmap — should always be under the Product Manager’s control.

That is not to say the Product Manager should keep the roadmap under lock and key after creating it. On the contrary, an important part of a Product Manager’s job is to maintain the roadmap as a living document, updating it frequently to reflect new realities and priorities, and sharing the latest version with all relevant stakeholders across the company. (We’ll discuss how to do that below.) The roadmap should indeed reflect the buy-in and input from other stakeholders across the organization.

But while individuals and teams throughout the organization should always have access to the up-to-date roadmap — and the product team should encourage questions about it from these stakeholders — only the Product Manager should be tasked with making additions or changes to the product roadmap. This is a best practice in that it’s another way to ensure the roadmap serves as a single point of product truth.

Where does the product roadmap fit into the planning process?

Building a product that resonates with the market requires research and strategic planning. For the results of that legwork to be reflected on your product roadmap, you’ll need to go through those steps first — before you begin developing the roadmap itself.

In fact, the roadmapping stage should take place within a well-ordered sequence of strategic steps that look like this.

The steps that should lead up to building your roadmap

• Define (or review) your company’s mission
• Define (or review) your company strategy
• Establish your product strategy
• Determine your OKRs (or KPIs)
• Develop your backlog
• Build your roadmap
• Continuously iterate, as it’s a cycle, not a linear progression to one final point

If you prefer a visual depiction, the diagram looks similar to the following. (The one exception is that the image below represents the strategic hierarchy, not the order of steps. You’d actually work on the bottom rung – the backlog – before building the next-to-last one, the roadmap).

 

Let’s assume you work for a company that’s been around for some time, as opposed to a new startup for which you’re building your first product.

In that case, you can jump straight to step 3. Here’s how product expert and CEO Melissa Perri defines product strategy: “A system of achievable goals and visions that work together align the team around desirable outcomes for both the business and your customers.”

Developing a product strategy will require thinking through important issues such as:

• What problem are we planning to solve?
• Who are our personas?
• What, if any, competitive products already address these challenges?
• If no competitive solution exists, how are our personas dealing with the challenges today? Why will our product represent an improvement over those workarounds?
• What will our key differentiators be?

With a rough sketch of those strategic details, you can move to step 4 and determine which metrics you’ll set to know what success looks like. For example, are you hoping to reach a specific number of free-trial users within 6 months after launch? Will the product’s success depend on hitting a revenue number within a specific timeframe?

And now that you’ve arrived at both a high-level product strategy and a set of OKRs or KPIs to monitor, you’re ready to begin building the roadmap itself.

Strategic inputs (OKRs, personas, etc.)

What gets included on a product roadmap?

Because the product roadmap is designed to present a strategic view of what’s happening with the product, you’ll want to include only the strategic-level elements of your planned work.

Planned strategic work (either in progress or scheduled for near-term work)

• Initiatives
• Epics
• Features (and stories)
• Subtasks

View dependencies across roadmap sections

Timelines

Product roadmap vs. product backlog: An important distinction

For an item to make it onto your product roadmap, it must either be in development or agreed upon and planned for future development within a reasonable timeframe (even if your team won’t begin work on it for many months).

All other work items that you and your team have compiled — such as suggestions or requests from stakeholders, or lower-priority feature ideas — belong on your product backlog. The product roadmap represents precious strategic real estate and should be limited to items your team has vetted and determined are worth pursuing now or in the near future.

How do you prioritize your product roadmap?

At this point, you’ve done your strategic legwork. You’ve fleshed out your solution’s value proposition, gotten to know your user or buyer persona, and studied the competitive landscape to identify any gaps in the market.

As you sit down to develop your roadmap, you and your team will probably have a list of potential features to address the market need you’ve uncovered. And because those early brainstorming sessions are often the most exciting time in a product’s evolution, chances are your team has come up with lots of ideas. How will you decide what to build first? How will you decide whether some of those ideas were your own projections onto the user and not worth developing at all? The items that make it onto your roadmap should clearly reflect the need they are set to meet and the business initiative answered in your product strategy, and the roadmap itself should be responsive to changes in customer feedback on the competitive landscape. As we’ve said, a roadmap is a living, breathing document.

Choosing a prioritization framework

The product management community has adopted many prioritization methodologies to help product teams objectively evaluate initiatives and figure out which ones will yield the best return on investment — whatever that means to a given company.

Among the most popular prioritization frameworks that can help you make smarter product decisions, there’s Value vs. Effort, RICE, MoSCoW, Weighted Scorecard, WSJF, and others.

With Value vs. Effort, for example, you’ll assign two numerical values to each item on your list: one to estimate how much work, time, and resources it’ll consume (the effort), and the other to estimate its potential value to the company. Divide value by effort, and you have your score. As you do this exercise for several initiatives on your wish list, you’ll begin to arrive at a prioritized plan of attack for beginning work on the new product.

Note: If you’re using the right product management software, you’ll actually find several of these prioritization frameworks built into the roadmap tool itself. That means you can simply click a few buttons to begin prioritizing your initiatives based on your chosen framework. And you’ll be just as easily able to switch between prioritization frameworks if one isn’t working for your team. Ideally, you should even be able to customize your formulas for increased precision to understand, rank, and reflect your needs.

If you want to see how to do this in practice, with a real-world product management solution designed to help you with effective prioritization, book a demo of craft.io.

How do you build a product roadmap?

As you start building your product roadmap, the key principle to keep in mind is flexibility. Roadmaps are not static documents that you create once, show to your team, and then save as a file you’ll never open again. Nor are they an image you print out and stick on the wall. They are like product management itself – dynamic. In fact, treating this strategic document as a static file is one of the biggest roadmapping mistakes Product Managers make.

Product roadmaps change. They evolve regularly with the changing needs of your market, priorities or resource levels of your company, and other strategic realities that are often in flux.

That’s one reason (among many) that you do not want to start building your product roadmap using a tool meant for presentations or spreadsheet creation, especially with the rest of your strategic background information stored elsewhere. With this type of tool or assorted collection of tools (this time the whole is not more than the sum of the parts), each time you need to adjust something on your roadmap, you’ll need to manually update the content in your file’s text boxes, bullets, slides, cells, rows, etc.

That’s a time-consuming nightmare for Product Managers who’ve had to develop and maintain their roadmaps using these static tools over the years. As a result, they often just don’t return to the roadmap much, if at all, during the product development process. And that makes this all-important strategic document less useful both to the Product Managers themselves and to all stakeholders trying to contribute to the product’s success. The price of this is less the desertion of the existing roadmap, but instead the lack of organization and efficiency that comes with aligning around a well-built roadmap built on best practices. Roadmaps are like roads, we build and use them for a reason.

Creating a brand-new product roadmap

If you’re looking at a blank page (or slide or spreadsheet), you’re going to find it difficult to create a roadmap from scratch, because you’ll need to build and populate every component of the roadmap manually: layout, hierarchy, the product data itself, a color-coding scheme or legend to indicate what specific items mean, etc…

This is just one of many reasons to use a purpose-built roadmapping tool designed for product managers. But assuming you’ve found such a solution, you’ll have a couple of options for populating your new roadmap with data.

With a purpose-built solution for product roadmaps, you can begin adding new product data directly into the platform. In the craft.io screenshot below, for example, you can select the relevant release and from there create or assign epics.

After this, you will be able to assign stories to the epic and add OKRs, user personas, and other strategic inputs to give the item more context.

Alternatively, if you’ve already built some of your product data in Jira, you can import that content straight into your roadmapping environment (in our case, workspace). You can even set mapping rules to ensure the data transfers exactly as you want it across the platforms — where Jira epics and stories are imported as epics and stories.

Common types of product roadmap you can use to visualize and present your content

There are numerous ways to slice, dice, and view your product roadmap data. You should be able to leverage any and all of them, depending on the circumstances.

Because roadmaps serve many strategic purposes, and because different types of stakeholder meetings will require a focus on different aspects of the roadmap, you’ll want to make sure your roadmapping solution offers flexibility in terms of how you arrange, filter, and display the data, and the types of insights you’re able to glean as a result.

Here are a few examples of the different types of views and the roadmaps you can create by making smart use of the right view for each story you need to tell. For more, check out our ebook on roadmaps or read this blog on 5 awesome roadmap examples.

Strategic Product Roadmap

This roadmap displays a high-level strategic overview of a product. The contents you choose to highlight will depend on your circumstances and stakeholder audience, but common high-level details on a strategic product roadmap include a breakdown of the planning, estimated timeframe, work assigned to each team, and goals for the product.

In the example screenshot below, this strategic roadmap displays a swimlane view, where each row is a lane representing work to be done on a specific area of the product, and each column represents a timeframe (in quarters).

With the right roadmapping solution, you can also add a third dimension to your product data. In this craft.io screenshot below, for example, we’ve added a third strategic element, the columns breakdown, which you can see in the gray text just above each card. This additional piece of strategic data describes the objective for that section.

In other words, the craft.io strategic product roadmap allows you to see the work allotted for each area of the product, and what strategic goal each work item (i.e. epic) will contribute to the product’s overall success.

When to use it:
The strategic roadmap view is ideal for cross-functional team meetings when the product team wants to step back and take stock of how each product crystallizes work to deliver value on business objectives and which elements are allotted to each quarter.

Release Roadmap

A release roadmap presents your epics, goals, current progress, and anticipated timeframe relating to an upcoming product release (or multiple releases).

As you can see from the screenshot below, this release roadmap created with craft.io displays several planned product releases on a timeline and includes detail about each release’s assigned epics, the features or user stories under each epic, and the current progress (represented as percentages complete) of each item.

When to use it:

You’ll want to switch to a release roadmap when you and your team want an up-to-date picture of the progress made toward the planned launch. You might also want to use a release roadmap when your executives ask whether things are on track for the product release and want you to walk them through the details of all the moving parts.

OKRs Roadmap

An OKRs roadmap is a specific type of strategic product roadmap that lets you view your progress across different criteria — teams, epics, timeframes — to see what each has contributed to a specific Object and Key Result.

In the craft.io screenshot here, for example, you can see we’ve arranged the roadmap data to display the columns as releases (one per quarter), the rows as our Objectives (for example, “reduce churn”), and the column break-down as Key Results (such as “10% increase in paid users”). Here we leverage the Swimlane View to see the information on multiple axes, as you can see in the screenshot below.

When to use it:

Use an OKRs roadmap to show your team, executives, or other stakeholders a big-picture view of which areas of the product are generating the greatest measurable results, what products these data suggest it makes sense to focus on next, and how everyone’s work has been contributing to your product’s market success.

How to present your product roadmap to get buy-in

One of the valuable roles your product roadmap will play in your product’s success is helping you to earn the buy-in (and, ideally, the enthusiasm) of stakeholders throughout your company.

To make your product as successful as it can be, you will need the contributions of many teams: development, sales, marketing, customer success, etc. And even before that, you’ll need to gain approval to move forward with the plan you’ve laid out for your product. To achieve both of these strategic goals — earning buy-in for your plan, and then persuading your contributors to bring their A-game to their roles — you’ll need to present your product roadmap in compelling and persuasive ways.

Note the term “ways,” not way, in that last sentence above. The most effective approach for presenting your product roadmap will differ based on the situation and the stakeholder audience. A great feature option is the ability to filter and show only the relevant information to different stakeholders, including password protection for views to limit access. Flexibility of presentation is crucial to making sure you tell the right story each time.

Here are a few examples of how to present your roadmap, based on the audience:

Presenting your product roadmap to executives

If you’re sharing your roadmap with senior-level decision makers — and asking them to green light your plan — you’ll want to limit the roadmap details you display to the issues these executives will care about, such as:

• Markets, industries, and user personas targeted
• Revenue estimates
• Potential for gains in market share

By contrast, you won’t want your product roadmap displaying multiple levels of tactical plans: epics, all stories under each epic, and features and subfeatures also showing). Your executives will want a high-level view of your strategic plans, not every detail behind it.

Presenting your product roadmap to developers

When you first present your product roadmap to your development department, you have the dual objectives of gaining their thumbs-up for your plan in general and beginning to discuss how to break down your big strategic ideas into actionable assignments for their teams. Your developers will be looking for several details here, including:

• Epics you’re proposing for the product (in priority order)
• Your estimates on timeframes
• Stories and other work you’ve identified under each epic

Note: For all stakeholder audiences (executives, developers, sales, etc.), you should also be ready with evidence — or at least a concise explanation of your strategic reasoning — for every item displayed on your roadmap. If an exec or developer asks you why you’ve chosen to prioritize Epic XYZ, you need to have a compelling answer ready.

In fact, one best practice of your product roadmap presentation to any audience is to offer evidence or reasoning for every roadmap item you review. That will make your presentation — and the concept of building the product itself — much more compelling to your stakeholders.

How can you make roadmapping easier and more effective?

As we hope we’ve made clear, the ability to switch quickly and easily between different types of roadmap views can be invaluable for saving time, presenting highly relevant information specific to the participants in every product meeting, and ultimately helping your team build better products.

The strategic importance of purpose-built roadmapping tools

However, for most of modern product management history, PMs have had to manage by cramming their roadmaps into applications never built with roadmapping in mind, and juggling the management of different elements across different tools, still not arriving at a good enough approximation of a purpose-built solution. Creating a timeline roadmap in a presentation tool, for example, meant PMs would need to completely recreate the roadmap in a new slideshow file if they had to present a different level of detail to a different stakeholder audience. That’s where craft.io comes in.

craft.io’s purpose-built product management platform offers multiple roadmap formats built in out of the box, and is sufficiently flexible to be customized for specific audience needs, whether you’re producing roadmaps to share with customers, developers, investors, or senior management. And once everyone has full transparency into the product management processes, feedback collection, collaboration, and engagement naturally improve.

Using craft.io, you can create roadmaps that will help your organization keep track of the bigger picture, become proactive instead of reactive, and develop true, cross-organizational alignment.

To learn more about roadmapping, check out our ebook here.

Want to try craft.io? Start your free trial now.
(Yep, it’s that easy.)