What I have learned about roadmaps

In a previous company I had to do a lot of roadmapping, and now as an interim CTO to many clients I am helping them with their roadmaps.

Whilst I was learning what makes a robust roadmap I decided to get up to speed on what people seem to think makes for a good roadmap.

I wanted to share my thoughts.

What is a Roadmap

All sources seem to share the same opinions.

Roadmaps are:

• A communication document
• A guide to keep everyone in the loop
• A way to ensure new projects get judged equally
• A direction towards fulfilling product vision
• A way to unite developers around common goals
• A framework to allow people to lobby for moving projects up/down the list

What a Roadmap is not

Roadmaps are not:

• A strict project plan
• A commitment
• A place to store bugs / minor issues
• A release plan

The Roadmap can change

The roadmap can change for several reasons;

• Not all ideas work in practice, only once you start developing them out you realise this
• Priorities within the company change
• New opportunities present themselves
• Completing version one of a feature may spawn several other ideas and features

The size of your team / company matters

A small team working in a small company can get away without a roadmap, they have a stream of important tasks.

A large company can benefit from enterprise level process and will have dedicated people to carry it out.

The majority of companies fit somewhere between these two extremes, which means they would benefit from a roadmap but don’t have the people in place to go full-enterprise.

Dates are the devil

Everyone seems to agree that dates on roadmaps are a bad idea. They make people feel bad because they set unrealistic expectations.

You you can’t know the following;

• The size / skill set of your team in 12 months time
• What is going to take longer than expected
• What is going to come in in the mean time
• How priorities change over time

Some people think you should just have a list ordered by priority, others say to have loose groupings like Currently Working On, Up Soonish, and In the Future.

For what it is worth I like the idea of having it more as a running list.

When you are told a date

When someone tells you that you need to get something done by a particular date you need to explain that if that is the case then the scope of the project has to be flexible.

Add a new Project based on merit

I mentioned earlier that a roadmap is “a way to ensure new projects get judged equally”.

To know the merit of a particular project we need to know what is important to the business.

We should have 3-5 key metrics that are important to the business to judge each project by.

Examples of these key metrics could be;

• Revenue
• Staff Productivity
• Customer Insight

Some of these metrics will be more important than others, we reflect this in a scoring system.

Say that Staff Productivity is twice as important as everything else. For each project we score it against these metrics out of 5 then for Staff Productivity we can double it.

For example;

  Project: Improve Sales pages to address common questions

  Revenue: 4
  Staff Productivity: 4 (2 * 2)
  Customer Insight: 3

  Total: 11

If another project scores higher then this should be done first.

We can add extra items to this like an effort score, we will score it out of 5 and use it to divide against the total;

  Project: Improve Sales pages to address common questions

  Revenue: 4
  Staff Productivity: 4 (2 * 2)
  Customer Insight: 3

  Effort: 2

  Total: 5.5

This means that smaller features might come out on top once you weigh in effort.

Only consider products that fit the vision

Before we start judging the merits of a project we need to know that is fits the company or product vision. This should be a statement which reads something like;

Our product is the only __ that __ for __ in __ who __

This will guide our roadmap.

It is important to remember that a bunch of features does not make a product. A vision ensures that the features help move the product to where it needs to be.

The features of a project on a roadmap

Each project on a roadmap should have the following information stored about it;

• A scope – The detail of this scope changes depending on time out, I explain this more shortly
• A Strategic Rationale – Why are we doing this
• A time horizon – If it is happening immediately or at some point in the future
• The product(s) effected by the project
• The parts of the product(s) effected – This could be as simple as tags like Sign in, Sharing

Dividing Workloads

I said under what a roadmap is not “A place to store bugs / minor issues”. This means we have at least one other location to store these (we use Github Issues).

Everyone will have their own ways to delegate tasks, it seems sensible to spend some time working on smaller issues. You need something solid to build on.

Deciding on Scope

The closer something is to being ready to work on the more scoping it needs. We shouldn’t spend too long scoping projects that are several months out, that scope is likely to change.

Things that are being worked on in the current sprint should be tightly scoped. We should handle scope creep or change outside of the current sprint.

Sharing your roadmap

Everything I read seems to suggest sharing a roadmap is a good idea.

• It starts conversations with customers / stakeholders
• It gets people into long term thinking
• You can get early feedback on ideas you haven’t even scoped yet

The advice seems to be to not worry about your competitors seeing your roadmap, the version you will be sharing publicly will be so high level that it will be hard for them to glean real business insight from it.

What you share

The version of the roadmap you share with customers, CEOs, Sales + Marketing should be high level and not even begin to scope out the individual features. Keep the more detailed version for the people who need it, dev and ops.

When new projects come along

After planning, the next thing to happen is a project will come along that wasn’t included in the original roadmap!

Don’t slot it in before the first thing that feels less important. Revaluate the roadmap and see what other projects this new one might effect.

Perhaps this new one removes the need for an older project, or an upcoming project will supplant the need for this new one.

New projects should never be sent straight to the developers, it is a huge source of distraction and working on stuff that hasn’t been well planned can have disastrous effects.

Tooling

I haven’t tried the custom tools mentioned in anything I had read so I won’t write about them. The consensus is to focus on the content you are putting into the roadmap, not the tools.

For what it is worth I think we will be using a big white wall to keep our roadmap on and updating it as necessary.

Lots to learn

I hope you found this writeup useful, I still have a lot to learn and will add to this post over time.