« Back to Planio Blog

Jory MacKay on February 01, 2022

Jory MacKay

Jory is a writer, content strategist and award-winning editor of the Unsplash Book. He contributes to Inc., Fast Company, Quartz, and more.

February 01, 2022 · 15 min read

If you’re on a road trip and want to reach your destination on schedule and without wasting a ton of gas, you need a roadmap. The same goes for your product. Except instead of a single car navigating a lonely highway, you’re guiding a group of bikes, boats, mopeds, and trucks coming from all over the map.

That’s why a product roadmap is the backbone of every great development team. It’s the single source of truth that tells everyone from engineers to stakeholders where you’re going and why you’re going that way.

But unlike a traditional map, the landscape your product roadmap navigates is constantly shifting. And unfortunately, too many teams treat roadmapping like just another project, leaving it behind to collect dust as they move on and start building software.

In this guide:

An effective product roadmap isn’t a static document. It’s a living guide that brings together your vision, business goals, daily tasks, and even the industry landscape. Without one that’s effective, realistic, and consistently updated, you’re guaranteed to get lost.

This guide focuses mainly on developing a roadmap for engineering teams. However, you can use the same process for a leadership roadmap, sales roadmap, IT roadmap, or even an external customer-facing one with some minor adjustments.

What is a product roadmap?

A product roadmap is a visual representation of your short- and long-term priorities as a company that helps you plan, build consensus, and communicate high-level decisions. It’s the next logical step in turning your product vision and strategy into actionable projects and tasks your team can work on each day.

In fact, you should definitely not think about your roadmap until you have a clear strategy in place. Your hierarchy of high-level planning should look something like this:

1. Mission: What are you trying to achieve?
2. Vision: What does the world look like when you’ve achieved it?
3. Strategy: How will you achieve your vision?
4. Goals: How will you measure your progress towards it?
5. Roadmap: What do you need to build to get there?
6. Tasks: What can you do today to move forward?

However, while most people associate roadmaps with planning, they’re most useful as a communication tool.

A product roadmap explains why you’re building what you are (i.e., your strategic vision) as much as what you’re building. This connection helps align teams on a central goal and shows how a product might change and grow over time. Here is an example from Jeff Gothelf from 2017:

For example, software teams use product roadmaps to identify customer problems (aka goals) that relate to their overall strategy and then prioritize features and bug fixes that solve them.

However, it’s a mistake to try and include too much detail in a roadmap. Instead, your product roadmap should stay mainly focused on why you’re prioritizing specific tasks over other ones. Leave the details for your launch plan, scope of work, and project schedule.

Why you need a roadmap (even as an agile team)

Roadmaps are powerful communication tools. However, several other major benefits come from using one. Specifically, product roadmaps:

1. Back up your vision and strategy. First and foremost, roadmaps are communication tools. They’re the single source of truth for anyone unsure about your product vision and priorities.
2. Create an action plan for bringing your strategy to life. Roadmaps are detailed but stay high-level enough to be understood by everyone. They give visibility to the significant steps needed to hit your goals without getting lost in the details.
3. Get stakeholder buy-in and team alignment. The level of visibility that comes from a roadmap (hopefully) inspires trust and confidence in your plan from the top to the bottom of your organization.
4. Make space for discussion and scenario planning. A roadmap is a discussion, not a decree. They allow everyone to ask questions, voice concerns, and give feedback before you start using up resources and time.
5. Build excitement and boost motivation! Teams aligned around a core purpose and understand their company’s mission are more productive and profitable. A roadmap is one of the most important tools for getting everyone on the same page and inspired for the future.

Roadmaps are essential for bringing clarity and focus to the hundreds (or thousands!) of moving parts that make up every project and company. Rather than a long list of tasks or an unorganized backlog, a roadmap communicates precisely what to do next and why it matters.

However, the level of detail you include in your product roadmap will change depending on the software development process you use.

For traditional (aka waterfall) teams, roadmaps are the holy grail of product planning. Before you start building, you need every step towards the launch meticulously planned and organized. A roadmap ensures you’re working efficiently and know what needs to be done and in what order.

But what about Agile teams?

As we wrote in our Guide to Long-Term Agile Planning, Agile roadmaps focus on outcome-driven planning. So, instead of working towards a specific feature or product, the goal is to solve user problems and change their behaviors in a way that ultimately helps you reach your business goals.

While your end goal stays fuzzy, an Agile roadmap clearly articulates why you’re heading in a specific direction and has enough details to power at least your team’s next few sprints.

Who is responsible for making the product roadmap?

Coming up with your product roadmap should be a team effort. While it can be tempting to shroud product prioritization in mystery, teams thrive when you value transparency and candor. This is especially true if you’re working on multiple products or supporting legacy software.

However, roadmaps can quickly suffer from death by discussion. Ultimately, the product management team (or product manager) should be responsible for what makes it onto the roadmap and updating it as needed.

How to create a product roadmap in 9 steps

A good product roadmap needs structure. And what better structure to use than the four project lifecycle phases you’re already familiar with?

As you create your roadmap, break up the process into:

1. An initiation phase. This is where you conduct research and build context around the product you’re building.
2. A planning phase. This is where you decide on the desired outcomes, find problems to solve, and prioritize related features.
3. An execution phase. This is where you break down large epics into validated tasks, balance short- and long-term goals, and present your roadmap to stakeholders and the rest of your team.
4. An ongoing monitoring stage. This is where you measure success and update your roadmap as needed.

Let’s break down each of these phases into a few specific steps you can take. We’ve also included several product roadmap examples below you can use to see what a finished one looks like.

1. Start with research and context-building

Product roadmaps serve two purposes. First, they communicate your goals and priorities. Next, they build support for your plan throughout the company.

To begin, think about the audience for your roadmap. Your engineering team’s internal roadmap will focus on different elements than one designed for executives. Who’s looking at this artifact, and what do they expect? When you eventually present your roadmap, it pays dividends to have a clearly defined audience.

Next, think about the current state of your company.

Product roadmaps mature and change alongside your company’s growth. A product roadmap for a startup building an MVP differs greatly from a more mature company balancing multiple products across different markets. Here’s an example:

Before you even start thinking about outcomes, features, or priorities, make sure you’re in the right headspace.

2. Decide on the desired outcome(s) based on a business need

Product roadmaps are outcome-driven planning, especially for Agile teams. This means they focus on the change you want to achieve to further your overall strategy. The features or products you build are just a means to an end.

The best place to start is with a business need. In other words, what is the desired outcome for your roadmap and why does it matter?

Revisit your strategy and vision to find areas of impact. Or, dig into your other resources like market research, competitor analysis, internal requests from stakeholders, external requests from users, or even existing tasks in your backlog.

Gather some teammates and key stakeholders together and brainstorm a few critical elements:

• Desired outcome: What is the business need you’re trying to solve? For example, “become the top retailer of iPhone cases in North America.”
• Impact metrics: What metrics signal that you’re solving a problem in the best way possible? For example, increase revenue by 15% or increase average order size to 3 items per customer.
• Behavior change: What user behaviors need to change to hit your goals? For example, you could increase revenue by focusing on top-of-funnel users or upselling current ones, or even focusing on reactivating churned customers.

These elements give your product roadmap a narrative that goes from the strategic to the tactical.

A great product roadmap is realistic and idealistic at the same time

3. Find the right problems to solve

Now, it’s time to look at the current state of your product and how you can change user behaviors to get you closer to your desired outcome.

We like to think of this as solving the right problems.

What are the user problems you can solve to impact your metrics and business need?

There are several places to identify problems that connect to your desired outcomes:

1. Customer feedback. User interviews are, by and large, the best way to uncover user problems. However, if you can’t speak directly to customers or want more data sources, look for feedback from sales, marketing, customer support, and other user-facing departments.
2. Product backlog. You’ve probably already identified a giant list of tasks, issues, and problems to solve. As you look for problems, groom and update the user stories in your backlog. For each, ask if they provide value, have an owner, and still fit within your overall product strategy.
3. Usage data. Customers don’t always tell you what they want. Instead, look at how they actually use your product for problems, barriers, and friction points you can potentially solve.
4. Competitor/market analysis. You want your product to be a leader, not a follower. However, it’s still important to keep a pulse on the problems your competitors are solving or how the market is evolving.

Take time to go in-depth on your problem discovery. Finding the right problems to solve that will help you reach your desired outcome is the basis of a roadmap that brings results.

4. Set a timeframe

A roadmap needs a destination. Based on your desired outcome and the problems you’ve identified, set a rough yet realistic timeframe.

Are these problems with seemingly quick solutions you can test in a few months? Or are you committing to significant strategic changes that could take years to implement fully?

Remember, change takes time. However, a product roadmap should signal progress early on, so you’re not committing to blindly chasing outcomes for years on end.

5. Organize problems into high-level themes

At this point, you should have what looks like a bit of a reverse funnel going from a specific desired outcome to a few impact metrics and then a big list of problems to solve (and probably some existing backlog items that fit).

Desired outcomes (based on business needs) → Impact metrics (to track success) → Problems to solve (that will change user behaviors)

It will be a bit messy. However, it’s important to visualize this flow from goal to potential solution (and see how many different paths lead to the same outcome).

You don’t want to jump into a single solution yet. Product work is a combination of experience, data, and intuition, and it’s a mistake to get tunnel vision when developing a product roadmap.

Instead, look at your list of problems and try to identify themes that tie them together.

For example, if you’re trying to grow your iPhone case business, your list of problems to solve might include:

• Get users to sign up for our newsletter
• Increase repeat purchases
• Ask past users for reviews
• Create a white-label service for other businesses
• Boost average order size

A few of these problems all land under the theme of ‘customer loyalty.’

Some people refer to a theme as an initiative. But really, it’s just a destination on your roadmap. It can be an action, result, or even a specific aspect of your product.

You’ll probably end up with a few of them, but resist the urge to put them in any sort of order yet. Instead, just use them to start organizing your problems and backlog tasks.

In Planio, you can use categories to organize issues and tasks by themes.

This way, you can quickly see which tasks are associated with your theme when it comes time to prioritize tasks and plan your sprints.

6. Prioritize features and themes into initiatives

Now, it’s time to put things into order.

Roadmaps are an exercise in prioritization. You’ll have several paths you can take to reach your desired outcome. However, it’s up to you to decide which one to take.

Prioritizing is an art in itself (we’ve even written an entire Guide on How to Prioritize Features). However, there are a few common exercises you can use to get started:

1. Feasibility, desirability, and viability. Judge features based on how technically possible they are (feasibility); if your customers want them (desirability); and if they support your overall product strategy (viability).
2. Effort/cost and impact scale. This prioritization method is a simple 2x2 grid where you score features by how much impact they’ll have based on their effort. The goal is to look for high-impact, low-effort/cost features.
3. The RICE method. This method goes a bit deeper by judging a feature on a few categories. First, how many people will it impact in a given period? How much will it affect your strategy and goals (on a scale of 1–3)? How confident are you that it will be a success (out of 100)? And how much time will it require from the product, design, and engineering teams? Multiply each number together, and you’ll end up with a ‘total impact per time worked’ metric.

Finally, don’t forget that prioritizing is just another name for sequencing. Just because something isn’t at the top of your list doesn’t mean it won’t get done eventually.

Don’t jump into a single solution too soon. Developing a product roadmap is a combination of experience, data and intuition.

7. Set quarterly OKRs to measure the success of your initiatives

Now that you have a prioritized list of themes and associated features, it’s time to put them in some sort of order.

A good product roadmap builds on itself, so each milestone or release sets up the next one.

Even as an Agile team, it’s OK to make long-term guesses to base your roadmap on.

However, shifting from high-level plans and prioritized features to daily tasks is where most product roadmaps fall apart. Yet, the ultimate goal of any roadmap is to make sure that what you’re doing today connects to where you want to be in the future.

The best way to keep your daily task list tied to your overall product strategy is with Outcomes and Key Results (OKRs).

OKRs are a goal-setting strategy made up of two parts:

1. Outcome: This is what you want to accomplish. For example, this might be completing a feature or making progress towards your desired outcome.
2. Key Results: This is how you’re going to measure the success of your work.

Think of an OKR as a roadside marker on your journey–it tells you where you are and how much progress you’ve made.

Here’s what a quarterly OKR might look like for our iPhone case company:

“We will increase customer loyalty as measured by repeat purchases and monthly newsletter subscriptions.”

OKRs are great for setting quarterly goals for your product roadmap and having a way to assess and judge their success. Then, you build off of what happened and adjust your roadmap accordingly.

The feedback from Q1 will influence your roadmap for Q2 and so on. This way, rather than your roadmap existing as a static document, it’s constantly adapting and changing based on your actions, progress, and new research.

8. Move your roadmap into software to keep it flexible and agile

Congratulations! You now have pretty much everything you need to present your product roadmap and get buy-in. But let’s go a step further.

Roadmaps establish trust between you and your development team. But this only happens if everyone has access to them.

A project management tool like Planio is a central source of truth for your product roadmap, strategy, and sprints. This way, everything is connected and accessible. For example, you might translate your sprint tasks into a simple Kanban board to give everyone a high-level view of what’s being worked on and how it connects to your overall roadmap.

Moving tasks into your project management tool is also a good time to validate issues and requests.

• Have you groomed your backlog and updated user stories to reflect your new OKRs and desired outcomes?
• Are you balancing building new features and maintaining current ones so you don’t take on too much technical debt?
• Does each feature connect to your prioritized themes in a way that tells a clear story?

Finally, do you have the talent and resources to actually pull this off?

It’s great to plan for using new technologies or building your team, but those both take time.

A good roadmap thinks big but starts small. Make sure you’re using the resources available to you now.

9. Review and align your roadmap with other internal teams

Building a product roadmap requires deep analysis, consideration, and compromise. Unless you’re a one-person operation, you’ll also need to balance the needs of the rest of your organization.

Try to collaborate with other teams and stakeholders early in the process to get their feedback. Ask questions such as:

• What problems do you feel are most urgent? Why do you feel that way?
• What industry trends are you seeing that you think we should be aware of?
• What do you think will happen if we don’t act on this feedback or build this feature?

Keep conversations short and focused, but try to have them on a regular basis. Remember, roadmap alignment is an ongoing process.

How to organize your roadmap: Free product roadmap examples

The above guide is a step-by-step process for identifying your desired outcomes and then breaking them down into a prioritized series of themes, quarterly OKRs, and even tasks.

However, you’re probably still wondering what does this roadmap look like?

How you visualize a roadmap is personal and depends on how your team works and the level of detail you’re including. But the key is this: keep it simple. Too much or too little detail and you lose the narrative between vision, strategy, and problems.

Here are a few product roadmap examples you can use to find the style that’s right for you:

Basic product roadmap example

A roadmap can be as simple as a prioritized list of features or tasks associated with a theme or goal. Here’s an example from former Airbnb PM, Lenny Rachitsky:

As Lenny writes:

“With this very basic framework, you’ll immediately identify 80-90% of your best opportunities and, more important, have a starting point for conversations with your team and team leads.”

Agile product roadmap example

An Agile product roadmap gives a light structure to your product strategy while still leaving room to implement user feedback.

The Agile product roadmap is an exercise in balancing chaos and order. You can make strong guesses about where you’re headed and what to build to fill out an Agile board. But ultimately, your roadmap will shift based on feedback.

Gantt chart product roadmap example

For teams with a clear plan from project initiation to launch, a Gantt chart gives you an overall view of your product roadmap.

For example, in Planio, you can create a Gantt chart from issues and then automatically track progress over time.

This is a great way to identify dependencies and make sure you’re not going to hit any roadblocks.

Presenting your roadmap to get support

Roadmaps need support from two essential groups: leadership and the development team. However, this is where things get tricky.

Each group has its own needs. Leadership wants to focus on business needs and how your roadmap will impact their strategic goals. While dev teams want to know what you’re committing them to, if it’s realistic, and how it’s going to fit within their current workload.

Here are a few best practices for presenting your product roadmap and building support throughout the company.

Preview the roadmap with trusted sources

The success of your roadmap presentation comes down to tailoring it to your audience. Know who you’re talking to and what they need to hear. It can be helpful to enlist a few trusted sources to preview your presentation and ask questions you might have missed.

Keep your narrative clear

Storytelling is an essential product management skill. Use the research you started with to create a clear narrative. What’s the business need? What are your desired outcomes? How did you come up with the problems to solve and prioritize the features and tasks that will solve them?

Provide context, anecdotes, and inspiration–anything that will help you build your business case and get everyone on the same page.

Stay high-level

Presentations go off the rails when you get into the deep end. Avoid getting into the weeds of individual features before you’ve clearly established the need and benefits.

Instead, stay high-level and leave the specifics of task management for your project plan or sprint planning in your project management tool.

Be realistic

Your presentation needs to show that you understand and respect your development team’s time.

If a feature doesn’t have an ironclad reason for being on a roadmap but is still there, you can bet your development team will be rolling their eyes. In many cases, you might be stuck with an explanation that ends with ‘management wants it.’ However, take the time to explain your reasoning and stand behind it.

Be motivating, but don’t ignore the mundane

Development teams want to work on new and exciting features. But roadmaps are a balancing act between innovative new features and the must-have basics that keep your product working flawlessly.

Use metrics to drive your message home

Whenever possible, use data and research to justify your choices. If you found user problems through analyzing usage data, bring it in. If you’re working off a hunch

Touch on what comes next

A product roadmap doesn’t exist in a vacuum. Instead, briefly explain what the future holds after you launch your MVP or V1. This could mean your launch plan, QA/testing plan, or just how you’ll handle continuous improvement. Keep your audience looking forward to your vision of the future.

Be open about what you don’t know

Estimations are a part of product management, and it’s a mistake to look like you know everything. Point out where you need to do more user research or experimentation to validate ideas and adjust your roadmap.

Best practices for keeping your roadmap updated and actionable

We’ve all stumbled across long-forgotten planning documents that are painfully out of date.

So as a final note, remember that a product roadmap is only valuable if it’s up-to-date and actionable.

1. Set a weekly time to check on your roadmap and make updates. This doesn’t have to take hours. Instead, just use what you’ve learned in the past week to make notes and suggest updates to the roadmap.
2. Listen to your marketing and sales teams. Customer-facing teams are usually the first to know when customer behaviors are changing. Work with them instead of excluding them from your roadmapping process and business growth strategies.
3. Regularly re-evaluate and deprioritize features. Not everything that makes it onto a roadmap needs to stay there. Try to think about what you can remove to solve user problems rather than only what you can build.
4. Talk to your customers. Surveys are easy ways to make sure your roadmap is up-to-date. You can ask specific in-app questions or send regular surveys asking what they’d keep or kill.
5. Know who’s looking at your roadmap. Different audiences use roadmaps for their own purposes. Executives may use it to get strategic resources, while sales could use it with customers to try and close bigger deals. Make sure you know who’s using it and why so you can update it accordingly.

A great product roadmap is realistic and idealistic at the same time

Roadmaps are powerful tools. But the real world rarely works according to our plans.

Instead, a product roadmap needs to be flexible with eyes to the future but feet planted firmly in the present. Start with a business need, find problems to solve, and then work it into a clear and actionable product roadmap, and your entire company will have the guidance they need to move towards your goals.