DEPARTMENT OF

PRODUCT

PRODUCT
ROADMAPS
Discover how to create a product roadmap that ensures stakeholders truly
understand your priorities and delivers your vision with impact
departmentofproduct.com
What’s a roadmap anyway?
A Product Roadmap is a device which allows product managers and product
teams to communicate the direction, vision and priorities of their product.

The roadmap is a living, breathing, dynamic tool which evolves and changes
over time. It’s an essential part of the product management process. You’d
think since product managers are tasked with so many difficult things to
juggle at the same time they’d make light work of something as simple as a
document which tells the business and the teams what’s coming up next for
the product team.

Not so.

The truth is that many product managers struggle to know where to start
when it comes to building product roadmaps. There is such a mind-boggling
array of different ways to create and present your roadmap that product man-
agers often end up feeling overwhelmed by the number of options available to
them.

Some product teams don’t have any roadmaps or if they do they get produced
for a 1 off stakeholder meeting to update everyone what on earth the ping
pong team have been up to for the past 6 months. Then the deck gets left a
folder on Google Drive which anyone can open ‘if they’d like to take a look’.
Nobody wants to take a look. And it’s not opened until the next product
roadmap meeting.

What roadmaps are:

• Simple, clear communication tools

• A high level overview of priorities designed to communicate your product
plan
• Organic, dynamic, evolving over time

What roadmaps are not:

• Excel spreadsheets with lists of things to do

• Your product backlog
• A 54 page powerpoint deck

How to create a product roadmap

The development of the product roadmap is not typically down to 1 single
person but rather, it is a collective, team effort. Whilst this may the case, it is
often the responsibility of 1 person to physically create the roadmap. If you
work in a larger organisation this may be the Senior Product Manager / Head
of Product, with the more junior product managers feeding into that. If you’re
a product person at a smaller company or startup, it’s likely that you’re the
only product manager and that you are responsible for developing the roadm-
ap along with your CEO.

You may also have a series of different roadmaps – one for each level of the
business. The exec team may be best suited to a roadmap which outlines the
product plans at a more strategic level whilst individual scrum teams may
have a separate roadmap which they are working towards as an autonomous
group.

Depending on your level in your organisation, you will need to tailor your
roadmap for the audience it is designed for.

The first step to creating your roadmap is to collect your inputs. Inputs typ-
ically include feedback, insights, analysis and requests from the following
sources:

1. Stakeholders
2. Team members
3. Data points
4. Customers
5. Idea generation

1. Stakeholders

Shying away from stakeholders and hiding in a meeting room for a week may
lead to some fresh perspectives on problems you’ve been facing but wilfully
neglecting the views of your stakeholders won’t win you any favours.

The Head of Sales is wondering when their team will be getting that automat-
ed messaging feature they’ve been promised for the past 5 years.

The Customer Service team need to stop relying on 3 separate systems to pull
their weekly reports and they want an invoice generating machine that works
in ‘1 click’. Like magic.

The Marketing Manager wants to know when the CRM is likely to be re-
placed by something more modern than the archaic monster you have in
place today.

Your role as a product manager is to involve your stakeholders and to ensure

their concerns and requests are heard during the product strategy and roadm-
ap creation process. Having a dedicated business backlog can help facilitate
this process.

If you work in a smaller organisation / startup you’ll no doubt be in constant

communication with your stakeholder team and may even sit on the same
bank of desks. If you’re a product manager at a larger company you might
want to consider creating a Product Council. Whilst this sounds like it be-
longs in the United Nations, it can be an effective tool for managing input
from stakeholders.

The Product Council

The Product Council is a meeting with all your key stakeholders from rele-
vant departments where you discuss various priorities and each stakeholder
makes their case for what they need and why. This can work to facilitate not
just communication between you and your stakeholders but also between
stakeholders themselves; often they’ll forget that there are 12 other depart-
ments each with their own priorities and bringing them together in 1 room
can help to reiterate this point and make compromise easier.

Ultimately you cannot and should not aim to please all your stakeholders.
In fact, I’d go as far as to cheekily suggest that you have failed if you haven’t
peeved off at least 1 stakeholder. That sounds a little harsh so let me explain.
Making 1 stakeholder unhappy about your choices proves that you have made
a tough, strategic decision to not do something. Promising everything to
everyone and producing a diluted version of everyone’s ideas is the worst case
scenario.

2. Team members

Your team includes not just your typical stakeholders (heads of department)
but also your engineering team, designers, UX, QA folks too. Often, there can
be nuggets of information or hidden gems stored within your team. The team
may talk amongst themselves about what might solve a particular problem
but not always feel like it’s their place to decide what goes in the roadmap.
This culture can be corrosive and can prevent you from solving your biggest
problems in unique ways.

Encourage your team to share ideas, whatever they may be. Encourage even
‘bad’ ideas or ideas that seem ridiculous. The objective is firstly to help your
team overcome their fear of speaking up and secondly to create a culture
where ideas can come from everyone and be considered equally; a bad idea
from the CEO is just as bad as a bad idea from a UX person. A good idea
should also be treated equally and there is no place for idea snobbery in a cre-
ative team.

3. Data points

As a product manager, you’ll no doubt have identified some key metrics that
matter to you and your product. If you don’t have any metrics that you’re
measuring on a frequent (at least monthly) basis then get some.
But the act of measuring data in and of itself is of no value to anyone. The
value of metrics is derived from the discoveries you make. Discoveries can
often be discovered by asking interesting questions about your product:

• Why is our API revenue down YOY?

• Is there a difference between our registration completion rate between
desktop and mobile?
• Why have our virality metrics for referrals increased in Europe?

Use data points and insights to help you to identify trends which help you to
build your roadmap. Find data points which link to your overall goals and
objectives.

If you know that nobody is visiting the part of the site that the Head of Sales
wants to completely rebuild, use the data to reinforce your reasons against
dedicating 3 months of development work to it and instead make a case for
building something which you can prove there is an appetite for with data.

4. Customers

What do you mean you haven’t spoken to a customer in 6 months? How

naughty.

With everything else that’s going on on a day to day basis in product manage-
ment speaking to real human users can sometimes be difficult to manage. But
if you don’t do this then you simply have no idea what you’re building.

Conduct regular UX sessions, customer panel feedback, NPS scores and sur-
veys to build as clear a picture as possible of the human beings who are actu-
ally using your product and factor this into your roadmap creation process.
You’ll often discover small nuggets of insights which would have been impos-
sible to know inside your 4 walls.

But don’t just build what your customers tell you to build. Instead, take the
feedback and evaluate it alongside the other inputs as part of the wider con-
text of your business, your product and your market.

5. Idea generation
Before you commit to a new roadmap, consider creating some entirely new
ideas. Ideas which are not derived from data analysis, customer feedback or
stakeholders. These ideas are yours. They’ll come from inside your head.

I’m all for teamwork and collaborative working but the truth is, working in
complete isolation can often be an extremely effective way to generate ideas.
Studies show that the groupthink effect of brainstorming sessions can lead to
less creative ideas than if participants are tasked with coming up with ideas
alone.

Consider blocking out an entire day to isolate yourself from the rest of the
team and generate your own ideas. This isn’t to massage your ego; this is
designed to help you to think creatively. If you’re struggling to generate ideas,
check out our guide to mastering the currency of ideas.

Solitude is surprisingly effective at generating ideas, but don’t do this at the

expense of also generating ideas with the wider team.

Step 2 – curate your inputs

Once you’ve gathered your inputs, it’s time to do something with them.
You’re going to need to whittle them down into priorities that you can in-
clude on your roadmap. How do you do this? Glad you asked.

1. Re-engage with your product goals and strategy

As a product manager and a product team, you should be setting yourselves
goals. Popular methods for doing this include the OKR framework. You may
have overall company goals which can be factored into this process but this is
specifically about the product and setting product goals.

Aim to keep your goals simple and limit them to a number you can count on
one hand. Keep them specific, measurable and memorable so that everyone is
clear about what it is you are trying to achieve.

With your inputs gathered, check each of them against the product goals you
have.

2. Ask questions

In order to prioritise all the various inputs, ask yourself key questions which
relate to your overall product vision, goals and strategy.

Questions to ask

• How does building this help us achieve our goals?

• What problems does this solve?
• What happens if we don’t do this?
• What evidence do we have to suggest this will succeed?
Your product vertical will generate questions that are more suited to your
industry, business and market. Pick some questions that are helpful to you.

3. Use prioritisation frameworks

Prioritisation frameworks are a popular method for prioritising inputs before

creating a roadmap. Here’s some of the most useful prioritisation frameworks
you can use:

Impact vs. effort

Plot the item on a chart with axes; one for impact and one for effort (where
effort is defined by you and your team). The low hanging fruit may (rightly)
be the things you decide to tackle in your roadmap. However, be wary of al-
ways opting for the easy high impact stuff. Sometimes you need to tackle the
more difficult high impact challenges to achieve breakthrough success.

Impact vs. goals

Plot the impact of the item vs. the overall goals of your product. If it doesn’t
help you achieve your goals in any meaningful way, why are you doing it?

Value proposition
Assess the item against your fundamental value proposition. For example,
if you work on a product which teaches people to learn new languages, ask
yourself whether your item helps people learn new languages.

The Kano Model

The kano model is used to plot product features vs. customer expectations.
Items can be categorised as one of 3 categories:

• Basic expectations – does your product meet your customers’ basic ex-
pectations? If there are gaping holes in your product which mean it is not
meeting the basic needs of your customers then these should take priority.
Without a solid foundation which meets basic needs, sexy new features
are irrelevant.
• Satisfiers – meets the ‘wants’ of your customer. Whilst basic expectations
are a must, the satisfiers go a little further in meeting a desire of your cus-
tomer. These are things which are not absolutely necessary for your prod-
uct to function but are nice to haves – and are desires that your customers
know they have.
• Delighters – items which genuinely go above and beyond standard cus-
tomer expectations to delight your customers. Your customers didn’t even
know they wanted this since it’s beyond their expectations for a product
like yours.
Your roadmap should contain a healthy mix of these 3 categories. Plotting
your inputs onto this model can help you to assess how much effort is being
put into items which will truly delight customers vs. meeting a nice to have.

Step 3 – create your roadmap

With your inputs curated, and your decisions about what it is you’ll be adding
to your roadmap, the next step is to create the roadmap in a way that will help
you communicate it.

There are numerous ways to present your roadmap but before you create it,
consider some guiding principles which should be followed, irrespective of
the type of roadmap you create.

Guiding principles

• Keep it clear and simple – the primary purpose of your roadmap is to com-
municate; communicating your roadmap to your team, your stakeholders
and the rest of the business. If it’s not clear and it’s not simple it’s more
difficult to communicate.
• Format – pick the format that is suited to your product, team and stake-
holders. If you know that there is no way your stakeholders are ever going
to log into a Trello board, reconsider whether this is the right format.
• Be disciplined – don’t be fooled into thinking you can create 1 roadm-
ap, put it in a folder and forget all about it. Be disciplined and keep your
roadmap updated and evolve it over time.
 The Department of Product

ROADMAPS
Diagrams to help you develop and
communicate your product roadmap

FREE DOWNLOAD
Gantt traffic light roadmap

Perhaps the most simple and most common way of designing a roadmap,
this traditional template allows your stakeholders to quickly see at a glance
what’s on the horizon.

Items are prioritised using the high / low priority axis and are given a traf-
fic light color to indicate the overall health of the feature / project. Red
indicates unhealthy / delayed / blocked and green indicates healthy and on
track. A traffic light system can be updated every few weeks to keep the
business updated.
Theme based roadmap

Items on the roadmap are grouped thematically. Themes can be decided by

you / your team and are designed to allow you quickly see how much of the
overall roadmap is allocated to a particular theme.

Time is expressed as ‘current’, ‘near-term’ and ‘future’ to avoid committing

to absolute deadlines. A rough indicator of time is better than the tedious
‘this is agile so there are no timelines’ response. Stakeholders would prefer a
steer on timings, even if it’s wildly caveated with subject to change depend-
ing on factors outside of your control.
OKR roadmap

Your goals / OKRs are stated at the top of the roadmap in a particular set
of colors. Your roadmap items are plotted beneath the goals on a quarterly
or annual timeline depending on the timeframes used in your company for
OKRs / goal setting.

A marker is highlighted on the timeline which highlights the end of the

goal / OKR period. This acts as a marker to visualise your impending end of
a set time period.

The goal / OKR based roadmap allows you, your team and your stakehold-
ers to quickly and easily assess how much of your work is actually linked to
your overall product or business goals since your product items are explicit-
ly linked back to your goals on the roadmap.
Dashboard roadmap

Your engineering team will no doubt have a set of their own dashboards
which they will use to monitor the build, highlight any bugs and track key
metrics. You also may have a set of product metric dashboards that you use
to track your metrics.

The dashboard roadmap borrows from this concept and encourages you
to build a dashboard style roadmap which can effectively communicate not
only the items that you have upcoming, in progress and recently delivered
in your roadmap, but also your overall key product metrics and quarterly
goals.

Being able to quickly see all this information in 1 glance means you can
have sharper, more concise product updates with the rest of the business.
Discovery & delivery roadmap

This roadmap is split into 2 clear tracks: discovery and delivery.

The discovery track is used to communicate which items in your roadmap

are still in the discovery phase. What’s the discovery phase? This is used to
describe items that are not yet ready to be worked on and are currently be-
ing analysed / assessed before being formally started. Once you have all the
requirements, they will pass into the delivery track.

The delivery track is used to communicate items which have been clearly
scoped out and are ready to be worked on and ‘delivered’. This will include
both items that have been scoped out but not yet started and items which
are in progress.

The discovery and delivery roadmap is useful to demonstrate to stakehold-

ers that whilst the team may not be actively building a particular feature or
working on the development of a project that doesn’t mean you’ve forgot-
ten about it; it’s in the discovery phase and will pass through to the delivery
phase once discovery is complete and that you’re satisfied that you have the
requirements you need.
Size scaled roadmap

When stakeholders are presented with a list of items it’s often difficult to
understand the amount of effort involved in 1 item relative to another. 1
line item on a roadmap looks visually identical to another, albeit with some
color changes and a different timeframe, but they are often the same size
and look visually similar.

This roadmap is designed to help you articulate how much effort is in-
volved in delivering a particular project / item by using visuals so that the
business understands that whilst 1 item may not seem like a huge amount of
work on first glance, relative to other projects, it is.

In a size scaled roadmap, make the larger items in your roadmap visually
larger and the smaller items smaller so that you can clearly see the relative
complexity / work involved in 1 project vs. another. Exaggerate the size
differences so that it’s easy to see the relative amount of effort involved
for each item. Don’t worry about this coming across as juvenile; the goal is
simply to make it clear that different pieces of work have different levels of
complexity – all relative to each other.
Transparency roadmap

One piece of the communication pie that’s often missing is communicating

with your customers. All too often we’re obsessed with making sure our
stakeholders know what’s coming up next that we sometimes forget to let
our customers know too.

It’s becoming increasingly popular for companies to publish transparent

roadmaps and this might be something you’d like to consider for your prod-
uct, too. A transparent roadmap is high level roadmap which tells your
customers what’s coming up next for your product and why.

Here’s some examples of transparent roadmaps:

• Slack – the office chat / communication tool

• Monzo – a fintech banking startup
• LinkedIn – the professional social network
• Buffer – the social media tool for automating your content

Try creating a version of your roadmap which you can easily share with
your customers. It’s a good idea to run this past your exec team to ensure
no sensitive data is leaked but transparent roadmapping can be an excellent
addition to your roadmap toolkit.
About us
The Department of Product is a global educational institution dedicated to helping product
managers and other technology professionals progress in their careers through acquiring
new skills.

Building digital products involves a unique blend of business, technology and user experi-
ence and we know that excelling in all 3 of the areas can be a difficult aspiration for most
people. Our educational programs are designed to help product managers and technology
professionals improve in areas they may be lacking and to enhance areas of excellence. Our
programs include:

• Product Mastery - designed for those looking to master essential product devel-
opment skills with an emphasis on developing product strategy, roadmaps and busi-
ness skills. You’ll learn both how to create a strong, differentiated strategy and how to
execute your strategy, using leading product companies as case studies.
• Web Technologies - designed specifically to help you get to grips with the techni-
cal aspects of product development and working with engineering teams. You’ll learn
about front end development technologies, programming languages, APIs, databases
and github - all from a management perspective.

To be a product person means to never stop learning.

DEPARTMENTOFPRODUCT.COM