Product Roadmaps
What is a Product Roadmap for? What is the “job to be done” for which people “hire” Product Roadmaps? Of course, there are lots of different behaviours that Product Roadmaps support. Some of these behaviours are good, improving our chances of delivering something of value. Some, not so good. Even what might be considered “not so good” typically has a real need behind it, even if the approach they’ve taken is not something we would recommend.
The practice of using Product Roadmaps is still fairly nascent. We just haven’t been doing it for very long. Because of this, there is no such thing as “best practice”, merely some inkling of possibly good practices and patterns – as well as a bunch of novel ideas that aren’t yet proven.
NB: This article is a work in progress. The plan is to collect some suggestions about Product Roadmaps based on our experience as well as provide some references you might want to take a look at. Over time it will get refined and expanded as we continue learning.
Start with “why”
A list (off the top of my head – not complete!) of some of the different reasons for producing a Product Roadmap:
- Planning Dependencies. For example, advertising, training, marketing campaigns, seasonal or date-driven deadlines, 3rd parties and suppliers or even just a launch party.
- External Communication. This could be regarding planned “major” release dates, when batches of features will be available, or for key integration points that customers may need to plan around.
- Managing Expectations – Senior management and others generally need at least a rough idea of when features that are being worked on or planned are likely to be available by.
- Encourage Alignment – between multiple teams working on the same product, or between different parts of an organisation about which things are the most urgent and valuable.
- Negotiating Tactic – related to the above need for alignment, it sometimes helps to visualise the order in which things are planned to be worked on. This makes it clear that not everyone can get what they want when they want it. What follows is usually horse-trading and negotiations toward an equitable sharing of a scarce resource. (See also: Eurovision model)
- Resource Allocation – especially of scarce resources, money, people, management attention. By visualising where the product is going this can lead to increasing or decreasing resources to “make it so” (mythical man-month be damned).
- Others? (shout out in the comments below)
In a lot of cases, the original need behind the creation of a Product Roadmap tends to morph and change over time. Having committed in some way shape or form to a Product Roadmap (even one that is regularly updated) the way these are presented of course has an impact on how they are interpreted. (We see the same thing with estimates, of course.)
The original question (sometimes misunderstood) generates a response. Which then generates a further questions. And responses… in the usual dance of imperfect communication. Sometimes this is virtuous, meeting needs and allaying concerns and fears. Other times it quickly becomes a vicious circle. What you say and how you visualise it impacts this, of course. Basically, if all you provide is a visualisation of Features and Dates, then don’t be surprised when the conversation revolves around Features and Dates!
“Via negativa”
There are of course many, many different approaches and visualisations of Product Roadmaps. We are never going to see “the one true way” to do Product Roadmaps. However, we should at least be able to highlight some common pitfalls that Product Managers and Product Owners fall into…
- Glorified Gantt Charts – where we end up with a rolled-up simplification of what someone might produce in MS Project. I know some senior execs prefer not to see the “Executive Summary” version, without the detail, but hiding the complexity hides risks. How many actual roadmaps (with real roads on them) do you see that are really a list of turn-by-turn instructions and the precise timing of each?
- Hiding Uncertainty – both in terms of timings and what the output will be. We don’t know the future, and pretending that we do isn’t helping. Invite stakeholders and teams into the uncertainty, don’t hide it away.
- Too linear – Product Development is largely the art of iterating to discover what works and what doesn’t, what customer’s love and what they don’t care about. If your Product Roadmap shows a linear progression from one feature to the next then you’re missing a trick. If we know anything about positive Black Swans it’s that the real value to be gleaned is often adjacent to our original ideas. Need to encourage curiosity and discovery, for teams to ask questions, not shut down options prematurely.
- Not involving the teams in developing and updating the roadmap. (Shocking, I know – but I have seen far too many middle managers who sit behind their computers and produce a Product Roadmap and then present it to senior execs before any of the teams even see it!)
- No feedback mechanism – either updating the “distance” to the next thing (usually dates and features), or ignoring feedback from customers/users about results of an experiment. I’ve seen too many Product Roadmaps that drove the team onto the next thing even when there is a clear signal from customers that there is a rich seam to be mined through iteration and delivering further increments. And the opposite, clear signal that something has little value that teams continued to work on long after the allotted time should have been cut short.
- Using Estimated Inputs – e.g. people’s time as the only input when trying to work out predicted dates. (I will pull together some advice on forecasting separately, but there is generally an overlap with what you see on a lot of Product Roadmaps.)
- Many more, I’m sure – as I think of them, or as people share below!
Some advice
How I normally approach this is to first try and figure out: what question are they really asking? This requires careful listening and probing, since people often struggle to articulate what they really want. It can help to ask what decisions they would make if they had the answer.
Then, consider at least three different ways of answering that question. Perhaps there is a better, or healthier, way to answer the question without falling into some of the common traps above. Whilst they might ask for a glorified gantt chart of features on specific dates, most people (customers and internal) don’t want to be told a fairytale.
In that respect, at the very least I would always suggest that the visualisation of the roadmap needs to convey the increasing uncertainty the further away we project from what we think we know today.
Ordering Hypotheses
My preference (doesn’t always match the need!) is to instead provide a rough ordering of the key hypotheses that we want to test. Hypotheses further down the list (or to the right if rotated 90 degrees) and therefore further down the “road” should be more fuzzy or faint. We’re not even sure if we have the right questions, let alone the capability to answer them.
Melissa Perri‘s post on Problem Mapping goes in a similar direction, (also highlighting many of the same problems I’ve seen with Product Roadmaps). Melissa suggests one way of fixing some of these is to map “problems” onto quarterly (or other) timelines. This approach might best serve some of the more planning and time-oriented jobs above.
Of course we aren’t going to test them all at once, and neither are they all of equal importance and urgency. Ordering the hypotheses (or problems to solve) by Cost of Delay helps. In some cases you can time-box how long teams will spend exploring a hypothesis before moving on. Of course, a Product Roadmap that is lacking feedback loops, folding in new information as it arrives is one that is doomed to fail.
Where are we? Where could we go? What’s the landscape like?
One thing that bugs me about most of the Product Roadmaps I see is that they don’t help the viewer understand where the Product is today, nor the different paths that the product might take, nor what the competitive landscape looks like.
What are the key strengths, weaknesses, opportunities or threats for this product? What are the alternatives that customers and users are currently hiring to get their job done? What are the Push and Pull, promoting a new behaviour? What are their Anxiety and Habits that are blocking them from trying something new? None of this can I understand by looking at a typical Product Roadmap.
In short, Product Roadmaps tend to lack situational awareness (something you might consider to be pretty important in a map). Simon Wardley’s work on mapping is worth reading. Start with “On being lost“.
Another angle worth considering is David J. Bland‘s Assumptions Mapping. One change I would suggest is to change the vertical axis: Instead of going from:
[unimportant] –––> [important]
I would suggest this should be:
[Low Cost of Delay] ––> [High Cost of Delay]
Why? Well, when I’ve observed people doing Assumption Mapping they tend to intuitively do this anyway, but there is a bit of a mental fight and to and fro’ing that goes on as they wrestle with going against the specified linear order of importance. The reason unimportant to important feels wrong is that there are a bunch of things that are extremely important, but just not as urgent to bottom out given what we don’t know yet. Adding Urgency into the mix fixes this by combining value AND urgency. (To be clear, the value here is primarily information value!)
Here’s a Qualitative Cost of Delay approach you could use for this. Or, if you’re brave enough and you really want to surface assumptions, I’d recommend heading into System Two territory to help quantify the value of information as best you can.
Assumptions Mapping works really well when you’re in the very early stages of developing a Product. As you develop the product further though you’ll have a lot more than a bunch of brave assumptions to work on. There’ll end up being a mix of highly uncertain hypothesis about what will move the needle and others that are a bit more obvious. At this point, you can map ALL available options against these four buckets.
Beyond timelines?
The map of the territory and the climate doesn’t need to be the same as our forecast of what which towns and vantage points we plan to attack and our tactics or strategy for doing so. Whilst these are both legitimate needs, it can help to separate the two. (It’s for this reason we talk about Forecasting and Roadmaps together in our Product Management course.) If you free the Product Roadmap from having to answer questions relating to timing, you can
Overall, while “Roadmap” may sounds like a perfect metaphor, but you should always be considering whether your “Roadmap” is helping your organisation find it’s way to success – or is it constraining them too much? It sounds trite, but I do think that Doc Brown’s comment at the end of Back to the Future is worth considering:
Some useful references:
Roman Pichler’s “The product roadmap and the release plan”
Melissa Perri’s “Rethinking the Product Roadmap”
Ryan J. Singer’s “Position, Position, Position”
Simon Wardley’s Intro to the (imaginatively named!) Wardley Maps
Simon Wardley (again) “On being lost”
David J. Bland “Getting started with Assumptions Mapping”
As I said, plan is to add to this with additional references and expand on this topic in future. Do you have some additional Jobs that Roadmaps are used for, or References you would recommend? Share in comments below!