How to Read a Roadmap Like a Product Manager When You’re Not One

This is a big day. Your product team have shared their roadmap and let you, a non-product person, read it. You’re here because you’re asking yourself how to read a roadmap like a product manager and how to make the most of this opportunity for better cross-team collaboration.

Having access to the product roadmap gives you the opportunity to understand your product’s vision, objectives and direction, and in turn helps you have better conversations with your colleagues and customers. Pretty cool, right?

But where do you start? How do you get the right information out of the roadmap and what are you supposed to take away from it?

If you’re finding this a little intimidating, don’t worry. No one starts out a roadmap expert. Most product managers thought dates were necessary on a roadmap till not too long ago… 😜

We’re here to help. Think of us as your spirit guide! After this you’ll know what a roadmap is for, how to read one, and how to guide better conversations.

Your product team will be so impressed they might just make you an honorary member, and more likely start to open up more channels for getting involved in the product management processes.

What is a product roadmap?

In the words of our CEO Janna Bastow,

“a roadmap is the prototype of your strategy.”

This means that as a communication tool, the roadmap will be forever changing, always updating based on research, feedback, market demands, and previous outcomes. If your PM shows you a roadmap, don’t take it as a final plan and get defensive if it doesn’t meet your expectations. Use it as an opportunity to understand their assumptions, and give your input.

Think of it as a similar approach as your UX designer showing you wireframes of a new functionality that might be coming. You don’t give them a hard time because it’s not perfect – the whole point of the exercise is to catch mistakes early on! Likewise, when your PM is showing you their roadmap, they are showing you their prototype for the product’s strategy.

A roadmap is not a set document of features to be built. Rather it focuses on the following key points:

• What is your team working on?
• Why are they working on those ideas?
• How do those ideas tie back to the set OKRs?

The roadmap is designed to communicate problems to be solved and open up the conversation for the entire team around how to solve them.

Understanding the Roadmap

With this in mind, let’s analyze the different areas of a roadmap to understand what it is we are looking at.

Time Horizons

The first thing you will notice is that the product roadmap does not contain any dates, unless sparingly, where they are strategically important and externally driven. This is to remain flexible as priorities and outcomes have an impact on the work being done.

A solid product roadmap will focus instead on time horizons. These are buckets of time, usually made up of three columns:

1. Now: Stuff that you are currently working on. This can include work in discovery and prototyping stages, work in development, or even ‘finished’ work that’s being validated.
2. Next: Stuff that’s coming up soon.
3. Later: Problems that likely need to be tackled in the future, but need to do a bit more research before you move on.

Some roadmaps may include potential upcoming items as well as completed items, so you can understand the work that’s previously been completed.

Initiatives

Within each column, you will see initiatives. These initiatives represent projects your team will undertake.

These initiatives talk at a very high level about the work to be done, without digging down into specifics of execution or delivery. This is about understanding the strategy behind this decision – what your team is doing and why they are doing it.

In general, initiatives should focus on highlighting the following information:

• Initiative name
• Description (Problem to be solved/benefits of solving these problems)
• Objective
• Idea pipeline (The experiments to be tried, in order to solve the problem)

At ProdPad, we represent these initiatives in what we call roadmap cards. Aside from the information above, we also display the following information:

• Initiative owner
• Tags (showing teams/product areas – easy for filtering)
• Impact/effort
• Team discussion

Objectives

Before your team starts any work, they need to understand how this work will impact your overall objectives. Objectives are helpful in making sure the team’s strategy is focused.

Each initiative will be linked to a set of objectives (likely more than one.)

This will give you an idea of what area will be impacted by this work.

Here’s an example: Let’s say that your team has chosen to adjust the onboarding flow.

They’re doing this because they’ve found several gaps and, looking at conversion figures, they are aware that improvements can be made to this flow.

The objectives impacted: Reducing Churn, Growth

This gives your team something tangible to measure. If churn reduces and growth numbers are up, we know the changes made had a positive impact.

Tying it all Together – How to Read a Roadmap like a Product Manager

Once you put all these items together on a single document, the roadmap might look something like this.

You can easily spot:

• Initiatives being considered
• What product areas are involved
• The scope of each project (what/why)
• What objectives are being met
• Where in the time horizon these items are

Turning the roadmap into a conversation piece

Now that you have all the information, problems to be solved and the objectives to be met, take this opportunity to use the roadmap as a conversation piece.

With the right information at your fingertips, you can now ask your product team the right questions, allowing them (and yourself) to manage expectations better.

With better conversations happening, they’ll feel more confident about opening up the product process more and more, giving you better insight into the world of product management.

As a bonus, the next time a customer asks you for a particular feature, show them the roadmap your product team has shared. Talk to them about your team’s objectives, what problems will be solved, and how this benefits them directly. They are likely to be more understanding once they have a full view of everything that is being done, as opposed to solely focusing on that one feature they’ve requested.

Open communication and transparency can only lead to great conversations.

That’s it – That’s the magic mix of how to read a roadmap like a product manager!