Product Roadmap — Why do you need it, What is it, and How to create one

Some form of a roadmap or a plan that helps the team know what to build next has existed for a long time. 

Yet, many product managers struggle to understand the true meaning, need, and the process of building a roadmap.

In this guide, I will deconstruct the roadmap into the most basic form so you understand what it takes to create world-class roadmaps.

Let's start with the basics:

Why do we need a product roadmap?

Before understanding "what" a roadmap is, let's understand "why" we need one.

A roadmap is essential to help the entire team move in the right direction and achieve multiple goals:

1. Impact:

A roadmap ensures that the team is investing in solving the highest-impact problems. It also ensures that the team is NOT investing in low-impact ideas.

2. Priority:

A roadmap is essential to help everyone know the sequence in which the team will solve the x problems mentioned above.

3. Collaboration, coordination, and alignment:

A roadmap ensures everyone is on the same page, working on the correct problem statements, and heading in the same direction.

4. Communication:

Roadmap alignment is also an excellent opportunity for teams to share feedback, ideas, and comments that should all improve the quality of the roadmap.

5. Iteration:

Roadmaps are not set in stone, as they shouldn't be. Well-crafted product roadmaps allow teams to iterate and make changes if and when needed.

So, now we know that a roadmap is essential to unlock impact, align priorities, collaborate, communicate, and be flexible to changes.

Let's understand what it means in the real world.

What is a roadmap?

It is a list of problems you want to solve and the sequence in which you solve them.

This list is well thought out and researched. It focuses on the most critical problems that will help you meet the goals you set out in the product strategy. 

So, a roadmap is -- a list of sequenced problems. It is as simple as that. Nothing more. Nothing less.

The process of building should also be super simple. And to do that, I use a simple Google Sheet for the entire process.

Here is a screenshot of a roadmap for a hypothetical product (CalmMe that helps users disconnect digitally, have a better device-to-life balance, and improve their mental health)

Now, let's understand the process I use to build a roadmap.

How to build a roadmap:

I follow a simple three-step process. I have written about it (here and here). But here is another simplistic view.

1. Ideation: identify a long and high-quality list of problem statements. 
2. Prioritisation: filter and prioritise them based on impact on the goal. 
3. Alignment: ensure that relevant people agree with the priority. In case they don't, collect feedback and iterate.

Let's understand what we are doing in each step and, more importantly, why each step is essential to the overall process.

Ideation:

This step aims to ensure you have a high quantity and quality of problems.

Quantity:

Having a large number of problems as a starting point is essential. 

It encourages you to think holistically, which is essential to making the right tradeoffs. 

Another reason to build a long list is to ensure that you consider most, if not all, possible options while selecting the ones to focus on and discarding the ones that are low impact.

But don't add ideas for the sake of it. Just focus on including holistic and diverse opinions.

I do two things to think holistically:

Comprehensive sources of information:

I enrich my list by seeking ideas from many sources (like user feedback, data, market research, competitive analysis, etc.)

Idea buckets:

I think of problems in buckets which are relevant to my product maturity and goals. For example, in mature companies, I think of three buckets:

1. Big Initiatives/ Big Bets: This bucket includes new ideas that will need non-trivial effort to build. Thinking of ideas for this bucket forces me to think big and beyond the incremental ideas.
2. Enhancements: This bucket is primarily for ideas that help improve and maintain existing features and capabilities. Getting ideas for this list forces me to be cognisant of all the existing capabilities and ensure I give them the right amount of attention.
3. Market / Competition catch-up: inspires me to think of ideas to ensure that we are not lagging behind the market or the competition.

Quality:

There is no objective way to measure the quality of a problem without actually building it. But a few things help:

1. Impact: include ideas that have a significant impact on the goal. Ignore ideas with low or unknown impact.
2. Strategic alignment: exclude ideas that do not align with your product strategy.
3. Enablement: include ideas that enable other ideas that have a high impact.

With that said, this is by no means the perfect or the only way to gauge the quality of the ideas. But it generally helps.

Prioritisation:

I keep this extremely simple — 

1. I estimate impact and cost.
2. I normalise impact and cost
3. I sort by impact
4. Then, sort by cost
5. Then, use judgment based on other variables like dependencies, strategic focus, etc.

Many PMs complicate step 1. They build mathematical models and formulae to estimate the impact. I want to remind you — the goal of "estimating impact" is NOT to calculate an accurate number. The goal is only to get enough of a sense to know the relative ranking of the features. So don't waste time figuring out if the impact of feature A is $1Mn or $1.2 or $1.21. Instead, determine if the impact of feature A is more or less than that of feature B

(This post shows an example of the above process.)

Alignment:

This step is critical to do at the right time. As soon as you have the first version of your roadmap, start sharing it with relevant stakeholders to do two things:

Feedback and expertise:

partner with stakeholders close to the customers, business, or product and get their feedback and ideas. Use meaningful ideas to improve the quality of the roadmap. Ignore the rest.

Alignment:

work with those who are critical to the success of your product, and let them know "what" you plan to do and "why" so that they agree and buy into your roadmap.

Also check: Create an effective annual product plan with these 7 steps

The biggest challenges that PMs face and the mistakes they make:

Let's accept it — the above sounds easy in theory, but in practice, it is far from it.

The biggest challenges:

Challenge # 1: Making the roadmap realistic (but impactful) can be tough

I've been in situations where I couldn't think of anything significant or different to create an impact or excite my senior leaders. The only ideas I had were incremental with relatively low-impact.

Mistake: As PMs, we make imaginary limitations. Saying things like "We can't build Feature A because we don't have the required skillset in-house", or "Let's discard this idea, as leadership will not increase the team size", or "I can't think of any good ideas."

Solution: In such cases, I repeat the "Ideation" step. I consciously ask myself, "What limitations am I applying to my thinking?" If that doesn't work, I do the Elon test by asking — "What ideas would Elon Musk have if he were building a roadmap for this product?"

So, the lesson here is that you need to force yourself to broaden your thinking and not limit your creativity. Just find any trick or hack that helps you zoom out, and do that.

Challenge #2: Prioritising well

Mistake: make the process too complicated or not having confidence in your priority order

Solution: At the expense of being repetitive, I will say again — this step needs to be simple. Do NOT complicate it. Do NOT build complicated models.

Secondly, seek a second opinion if you're not confident of your priorities. Talk to your manager or senior PMs and show how you reached your priority order. Please don't ask them to prioritise the roadmap for you. Instead, ask them to find flaws in your approach and how to correct them.

Challenge #3: Delivering the intended impact

Mistake: The team estimates effort incorrectly, or does not execute well, or both.

Solution:

1. Work closely with engineers to ensure their estimates are as accurate as possible. Again, the goal is not to calculate the exact number of hours or days it will take. But the goal is to get a fair estimate. A 10-20% deviation is acceptable.
2. Ensure you do not skip the "Alignment" step. Often, PMs fail to deliver on the road, not because the ideas are bad or the estimates are off. Instead, they fail because they don't get the support of the right people at the right time.

Challenge #4: too many changes to the roadmap

Mistake: A roadmap is not set in stone, but many PMs and product teams consider it to be.

Solution: think of a roadmap like a GPS. You input the destination, and it tells you the best route to get there. It gives you options to choose from different routes. Some have tolls, some traffic, and some bad roads. You make a choice based on your goals. Then, if the initially decided route is not the best anymore, it lets you know and gives you the chance to update your selection.

A roadmap is the same. It should give you the best route to meet your strategic goals. But if, during the journey, you find that the original plan is not the best anymore, you should iterate.

Being adaptive and agile is more about the mindset than the process. Product managers must accept that circumstances will change, which will demand iteration.

So that is it. That is almost everything I know about roadmaps.

Everything I shared here is from my real-world experience, failures, and learnings.

I still create roadmaps, and this is the exact approach I follow even today.

To see this in more detail with an actual example, please check my recent course here.