Sometimes we don’t get to start in the right place. We don’t have the right budget, or the right knowledge, or the right resources, and we can’t always be sure about the destination.

‍

Somehow, we are supposed to come up with a plan that takes the product from the starting line to a place completely different than where we started.

‍

That map is the product roadmap.

‍

How to recognise what features should be road mapped and what should be implemented

It can be tempting to continue adding features on to your product until it resembles more of a swiss army knife than a hunting knife.

From a user perspective the product feels overwhelming, from a product management point of view, the app quickly becomes unmanageable.

‍

So in order to continuously deliver stronger versions of the product, a product road map is necessary to cut the noise. First, focus on the core features of the product. Second, roadmap the features that complement the core product.

How to build a product roadmap

When building a product roadmap, it will always come down to two factors, value and cost.

‍

The value to users should be apparent from user experience and research. Identifying valuable features for users is what we will look to answer throughout this article.

‍

Then there is business value. A feature in the product roadmap might make money, or differentiate the product, or even save money. But implementing features requires resources such as additional budget and time.

‍

In this article, we look at the challenges of building a successful product roadmap and the steps in order to take the next step.

‍

For further reading, you can read Toptal's article on Strategic and Tactical Routes to Development.

‍

What is the product vision?

It can be challenging to roadmap features as they can quickly become subjective, and this is worrying from a product management perspective.

‍

A product roadmap needs to be more than a backlog of features to implement. There needs to be a compelling statement made to the user when updating software.

‍

Implementing features is never linear. Some new features which are supportive of the core product could take months to develop, while some features that are nice to have but not necessary could be up and running within a few days.

‍

In my experience without a product vision, this can become an unfortunate norm: Impactless features implemented in slow succession.

‍

Just like ‘X’ marks the spot, every map needs a destination. That destination is the compelling statement that you tell your users about why this product or service is useful to them.

‍

Most product roadmaps aren’t the result of a clear destination. They are the result of someone sorting a backlog of opportunities by the ease of implementation. The low hanging fruit will get prioritised and complex ideas that are impactful are put off indefinitely.

‍

How to build a narrative around app releases

A good way to build a product roadmap is to create a narrative around any future releases. This narrative will start to tell the story of your product and how it will evolve with time.

‍

To do this, you need to look through your backlog of features through a different lense. The best way to do this is to create chapters or themes.

‍

‍

When it comes to this point, I like to think of a classic childhood show, Dora the Explorer. She has her backpack, her map, some challenges that she needs to overcome, and an endpoint.

‍

When goes to the spooky forrest, she sees bats, overgrown trees and its dark. This is a theme that plays in to the narrative. You would not expect to see a mermaid in the spooky forrest, that just would not make sense.

‍

This is the same for when you are creating chapters around releases. Focus on releasing and implementing features that complement each other as one. This means you can prioritise your backlog based on which chapters appeals to your narrative.

‍

‍

Do JUST enough planning

So what is the problem with product roadmaps?

‍

One of my favourite quotes from Mike Tyson really sums this up, “Everyone has a plan until they get punched in the face.”

‍

From experience, a lot of the planning can go to waste. This is the nature of developing a software product. Things change, features become less important when real users are on the app, and other more important features become clear.

‍

By demanding that a certain feature gets launched in Version 3 and this feature gets launched in Version 4, we create plans that are a fantasy.

‍

In moments like this, it is important to realise that you can’t plan EVERY detail. Instead take note of the feature when it crops up in a running document.

‍

Work towards opportunities, not features

When discussing opportunities over features, we are talking about capitilising on something that you really need to give your product the app and deliver the narrative.

‍

I was once given an app that subscribed its users to pre written meal plans based on their goals. In the beginning it was a distillation of the features that were present on competitors apps - and there were a lot of features.

‍

Fortunately, we had already done alot of user research in the area as we had developed previous apps in this space before. Many of these features (shopping lists, favourites lists, forums, blogs, weight tracking, exercise tracking) were attempts to answer the problem: how do we help users follow their meal plan. And unfortunately, none of these features were an effective solution. In fact, they cluttered the app.

‍

The app was FEATURE heavy. And it felt clunky.

‍

So we decided to strip the product back down to it’s bones and focus on the core functionality. From there we were able to implement opportunity driven development and the product took a different turn for the better from what the stakeholders initially felt was the real value in the app.

‍

Feeling certainty in uncertainty

I know that you may finish reading this article only to feel more lost than when you started.

‍

But remember, the goal is to get to your destination.

‍

From your starting point, you can only judge what the eye can see. It’s only as you continue on your journey that more becomes clear.

‍

A product roadmap should only tell you three things:

- The end destination
- The most likely route (the map)
- The next step

The most critical thing is detailed planning does not belong on your roadmap. When a feature is ready to be implemented and committed to, it will be pulled into the product backlog and mapped out in sprints.

‍

The combination of a clear destination and a simple, but adaptable plan is the essence of a good product roadmap.

‍

‍