The Roadmap

The Roadmap

The other day I was asked to develop a Roadmap template for our SME customers.

We have a lot of variety in this division: from the start-up company that is creating an exciting new product, to established enterprises that are building upon released products. From companies that have one person leading all the development, to companies that have a board of directors that wants to be aware of the direction the product is heading.

With that in mind, I wanted to go with something that would be simple enough to get people started quickly and still be flexible to accommodate growth, without compromising what a Roadmap is about.

Before getting into it, it is worth understanding what a Roadmap is, and why it’s a good idea to have one.

Companies have a Vision, and will define their Strategy to achieve their Vision. Simply put, the Roadmap describes these two artefacts – it provides direction and focus to the company as it lays out the road ahead.

Having said that, the Roadmap should not be a static piece of information – it should be adjusted to match the ever-changing environment that we all operate in. Whilst this might seem obvious when you read this post, it is very important to make everybody aware of the fact that things can change. It’s very easy for stakeholders to get hung up on features that were supposed to come the next quarter and didn’t materialise because priorities changed. It is imperative that the Roadmap is visible and well communicated to all interested parties.

No Roadmap no problem?

The interesting thing regarding our SME clients was that they all had slightly different ways of managing project direction. Some would use the Story Map, others would use the development backlog, some a combination of both and others would just store everything in their head. All these approaches can be valid and might get you by for a time

However it rapidly gets to a point where they are not optimal, because they don’t provide the focus that the Roadmap provides. The Roadmap provides information about what you are doing next, what are the goals you want to achieve, what is the functionality you want to incorporate alongside a time line giving some idea of what is coming and when. Having this information clearly stated enables dialogue with prospects as well a focused and motivated team.

The documents I mentioned before can also do this, but I find that they are meant to capture other type of information (i.e. the Story Map captures the user journey, the Backlog captures a lot of technical tasks and information). Therefore, they don’t provide the necessary focus and flexibility that the Roadmap brings.

Roadmap, Story Map, Development Backlog

So, what is the relationship between the Roadmap, the Story Map and the Backlog?

The Story Map and the Roadmap have a lot of the same information. The Story Map shows a holistic view of the system or application from the point of view of the user – in other words, the focus is on the user journey.

This information is invaluable and feeds directly to the Roadmap. In a way, the Story Map defines all the things that you want the product to do and even drills down into a certain level of detail. In the first instance the Roadmap takes those things and puts them in a timeline, enabling a release-focused view.

You don’t have to have a Story Map to be able to create the Roadmap. There are a lot of successful projects that start off with a backlog and eventually get a Roadmap, and never have a Story Map, however a Story Map is very helpful to understand the system’s bigger picture, and to understand the context in which individual features must operate.

The development backlog is basically generated from the Story Map, by taking the stories and refining them so that they are ready to be picked up by a development team. The Roadmap specifies the priority of the Backlog.


Now that we understand why we should have a Roadmap and how it relates to the Story Map and the Backlog, let’s have a look at a simple template that will get you off the ground.

In the image above you can see that releases are organised by quarters and that we are releasing each quarter (obviously adapt to your timeline). Each release contains the modules and functionality that is to be delivered. From Q2 onwards we have included “Support” as it is very common that once the product is out you will have to provide some sort of support that will use the team’s capacity. In Q4 there is still some free capacity and Q1 next year is completely empty.

In addition to releases, there is the “Parking lot” – this is an area where modules sit while they are being analysed and refined. Some will make their way into the Roadmap and some will eventually be taken out and not implemented.

Once you have laid out the Roadmap, you can start using it to communicate intentions to your stakeholders, and with time you can add a few more bits of information and end up with something which would include the following:


• Always communicate any changes to the Roadmap to all interested parties;
• Collaborate with people to obtain strong buy-in;
• Review at least every 3 months;
• Start simple and evolve;
• If possible keep it in one location.

Have your say, do you agree with these templates? Do you want to know more?

Join the conversation on Twitter @blackcatsolutns