If you are new to Product Management, one thing you're bound to hear when you research the industry and how to become a Product Manager is that Product Managers are responsible for a 'product roadmap'. It is one of the most important artefacts you'll work on, so if you're interested in how to build it, read on...

What is a 'product roadmap'?

For anyone new to Product Management the product roadmap might be something you've never come across before. So before we get into how to build one, it's worth covering what a product roadmap is.

In many ways it's similar to a traditional 'roadmap' - it's a route planner of how you get from point A to point B. Point A is where your product is today (it may not exist as more than an idea at this point, or it could already be in the market. Point B is where you want your product to be - this is essentially your 'product vision'; the features you want your product to have and its worth in the market.

The roadmap is how you see your product evolving (iterating) over time to achieve that vision. Instead of a traditional roadmap where you might say "at this point we turn left" you'll say "at this point we want to deliver this feature". Your roadmap is, at its simplest, a list of features/functionality that you plan to build to achieve your product vision.

What a product roadmap is not

This topic is one I'm really passionate about, and it comes from a lot of (bad) experience! A product roadmap is not the same thing as a Gantt chart, and it's not a project management tool. The problem is that a roadmap and Gantt chart can look very similar, and to people who haven't been involved in Product Management or come from working in project-led organisations, they seem like the same thing.

But a Gantt chart's key focus is delivery scheduling - the features or functions listed are only of importance based on how long they'll take to deliver, and when they'll be delivered. A product roadmap, however, focuses on the order of delivery. This can be supplemented with delivery schedules, but that should be the job of a Project Manager and it absolutely has to be based on the estimates of those involved in delivering the product/features and not on fixed dates decided outside of that team. I've written about how date setting can work only on that basis.

How to build a great product roadmap

So having said that a product roadmap is effectively a list of features in order of delivery, let's look in more detail at how we arrive at that order. There are two main things to consider before you can build your roadmap:

  1. Value - what measurement(s) you use to define the value of a feature/function of your product
  2. Method of prioritising - how you turn those measurements of value into priorities

Defining the value of product features

We teach a lot about value on our online Product Management Course for the simple reason that understanding it and getting it right is absolutely critical to being a successful Product Manager. But how should you define 'value'?

There is no ultimate consensus on a final or ultimate definition of value in Product Management. There could be an argument that all measurements eventually boil down to profit, and some methods of prioritisation rely on value being defined purely in monetary terms. But measuring every feature or function in purely financial benefit to a business is complicated, sometimes extremely so to be close to impossible.

There are definitely three 'buckets' of value that we can identify:

  • Business value
  • Customer value
  • Technical value

For advocates of purely financial value-measurement, the argument is that customer value ultimately leads to financial value through happier and increased numbers of customers. But establishing that connection can be incredibly difficult and somewhat hypothetical. In the same way, they would argue that technical value ultimately leads to financial value through better performance, which attracts more customers and in turn more income.

Regardless of the definition of value we use, we should make sure it meets these conditions:

  1. It should be objective
  2. It should be measurable
  3. It should be agreed between stakeholders

Prioritising method and delivering value

Having established a measurement of value (or more than one) the next job is to use it to prioritise your product roadmap. This is the key to a good product roadmap - it should always be prioritised in relation to value. Going back to the analogy of a travel roadmap, where the purpose is to provide the quickest route to your destination, the product roadmap's purpose is to provide the most valuable route to your product vision.

This might seem simple at first - if 'feature X' will generate financial income of, for example, £100,000 per yer and 'feature Y' will generate £80,000 per year, then wouldn't the priority would be X followed by Y? But what if it takes the delivery team a year to deliver feature X but only a month to deliver feature Y? Suddenly it makes more sense to prioritise them in the opposite order, because over the one year and one month of development time, delivering X first would generate close to £0 income, but delivering Y first will deliver £80,000 (following the one month of development).

So while 'value' is the key, it has to be balanced in some way by time and effort. That is where a methodical approach to prioritising is important. And it also (in some cases at least) helps remove even more subjectivity. A few of the prioritisation methods you might use, which we go into in more depth with examples and instruction on our online Product Management Course, are:

  • MoSCoW (not my favourite)
  • Value/time matrix
  • Cost of delay
  • Weighted shortest job first

Once you pick a method - and in some cases you might use more than one method - you can start to create your roadmap.

Final considerations for your product roadmap

Before wrapping up, it's worth noting that in 'real-life' Product Management, there might be times when even the most value-driven, well-prioritised roadmap will be challenged by circumstances and people/politics. Unfortunately no Product Manager operates in an ideal world!

Roadmaps are also rarely linear - feature deliveries will overlap and be worked on simultaneously. You might also deliver features in increments, so the roadmap will reflect that.

And finally, very importantly, product roadmaps change! If you have a good feedback loop for your product, as well as data that you can monitor, you should be ready to re-prioritise based on new/improved learnings.

We offer a full Product Manager Education which covers all of the above in detail, with examples and explanations of how to build your product roadmap. And it covers everything else you need to get started in a career in Product Management.