Many organizations struggle with roadmaps, finding them difficult to maintain and hardly ever coming true. They say, a roadmap in its first edition barely resembles what they get in the end.

It all misleads into believing that the product roadmap is just some mumbo jumbo that has little in common with real business problems.
Those not given up the fight, experiment with crossbreeds of the roadmap and the release plan. Eventually, they create Frankenstein that is then preferred to be kept out of everyone’s sight, as the only thought of updating it gives a heart attack.

Whether you have already tried the above scenario or you are just about to create your very first roadmap, this article should give you some good food for thought.

Product roadmap is…

Product roadmap conveys the product development strategy you intend to employ to meet the business objectives.

• Aims to create transparency, internally and externally
• Builds the shared understanding between the stakeholders
• Links strategy to tactics
• Focuses on the outcomes
• Is agnostic about solutions
• Is a statement of intent, not commitment

Feature-based vs outcome-driven roadmap

The feature-based roadmap usually contains a number of features or feature blocks organized by some time spans (e.g. weeks, months, quarters).

Here are a few examples:

They are well structured, nice looking, and provide a comforting feeling of everything being under control.
Yet there is something very wrong about them…

1. User needs
The continual business success is grounded in the satisfaction and loyalty of the target audience, which depends on how well you cope with user needs and pains.

Your job is to incorporate the fulfillment of those needs in the product development strategy in a way that helps you achieve the business objectives.
User needs are opportunities for the business to succeed in reaching the objectives. And by addressing them in the product development strategy, you secure the course towards the win-win result — the point of mutual success for the business and the clients.

Now, looking at the roadmap samples above, can you tell what outcomes the users will get upon the feature delivery? Which features are most important and how do they align with the business objectives?

That’s it. You can’t.
Unless you are the creator of such a roadmap, all you can do is assume and theorize.

This is where the outcome-driven roadmaps shine and the feature-based ones fail.

2. Priorities
Another significant drawback of the feature-based roadmap is the difficulties in prioritization.

How do you know what to deliver first?
Prioritizing from assumptions would lead you nowhere: most likely, you will end up shipping features that nobody is going to use. Usually, it happens because those features do not deliver the desired outcomes to/do not solve the real problems of the end users and therefore fail at gaining the adoption.

Prioritizing without knowing the context of the problem and the desired outcome is like shooting in the dark. No matter how hard you try, you have virtually no chance to hit the target.

On the other hand, prioritization becomes a piece of cake when you understand the severity of the problem and the outcome to pursue. This leaves any debates around the priorities out, making them clear and easy to communicate to anyone.

3. Focus

Being focused means see the goal and progress towards it without straying in pursuit of the unimportant.

Focus helps you save time and money by nullifying the extra work and narrowing down the feature scope.

Unless the roadmap allows to easily trace every feature up to a specific outcome, you risk shipping a whole lot of wasteful material, sacrificing or at least delaying the needful.

The anatomy of the outcome-driven roadmap

The outcome-driven roadmap establishes a connection between the product vision and the problems to be solved to fulfill it. It links the outcomes desired by your target audience to the intended impact for the business.

For internal stakeholders, the roadmap allows tracing the strategic initiatives down to tactics and vice versa, which easily answers why they are doing what they are doing.
For external stakeholders, it is your way to say “We know what troubles you, and we will help you out”.

I recommend dividing the roadmap into three levels:

Top level — Themes — Global outcomes to be achieved, also traceable to the strategic business objectives.
Themes may span over several months and take more than a year to complete.

Mid level — Initiatives — The directions of the work that guide the tactics. You can think of them as categories for the tactic-level items — epics.

Bottom level — Epics — The collections of related stories.

Here is a fragment of the real product roadmap:

I use indexes to associate themes with their pertaining initiatives. For instance, on the above figure, A. EASY ONBOARDING is a theme, A1. Effortless setup, A2. Low migration effort, and A3. Guidance are the related initiatives.

Each initiative is a collection of epics those names are links to the respective tickets in the issue & project tracking tool.

Status helps your roadmap communicate the progress towards the objectives:
New — fresh epic with some basic information gathered
Planned — scheduled for design and implementation in the near term
In Progress — work in progress
DONE — delivered
(Feel free to use whatever statuses fit your needs best.)

To emphasize it that the roadmap is neither a commitment nor a release plan, and to save room for the shifts in delivery, leave out the dates and indicate the time horizons instead. Use broad timeframes such as quarters or half-years.

Provide priorities to set the sequence of execution.

You may also want to use confidence to indicate certainty in completing the items as intended. The lower it is, the higher are the chances of a delay.
Use scale (high, medium, low) or the percentage.

However, such representation of the roadmap may be a bit too complex for the quick alignment of stakeholders. So I suggest you create a birds-eye-view of it with an indication of priorities and sequence:

All three categories contain epics prioritized top-down and supplied with the index of the initiative (for traceability purposes).
Hot right NOW lists the epics which are work in progress.
NEXT big thing is for the ‘next-in-line’ epics.
For the FUTURE lists the epics of least importance, which will be taken in some time later.

Such simple categorization allows for fast re-prioritization. All you need is to find the right category based on the importance of the item and contrast compare that item inside the category to put it on the appropriate position in the list.

By the way, both of the above samples are fragments of the Google Sheets document. This is not advertising. It is to show that you do not need sophisticated tools to make roadmaps work in your organization.
Google Sheets suits me well because of the freedom in experimenting with layout, the ease of updating, and the seamless sharing.

Whatever format and tool you choose for your product roadmap, remember that it is not to demonstrate how busy you are going to be doing all those features, but to spotlight the bonds between the business objectives and the outcomes for your target audience. Concentrate on value and results.