Product Roadmaps – an Essential Guide
Let’s talk about product roadmaps
What is a product roadmap?
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 managers 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
Why roadmaps are critical
A world without roadmaps is like trying to live in a world without gravity.
Imagine Sandra Bullock attempting to navigate a 30 minute commute to work in that little jet pack from the movie Gravity. That’s you trying to achieve your product goals without a roadmap. You’re all over the place; reacting to whatever is immediately in front of you, avoiding near misses and being pulled in multiple different directions.
Your CEO wants something new so you drop everything and crack on with the new, allegedly game changing idea.
1 user says s/he wants a new feature so you decide to build it.
Nothing beyond the next week is planned and a good day at the office is a day where you haven’t been shouted at by your CTO for changing your mind about priorities for the engineering team every 3 days.
A solid product roadmap grounded in sound principles will help relieve this pain, reinstate the centre of gravity and pull you, your business and your team in your desired direction together.
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 roadmap 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.
Step 1 – collect your inputs
The first step to creating your roadmap is to collect your inputs. Inputs typically include feedback, insights, analysis and requests from the following sources:
- Stakeholders
- Team members
- Data points
- Customers
- 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 his team will be getting that automated messaging feature he’s 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 replaced 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 roadmap 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 belongs 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 relevant 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 departments 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 creative 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 management 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 surveys to build as clear a picture as possible of the human beings who are actually using your product and factor this into your roadmap creation process. You’ll often discover small nuggets of insights which would have been impossible to know inside your 4 walls.
But for the love of God 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 context 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.
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 include 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 always 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 expectations? 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 customer. These are things which are not absolutely necessary for your product 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 customer 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 communicate; 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 stakeholders. 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 roadmap, put it in a folder and forget all about it. Be disciplined and keep your roadmap updated and evolve it over time.
Roadmap 1 – Gantt Traffic Light
How it works
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 traffic 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.
Roadmap 2 – Theme Based
How it works
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 depending on factors outside of your control.
Roadmap 3 – Goals / OKRs
How it works
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 stakeholders 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 explicitly linked back to your goals on the roadmap.
Roadmap 4 – Dashboard
How it works
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.
Roadmap 5 – Discovery
How it works
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 being 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 stakeholders 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 forgotten 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.
Roadmap 6 – Size Scaled
How it works
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 involved 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.
Step 4 – Communicate your Roadmap
So you’ve decided which roadmap best suits your business / product and you’ve built your visual roadmap. Now what?
Unfortunately, whilst you might feel like sending the roadmap around in an email on a Friday night in the hope that none of your stakeholders will read it and you can just crack on with delivering the fun work, the truth is that you’re going to have to spend some time communicating the roadmap to your team and your business.
Preparing a documented version of your roadmap is only 1 part of the ‘roadmapping’ process.
Since the primary purpose of your roadmap is to communicate your product plans , the final step is to take the roadmap you’ve created and spend some time clearly articulating the roadmap to all relevant people in your business.
If you don’t communicate your roadmap, nasty things will happen. Your engineering team won’t know why they’re working on specific features, your stakeholders will think they’re getting all the items they’ve put in their magic wish list and your CEO thinks every single one of his new ideas is on its way to be delivered in record time.
The roadmap is as much about managing expectations as it is about managing your product.
Who should you communicate the roadmap to?
- Senior execs – if possible and depending on your position, get in front of the execs to make it explicitly clear what is on the roadmap for the upcoming quarter or year.
- Stakeholders – all your stakeholders who were involved in the input phase need to be updated and told what is coming up in the roadmap. You’ll no doubt have regular catch ups with some stakeholders who will know what’s likely to happen and what’s not so likely to happen so the roadmap shouldn’t necessarily be seen as a ‘grand unveiling’, but more of a confirmation of what was discussed during the input / curation sessions. If you have set of a product council, use this forum to discuss the roadmap.
- Engineers / product team – pencil in specific sessions with your team to discuss the roadmap in detail so that they understand what is coming up next and why. Communication with your engineering team is critical to your product’s success.
How to update the business regularly about your roadmap
These one off instances shouldn’t be one offs; you should be keeping the business and your team updated with the roadmap as regularly as possible.
Go back to the roadmap at the beginning of your planning sessions with your engineering team to remind the team of the broader picture and to clearly articulate why a specific feature / story is important in the context of the goals you’re trying to achieve.
Pencil in frequent slots in your company all hands to keep everyone up to date with how the roadmap is proceeding and demo releases with reference to the roadmap regularly.
Speak to your stakeholders on a one to one basis as regularly as makes sense for the projects you’re working on and ping around an email to let everyone know how the roadmap is being delivered.
Maintaining your Roadmap
Your roadmap should continue to develop and evolve over time. If you’ve set quarterly goals, your roadmap should be updated on a quarterly basis and re-assessed as often as feels natural to you and your team.
Sometimes you’ll need to reassess your roadmap more often than your previously defined window would suggest. For example, you may uncover hidden complexities in a particular project and as you progress, you may decide to re-evaluate the scope of the feature / project which results in more or less time and resource being dedicated than you originally anticipated.
How often should you update your roadmap?
The frequency with which you update your roadmap is ultimately linked to the stage of your business and the lifecycle of your product.
For early stage startups it might make sense to re-evaluate the ongoing items on the roadmap every 2 weeks or every month. For larger organisations with more a mature product, it may be suitable to update the roadmap quarterly or biannually depending on the culture of your company. Larger corporates can be slow to re-evaluate and shift in a different direction whereas startups can, by their nature, be far more nifty and agile in their product development approaches.
A word of caution though: try your best to avoid suffering from product attention deficit disorder. This is the equivalent of having 23 tabs open in your browser and flicking between them furiously.
It may be that you read about, discover or use another product which seems to contradict the decisions you’ve made and you want to change course.
It may be that you have an awesome idea in the shower and you’re sure it will be the next big hit and you want to prioritise it next week.
It may be that your CEO decides they want to build a new toy every 5 days.
As tempting as switching your attention to new things is, this impatience and frequent switching between priorities, projects, features and commitments can mean you never truly make any meaningful decisions or build anything of value.
A focused and clearly communicated product roadmap that is updated only when appropriate will make sure that you do.