Product Roadmaps part two: Living in the fourth dimension

Last time, we talked about product roadmaps, what they do and how they help you. We finished with an interesting analogy about apples. Back at our desk (with a pint of cider in hand), we need to talk about how the roadmap is organised.

When a new theme is defined, we ask the product owner (i.e., our point of contact within our client’s organisation) to define the impact of the theme – that is, how important it is, or how many benefits will result from achieving it. We like to keep this simple by representing the impact as a t-shirt size (extra-small, small, medium, large, extra-large – represented as a number between 1 and 5), as this makes it easy for the Product Owner to define where it sits in relation to the other themes on the roadmap.

It is important to understand that the impact rating is just one of many factors used when prioritising work. It can be useful when combined with an effort estimate (typically represented as a t-shirt size, or story point inspired by the fibonacci sequence – i.e. 1, 2, 3, 5, 8, 13, 20, 40, 100) assigned to each feature, because that can let us identify quick wins – that is, small-effort features which benefit large-impact themes – but other factors, such as a best-before date (i.e., the date after which there is no point continuing, as an opportunity may have expired), or technical limitations may have as much bearing on the priority.

So instead, each theme is prioritised into one of three statuses:

• now
• next
• later

Any themes labelled now are the immediate priority for the product, with most of the features in active development belonging to a now theme. Next-status themes are on the immediate horizon for resolution following one marked as now, and later themes are of a lesser priority still.

(There is a fourth status, ongoing, which we use to highlight the importance of maintenance, paying off technical debt, and writing documentation, each of which exist as a standard theme on all our roadmaps and are used to organise the jobs which serve those functions.)

It’s important to understand, however, that these are not intended to suggest when the theme will be delivered, but instead to be used as a priority indicator, so everyone on the team can understand where to concentrate their immediate effort, while informing the overall direction.

That isn’t to say that we don’t provide estimates for completion of work – that information can be gained from the individual features that build towards a theme – but simply that this isn’t the job of the roadmap.

After all, there is no guarantee that a feature built for a product is going to solve the problem defined in the theme. We can guarantee that the acceptance criteria outlined on a feature will be delivered, and we can do a reasonable amount of prep work to set ourselves up for success (much of which will be informed by the roadmap). But until a feature goes live, and we compare the success metrics outlined in the theme, we won’t know.

And that’s the ultimate strength of the roadmap – confirmation that the work we’re doing is solving the problem that it’s meant to solve, instead of delivering something which we hope will solve a problem and crossing our fingers.

By making decisions guided by the roadmap and testing the outcome of those decisions against the metrics defined, we can gather the evidence we need to prove (or maybe more importantly, disprove) that the outcomes match our expectations, and can adapt accordingly.

So the roadmap, with its overarching themes and problem-solving features, is vital to keep us on the right track to deliver the product solution.