Introducing the Product Roadmap

What is a product roadmap and why do you need one? What does the product roadmap do and how do you create it?

If you were around in 1994, you’ll be familiar with the song Cotton-Eyed Joe. Originally an American folk song written in 1861, the Swedish group Rednex released it as an electronic dance music remix in the summer of that year, much to the joy of teenagers everywhere.

For anyone who wasn’t around in 1994, or are lacking memory of this particular slice of the 90s, the song featured the following lyrics:

Where did you come from? Where did you go?
Where did you come from, Cotton-Eyed Joe?

What does any of this have to do with product management? Very little, if truth be told, other than the fact it’s feels like an (imperfect) analogy to explain the concept of the product roadmap.

Let’s imagine we’re working on a product called Cotton-Eyed Joe. The lyrics ask two very important questions: Where did it come from? And where is it going? And it just so happens that these are among the questions a product roadmap answers.

What are themes?

At Foxsoft, a roadmap is a collection of prioritised themes – which are, essentially, problems to be solved. Themes are typically aligned with the goals of the business and contain information on:

What is the problem being solved?
Why is it a problem?
Which metrics can be used to track progress?
How do we know when we’ve been successful?

The answers to these questions provide alignment between stakeholders and the technical team, allowing a greater understanding of the context behind the decisions which have been made, and an understanding of the overall direction for the product.

But before we go any further, we need to understand the difference between themes and features. Although the two are related, the difference is that themes exist to define problems, while features exist to attempt solutions, and they play different roles in the development lifecycle.

Each feature picked up for development typically feeds into one (or more) themes. If a feature doesn’t align with a theme, that might be a red flag that the feature in question is a solution looking for a problem or isn’t contributing to the overall direction for the product at that time.

This is especially useful when trying to manage the expectations of the HiPPOs (Highest Paid Person’s Opinion) and ZEbRAs (Zero Evidence but Really Arrogant) on the team, who might have the best interests of the product in mind, but might be misguided on how best to deliver that.

The other main distinction is that themes are big-picture overviews and are kept for reference once the problem defined has been solved, allowing for an overall history of the product to exist. This is the opposite of features, where the artefacts generated as part of the development process (such as feature specifications, user stories, acceptance criteria, mock-ups, etc.) are discarded once that feature has been delivered. This is because those artefacts are typically only true at that point in time and are aimed heavily at the development team, and as such don’t hold much value once the feature has been delivered.

(It’s probably important to mention that we do keep some documentation related to features, known as architecture decision records – ADRs – but that’s outside the scope of this article).

Bobbing for apples

Anyway, I feel that an analogy might be in order, so let’s think of it like an orchard being planted for an established cider brewery.

The theme might be something like “diversifying crops to avoid the risk of a single variety”, with sub themes grouping each variety to try (such as “Somerset Redstreak”, “McIntosh”, “Golden Russet”, etc.), and for each, a list of features such as:

purchase land
plough and fertilise the field
install irrigation
plant the rootstock
weeding (ongoing)
harvest first crop
run a test brew
tasting session

Each of the features above can be worked on and delivered individually, thus contributing towards the overall goal, which is tracked against the metrics of the theme and used to determine success or failure.

However, in this instance, I think we’ve missed a trick. The problem is that it’s going to take years before we can taste our first pint, and if the cider brewed with that variety of apple is bad, we won’t be able to sell it. Sure, we’ve learned a valuable lesson, but it’s taken us years to learn it – years which could have been used in more productive ways.

Thankfully there is a quicker and easier way of learning that lesson, by simply buying in quantities of the varieties we want to experiment with (instead of growing them ourselves) and using them to brew trial batches. This might work out more expensive-per-apple in the short term, but we’re able to run an experiment for each variety and reject any which don’t match our standards, allowing us to adapt our roadmap accordingly, and saving a lot of time and money in the longer term on the varieties which are ultimately unsuitable.

Likewise, if we discover a problem with one of the varieties as we work through the features, such as a lack of nutrients in the soil resulting in a poor harvest, we can check what that does for our metrics, and pivot accordingly.

But without the roadmap and the context it provides, reminding us of where we’re going (and where we’ve come from), we run the risk of making poor decisions.

I know analogy can be a bit difficult at times, so if you’re having trouble aligning this one with software development, imagine the “apples” are a reporting component to be added to an existing application. You may have a long-term intention of building the report tooling yourself, but you can short-cut the feedback loop on the success of the concept by paying a vendor to provide the tooling for you in the short term, allowing you to learn the lessons of that experiment and use them to inform your own approach.

Next time, we’ll look at how to organise that roadmap.