How To Create a Simple Roadmap

Roadmaps don’t need to be complex, nor should you need a PhD to create one. Here’s a simple version to win over your team and stakeholders.

David Webb
Product Coalition

--

Long road with rolling hills, surrounded by big bushy trees
Photo by Matt Duncan on Unsplash

Ahh the dreaded word roadmap…

The mere mention of a roadmap can divide the room, and send Product Managers into a world of panic. Let’s face it, roadmaps have a bad reputation. They can do more harm than good, and are often neglected or blamed when things don’t go to plan.

This article won’t go into history, debate why roadmaps are worthwhile, or describe their place in your product toolkit. If you’re creating a roadmap or refreshing an existing one, here’s a simple solution you can try today.

Introducing the simple roadmap

Like many product people I’ve experimented with lots of different roadmap formats over the years. Ranging from purpose built roadmap products like Roadmunk, Aha and Productboard, through to quick and dirty versions in Microsoft Word, PowerPoint or Confluence. Whilst there is no single right solution or product for this, I’ve found myself coming back to this simple format time and time again.

Four elements of the simple roadmap

The simple roadmap has four key elements;

  1. 3 x time horizons
  2. Themes
  3. Customer outcomes
  4. Business outcomes

The simple roadmap must fit on one page with a reasonable size font. Each time horizon should have one theme with ~3 customer outcomes and ~3 business outcomes, represented as a short sentence each. Any more than this and it’s no longer a simple roadmap.

the simple roadmap shows the intent for a product over time. It has 3 columns, one for each time horizon. Each column is labelled with a theme, and lists the customer and business outcomes to be delivered over time.
the simple roadmap by David Webb

1. Time horizons

Time horizons are represented by three columns. Common spans include:

  • Next 3 months, 3–6 months, 6+ months
  • Quarters
  • Financial year halves
  • Now, next, later

The first column should be fixed and not change much given it’s what your team should be focused on right now. The far right column is subject to change as it’s further away and reflects that customer and business needs are likely to evolve between now and then.

2. Themes

Themes come from your product strategy and are described as a heading in one or two words above each time horizon. This sets your team’s focus for a period of time. Start with the most immediate priority (theme 1), and work through to the longer-term priority (theme 3). It’s good to describe themes with a verb like improve, increase, integrate, migrate, personalise, reduce, retire or upgrade.

3. Customer outcomes

The single biggest problem with most roadmaps is that they are solution focused, and contain too many things. Historically I’ve attempted problem based roadmaps whereby we list the problems to solve over time. Whilst this may sound appealing I’ve found it difficult to obtain stakeholder buy-in with this model.

But, who can say no to a good customer outcome? If you use the sub-heading “customers can: ”, I’ve found a few things happen quickly:

  1. You and your team will articulate the desired customer outcomes. How will you improve your customers lives, and what experiences do you want to deliver?
  2. It promotes the prioritisation of outcomes rather than features, and if stakeholders don’t agree with the proposed outcomes they’ll tell you.
  3. If your roadmap was too internal or solution focused, it will challenge you to think about and communicate what’s in it for customers.

4. Business outcomes

Business outcomes communicate the progress we’ll make toward achieving the theme, which in turn is a larger step towards making our vision a reality. In the simple roadmap this is represented as “<your business name> will: ”. At the bottom of this page you’ll find an example with “Food Corp will: ”.

Note: I don’t recommend adding metrics at the roadmap level. I suggest you capture this in the next level below, for example as OKRs. That’s not to say you can’t, but it may get a little messy. My advice is to start with outcomes, then determine what your goals are and how you’ll quantify them.

Benefits of the simple roadmap

If you’re not already sold, here are five reasons to try the simple roadmap:

  1. It’s quick and easy and you don’t need a fancy roadmap tool.
  2. You won’t need to reformat it should you wish to print, share or add it to a presentation.
  3. You can serve all audiences with a single artefact. You shouldn’t need multiple roadmap versions e.g. detailed vs. high-level, or team vs. stakeholder. You’ll have a single source of truth!
  4. It gives teams the flexibility to work out how best to deliver the outcome. It doesn’t matter whether the team employ solution 1, 2, 3 or 4, as long as the agreed outcomes are delivered.
  5. It can be a great instrument for building empowered product teams, and prioritising and negotiating target outcomes with stakeholders.

Common pitfalls the simple roadmap avoids

The format of the simple roadmap is restricted on purpose, to avoid it becoming complex. It deliberately does not look like a gantt chart and therefore avoids common roadmap problems:

  • There are no fixed start and end dates for individual items, just time horizons. Thus avoiding time wasted trying to perfect specific dates.
  • It is not about features, solutions or activities. The focus is outcomes.
  • It encourages teams to think through both customer and business needs, which helps prevent the roadmap from tipping too heavily in one direction. Thus solving for customers and the business, per Gibson Biddle’s DHM model:

“Delight customers, in hard to copy, margin enhancing ways.”

Note: if you find yourself creating a gantt chart that lists features over time, you’ve probably built a project plan or release plan rather than a roadmap.

Important reminder

Roadmaps should not be static! To be effective and meaningful they must be frequently viewed and updated. When publishing a roadmap it’s good practice to add a disclaimer at the top of the page that reinforces this. For example:

  • this roadmap outlines the intended direction forward for <product>
  • like any good roadmap, it will change and evolve over time as customer and business needs change
  • as at <date> it is <status> (draft, approved etc.)
  • any other assumptions, constraints or key callouts about what it does and doesn’t include. Add links to your strategy, vision or other related artefacts.

Don’t delay, try the simple roadmap today!

If you’ve been looking for a better way to build a roadmap that unifies teams and stakeholders, and drives real customer and business value, try the simple roadmap.

As a bonus for making it to the end, here’s an example of a fictitious online food business ‘Food Corp’ using the simple roadmap.

An example of the simple roadmap for ‘Food Corp’ a made up online food business who wants to improve their menu, deliveries and increase customers over time.
the simple roadmap example by David Webb

Pro tip: take the simple roadmap to the next level by adding your vision as a single sentence heading to the top of your roadmap.

Over to you

If you found this article useful please take a moment to clap, share or comment.

I’d love to hear from anyone that tries the simple roadmap. What did you like about it? How could it be improved? Alternatively, if you have a better, simpler roadmap template please get in touch.

--

--