Product Roadmap: How to Build and Communicate

Product Roadmap: How to Build and Communicate

What is A Product Roadmap?

Product Roadmap is the representation and communication of the product strategy of the company for the next 6-12-18 months. It can be in the form of a document, powerpoint slide, a gantt chart, etc. You can use tools available online to build a roadmap.

Why is it important?

Early on in my career I used to wonder why it’s necessary to have a published roadmap. As part of the product team I was pretty aware of what was going to be built in the coming months.  It was only later that I realised that every team is busy focussing on their work and probably don’t breathe product in and out each day. A published roadmap is critical for the success of any product team. Here’s why:

1.Promotes a culture of transparency in the organisation
2.Aligns the different teams towards common goals
3.Inspires the organisation
4.Creates excitement about the future
5.Empowers everyone in the team to scrutinise it

Who is it for?

Each stakeholder is looking for something particular in the roadmap. For example:

1.Customers who want to know what they can expect in the short and long term
2.Prospects evaluating the product against everything else out there
3.Investors who want to see the strategic direction that the company is taking
4.Engineering team who want to understand the technical competencies needed in the coming months
5.Sales team looking to understand features that would fulfil use cases for their pipeline
6.Marketing team looking to build their own roadmap on how they would build out the marketing programs to support the releases

What Factors Influence the Roadmap?


The roadmap has to be consistent with the company’s vision. Achieving the roadmap should bring us close to achieving the vision. For example- Your company’s Vision is to “Make Collaboration easy through Technology”. In your product roadmap you showcase an online store to sell your office merchandise. That will make heads turn. The roadmap needs to make logical sense in the company’s quest to achieve its vision.


Vision is where you want to be in the long-run. Goals are targets you set out for yourself in the near-term. They are more specific. The roadmap should focus on initiatives that will balance the short term goals with the long-term vision. It should meet the customer needs in the next 6-12-18 months while also making investments that would enable you to be competitive in the future. For example- Your goal is to increase revenue in the financial year by 17%. The product roadmap should have specific updates that help achieve that goal.

External Feedback from Users

In an ideal world you want to be able to build everything your customers want. That isn’t always the way it works. Working through the feedback you get from users on a regular basis will help you discover themes or patterns in them. For example the data might point to issues on one part of the product or a missing feature in another. Represent customer needs in the product roadmap through updates to your platform. It shows that the company listens and takes customer feedback seriously. The customers in return become more loyal to the brand, eventually becoming evangelists for your product.

Internal Feedback

There is no dearth of great feedback coming from different teams. Treat it the same way you would one that comes from customers. See if you can draw parallels between what internal users versus customers are saying. Is it the same? Is it different? Is it consistent overtime? Most internal feedback especially from the the customer facing teams can be traced back to the customer 😆. I’ve often seen engineering and design teams offer feedback that is unique and thought-provoking.


Your product roadmap should reflect how you will respond to the evolving face of the competition. You will not be able to do this in a day. It is important to take out some time each week to look into what key competitors are doing and what prospects are saying about them. Track how your product compares to them. Do a feature gap analysis and keep it updated. Identify the ones that need to be fixed.

How do you Start Building a Roadmap?

All this can sound overwhelming! Don’t worry it’s not. Product Roadmaps are not built overnight. They are a culmination of cross functional collaboration between all team led by product managers. But it doesn’t end there. It then becomes a live document that needs to reflect the changing needs of the business. So you will have to shuffle things around and make changes. It’s not a great habit but it will happen 😶

You can organise your roadmaps in a couple of ways:

Theme based

You can have different themes and projects under them. For example- Improving Customer Onboarding can be one of the themes. Redesigning of the signup flow can be a project under it.

Objectives based

You can also state your objectives at a high level. Then club different development projects under them. For example- Your objective might be to increase revenue by 17%. And you group together work aimed at achieving it.

Once you have done the above follow the steps outline below:

Step1: Identify all the problems by going over feedback from different sources ?

Step2: Filter the ones that should be considered worth spending time on. Use three filters in this step:

Is this Urgent
Is this pervasive
Are customers willing to pay for it

The reason for this is that you might have hundreds of ideas. Not each of them needs to go through the same amount of effort and due diligence.

After this step prioritise the ideas based on data you have, consultations with stakeholders and vision of the company. There are lots of great frameworks you can use to do that. From the very simple ones to more complex ones. Take your pick.


Intercom prioritises features based on four variables and stack ranks them based on the RICE score(R*I*C)/E:

REACH: The percentage of users who will use a feature
IMPACT: The value of the feature for users
CONFIDENCE: How confident are you in the data that you are providing
EFFORT: Resources needed to build and launch the feature

Kano Model

It prioritises features based on customer satisfaction and the implementation effort required to get it out the door.

All features are assigned a category depending on the value you assign to the two variables:

1.Basic: The product doesn’t work without them
2.Delightful: Initial effort into these features will delight the customer. But it tapers of after a point
3.Performance: Customer satisfaction is directly proportional to the effort you put in.

MoSCow Method

This method groups all the work into four buckets.

1.Must Have
2.Should Have
3.Could Have
4.Won’t have.

You assign resources to the Must Haves first and then move down to Should and Could Have. Won’t have is category of things that you don’t intend to tackle in the short and mid term.

Story Mapping

As the name suggests you map out the journey of how customers use the product. Divide the journey into different segments. List out different actions that make up a segment. This provides one view to all the stakeholders. Now work with the stakeholders to prioritize work within each segment.

Product Roadmap is subject to change 😭😭😭

You might have given a full fledged product roadmap presentation to a packed house. And within a few weeks you have to shuffle things around and add new items to the roadmap. That means bumping a few off the roadmap. It can be frustrating. But business is always changing and you either adapt or perish.

At times flexibility can hurt the productivity of the team more than the gains it provides. As a product manager you are the gatekeeper who balances the need to be flexible but not so much that it brings development to a stand-still. You do this by doing the due diligence on the new items and analysing whether they in-fact qualify to be higher up in the prioritised list of ideas.

The goal is always to provide as much stability as possible to teams doing downstream work.

How do you Communicate a Roadmap

Communication is dependent on the audience. Build a master roadmap that you can share with the entire company. Then build customised ones for key stakeholders that can highlight and focus on things that interest them.

Presentation of the roadmap should only include high level information about the project. Steer clear of getting into the nitty gritty details of implementation. Not everyone needs to know about them. But always be prepared and ready with all the finer details in case it ever comes up in Q&A sessions.

It is easy for roadmap sessions to get out of hand. Here are few things you can do to avoid them:

1.Share the final roadmap a day ahead of the presentation. It gives people time to go over it in advance of the presentation
2.Define the agenda before the start of the presentation
3.Be clear about how much time you will spend on each section of the roadmap
4.Keep at-least the last 20 minutes for Q&A
5.Some questions will end up becoming a discussion on implementation. It might not be relevant to the entire team. Park those questions for a side discussion after the presentation
6.When you present to customers or prospects do not commit to anything. Because as discussed above product roadmaps are always subject to change!  And the last thing you want is your customers making a commitment to their customers based on your commitment to them . Yes that’s a very long sentence 🥲 . Read it again if you need to!
7.The jury is still out on whether you should show Tech Debt in a roadmap. My take on this is that it depends on the audience. For internal teams I show large tech debt items as part of the roadmap. Otherwise the question comes up “What is the rest of the engineering team working on??“. When presenting to customers I do not show tech debt. Because most of them don’t care about it or worse they might look at it and start having doubts on the stability of our platform

In the end it’s all about balance! A roadmap that keeps in mind the needs of users and business NOW while anticipating what they will be in the FUTURE will make the desired impact.

You may also like