How do I make my product roadmap a better communication tool?

Hi Jock,

My product roadmap is not getting the right information across to other people in my company. In particular, my customer success and marketing teams are struggling to plan their work for upcoming product releases. I’m also not sure how I can show my roadmap’s relationship to the half-yearly OKRs we set. How can I improve it?

Thanks,

J

Hi J,

First and foremost, your product roadmap is a communication tool, so if people are taking away the wrong message or not getting the information they need from it, then it may be worth rethinking how you present the information.

Extract a release plan #

It sounds like your customer success and marketing teams need advance warning about certain releases needed by key customers, or releases worth highlighting to the market more generally. You may wish to pull out a subset of the roadmap as a release plan specifically for these audience. It would be characterised as the most certain bits of delivery, filtered by relevance to external audiences, expected to drop in a relatively short timeframe (maybe 1-2 months at most).

Use OKRs as roadmap themes #

We also talked about how your 6-monthly OKRs (objectives and key results) effectively set the two main focuses (or themes) for the next 6 months of your roadmap. I’ve seen teams colour-code their roadmap items to correspond to the current themes. That way, they can glance at the roadmap and see that they’re working mainly on the blue theme (OKR 1) right now, and a little bit of the red theme (OKR 2), then later on the balance shifts the other way. You can also add housekeeping stuff like bugfixing or refactoring into the roadmap as a separate, more long-lived theme.

Show everything your team is working on, and why #

With that in mind, it’s reasonable for a roadmap to include whatever the team is actually working on, whether it’s a timeboxed discovery or experiment to learn or test something out, or delivery of ‘shippable’ product. What matters is that there’s a clear ‘why’ for each item on the roadmap. You should be able to point to any roadmap item and describe how it answers a question or delivers something that in turn helps the team move closer to their OKRs, which in turn (hopefully) aligns with what the company is trying to achieve in the next 6-12 months.

Think in outcomes and bets #

Another way of thinking about roadmap items is that they are all outcome-based, meaning we’re expecting something to change for a particular group of people as a result of completing that roadmap item (again whether those people are a segment of users or the team itself increasing its knowledge).

But the roadmap items are also bets on the future – we’re effectively saying that we’re doing the item because we reckon/bet that it will cause a particular outcome. Some of those bets are on what we think we know (hence discovery and experiments), others are bets on how we can help our users to do something more effectively, or at all.

Our confidence (likelihood of success) will differ for each roadmap item. Usually we want a balanced portfolio of bets – some low risk/low return, some high risk/high return, some in the middle.

Final thoughts #

In summary, the roadmap should a way of abstracting the detailed work of the team so we can more easily tell the story of our team’s current and planned future focus (themes), progress to-date, confidence (risk) & learning, and alignment of learning and delivery with higher level goals and strategy.

Cheers,

Jock

Further reading #

Tom’s Roadmap Heuristics – a work in progress – Tom Dolan

Make the most of your roadmap – Scott Colfer

How we made the GOV.UK roadmap – Jen Allum

PRODUCTHEAD: Outcome-driven product roadmaps – I Manage Products

PRODUCTHEAD: Place your bets, please – I Manage Products

The secret behind meaningful product roadmaps – I Manage Products

The secrets of meaningful product roadmaps (redux) – I Manage Products

Can I pick your brain about product roadmaps? – I Manage Products