Today you are going to learn why and how to create product roadmaps.

The main ideas are taken from the excellent book “Product Roadmaps Relaunched“.

Let’s dive right in.

What is the purpose of a roadmap?

Before you start working with a roadmap you should consider the purpose of the roadmap. Traditionally a roadmap has been a list of bigger features plotted out in a timeline. A lot of the time the purpose of such an approach to roadmaps is to create a false sense of security.

What do I mean by that?

Well, no one can predict what is going to happen in the future. Even though you did your research, estimated and got a commitment from your engineers on a future feature, it most certainly won’t be completed at the predicted date.

There is also another problem with roadmaps that focuses on features. A feature does not guarantee the desired outcome. If we seek a certain outcome, only after the feature that is thought to deliver the specific outcome is released and used by actual users, we can confirm whether it did or did not deliver the outcome.

Thus, a roadmap that focuses on features and dates are doomed to fail.

Rather, the purpose of a roadmap is to:

  1. Focus on the future desired outcomes
  2. Promote your product with stakeholders

First, let’s talk about outcomes. Outcomes are in my opinion the only real indicator of progress. If we, for example, want to increase the time spent using a product, the desired outcome can be “Increase time spent using a product with 10% in each session”. Only an increase in that metric will fulfill the outcome.

How we reach this outcome is uncertain until we actually reach it. It could be anything from small tweaks in the design, a completely new interface or new features in the product.

The second purpose is to bring all stakeholders together and create a shared understanding of where we are going and why. A good roadmap will bring excitement about the product’s future potential.

So, in summary, a roadmap should not:

  1. Focus on features
  2. Promise dates

Rather, a roadmap should:

  1. Focus on outcomes
  2. Get stakeholders excited about the product’s future

What should a product roadmap contain?

Now that we have established the purpose of a roadmap we need to consider what components it should include.

The primary components of a good roadmap that rally your troops and sees nothing else than outcomes are:

  • Product vision
  • Business objectives
  • Outcomes
  • Status
  • Disclaimer

Product vision

A product manager is sometimes referred to as the CEO of a product. And as all good CEOs know, you need to establish a vision. This is just as true for products as for companies.

A product vision should ideally be aligned with your company’s vision and answer the following questions:

  • Who are the target customers?
  • What are their needs?
  • What is the product name and what is it?
  • What are the product benefits?
  • What differentiates it from competitors?

With a product vision established, you know have an excellent answer to why your product exists in the first place. The vision will also act as a guiding star for your roadmap.

Business objectives

The next component to include in your product roadmap are the business objectives. These should be closely tied to your vision and identify what needs to be accomplished in order to fulfill the vision.

Here are three tips regarding business objectives:

  1. Everything on your roadmap should be connected to one or more objectives
  2. Keep the number of objectives for your product below five
  3. Focus your objectives on outcomes


The main components of your roadmap should be the outcomes. You can think of these outcomes as “sub-outcomes” to your objectives.

An outcome is something that brings value to either your customers or stakeholders. Desired outcomes are much more stable than features and will by default change a lot less. This will let you spend more time delivering value rather than constantly update your roadmap.


I am a strong believer in date free roadmaps. Doing new development in an agile fashion will leave no room for estimating and promises on delivery dates. Therefore, it is much better to leave out dates completely.

Rather you can indicate which outcomes that your team currently are working on to realize and what we think should be the next outcome when we are finished with the current one.

In order for this to work properly, you also need a good way to prioritize between outcomes. We will address techniques for that later in the article.


Not everyone who reads your roadmap will have the knowledge and insights that you have. Therefore, it is important that you include a disclaimer which clearly indicates the purpose of the roadmap. Otherwise, some might consider your roadmap as a project plan, which it clearly is not.

How do you gather inputs to your roadmap?

We have now established that a roadmap should be based on outcomes that bring value to your customers or stakeholders. But, how do we find out what that is?

Here is a list of important questions you should be asking yourself and find answers to:

  • What do people need?
  • Who are the users?
  • How do people currently solve a problem?
  • What is the users’ workflow?
  • Do people want the product?
  • Can people use the product?
  • Which design generates better results?
  • How do people find stuff?
  • How to find participants?

There are all great questions. You can answer many of them by simply observing customers using your product or other ways they are trying to solve their problem.

When you observe them you should take note and map their customer journey. By doing so with a few typical customers you will most likely have gained a good amount of customer insight. Whenever you see that they struggle you have a golden opportunity for an improvement that could yield your product a competitive advantage and create a better outcome.

The end results from this exercise should be a set of personas and their respective customer journey trying to solve a problem.

How do you achieve alignment from stakeholders?

Let’s say you have finished your roadmap and that you did most of the work alone. You feel proud and want to present it to your stakeholders as soon as possible.

Don’t do it!

If you do it like that you won’t find alignment to your roadmap items. You might reach consensus or collaboration, but never alignment.

In order to reach alignment, you need to involve all your stakeholders early in the process. You need to talk to them and listen to their concerns and objectives with the product. I find that the best way to do this is to sit down with one at a time for 30-60 minutes. You should mostly be focusing on asking questions and listening.

After you have done so with all your stakeholders you should have gained a lot of feedback regarding their needs and fears. Use this input and add it to your roadmap.

The reality is that many of their needs won’t find their way to the roadmap, even less likely to the product. You should not over-promise during these meetings, rather set their expectations low. A big part of the job as a product manager is to say no to feature requests. Since we now have established that we firstly focus on outcomes and values. And a specific feature request from one stakeholder might not be in line with our desired outcomes.

How do you prioritize your roadmap?

When you have identified your customers and stakeholders’ needs you are left with the not-so-easy task of prioritizing between them.

But, fear not, there are a number of techniques you can use to do so.

Critical Path

A critical path is an absolute minimum that a product should be able to do so a customer can solve their problem and get the desired outcome. This method will ignore everything that isn’t necessary to reach the end goal. The customer will go through a critical path, things that must be there to do the main thing of the product.

This method is especially useful when launching a new product and can also be considered the MVP (Minimum Valuable Product).

Kano Model

The kano model an interesting way of prioritizing by classifying customer expectations in three levels:

  • Expected needs
  • Normal needs
  • Exciting needs

You can do this by sending a survey to potential/existing customers letting them grade the perceived value of your potential features into one of the three levels. Features that land in the expected needs category could be considered a part of the critical path. When your product has passed beyond the MVP state, the Kano model will help you to prioritize between them as well.

One thing worth noting is the time factor. Features that once were exciting will eventually move down to normal and up as an expected need. Thus, it is obviously important to update your Kano model semi-regularly.

Desirability, Feasibility, Viability

The two above mentioned methods have a common flaw, they don’t consider other factors other than customer value. And I doubt that you are in a situation where money and time isn’t a factor. Thus, we should include a few other factors in our prioritization models to make them more realistic.

The desirability, feasibility and viability model is quite useful. As the name suggests it factors in customers’ expected value (desirability), the effort and difficulty to build it (feasibility) and the business side, can we make money from it (viability)?

By scoring each of the three criteria you will get a total score that can help in prioritizing your features.

ROI Scorecard

If you thought the Desirability, Feasibility, Viability model was good enough, you thought wrong!

In order to prioritize scientifically, we must include even more criteria and do some calculations. The basic idea is value/effort = priority. Value is here defined as customer value + organization goals. Thus, we add up two important stakeholders’ perceived value of an item in the roadmap. The effort is the complexity and time it will take to implement whatever solution you find to meet your customers’ needs. The last factor we need to consider is a grade of confidence in your value and effort estimates. Customer needs that are well understood and solutions that are well defined will have a high confidence factor while the opposite is true for needs that are wage and thas has unknown solutions.

The full formula will then look something like this

(VALUE (Customer Need + Business Objectives) / EFFORT) * CONFIDENCE = PRIORITY


While not really a prioritization method, MoSCoW can be used to communicate the results of other prioritization models.

You place each item in the backlog in one of four categories:

  • Must have
  • Should have
  • Could have
  • Won’t have

This way of communicating is better than saying that item X has a score of 75 based on our ROI calculations. Instead, you can then say this item X has been classified as a should have.

To who and why should you show your roadmap?

Sharing and presenting your roadmap should, if you have done your job right, feel like an exciting activity.

Remember, that one of the main purposed of a roadmap is to bring excitement for the future of your product.

Here is a quick checklist for what you should consider when making and presenting your roadmap:

  • Think about who your audience is. Different audiences require and want different levels of information.
  • When you have identified your audience, start you presentation with why your product exists. When everyone is on board with your why you have set the scene right for presenting your roadmap.
  • Prepare your roadmap accordingly to your audience and why. If it is for your team, more details are necessary. If it is for the board, business value are the top priority.
  • Presenting your roadmap should only be done after careful alignment work has been done. Ideally, most of your audience has had the chance to give their input already.

What tools can you use?

Now that you have learned how to do product roadmaps the right way, where should you make them?

There are a few good options.

I will just leave you with the links for now. Might do reviews and comparison in the future, it’s on my content roadmap!

Final thoughts

To focus more on outcomes than on features is perfect for a roadmap. Features are of course extremely important but are up for change more often that outcomes. Features have their own place, but then in a format more like a release plan.

I also believe roadmaps should be more tuned into the OKRs concept with a few objectives and clear measurable key results.