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:

Who is it for?

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

What Factors Influence the Roadmap?

Vision

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.

Goals

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.

Competitors

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:

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.

RICE

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

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:

MoSCow Method

This method groups all the work into four buckets.

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:

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.