Firstly, it really depends what you mean by “Roadmap”. I’ve seen lots of Roadmaps, mostly bad, and a few good ones. The bad ones have some things in common:
1. There is only one road
Last time I checked, maps typically involve a two-dimensional (at least) abstraction of the landscape you are looking to navigate. They often contain lots of information, but one of the key jobs-to-be-done with a map is to understand what your options are about how to get where you want to be. Real roadmaps don’t just detail the steps required for the one route that has already been decided. A roadmap that doesn’t help you to understand your options isn’t a map, it’s a plan. For that, you need more than one potential pathway.
Try this: Instead of providing a single answer, provide optionality along the way. What are the alternative paths that we might take? Where do we suspect there might be roadblocks or traffic? There’s always more than one way to skin the cat, so show this. Don’t converge prematurely.
2. The road is straight
In general, I’m all for finding the shortest route between two points. As friends can attest, I often cross roads on an angle in order to shorten the distance. Unfortunately, in Product Development, the shortest route that you can identify today will almost certainly turn out to involve climbing a few mountains and figuring out how to get around gaps. Don’t be surprised to discover that your best roadmap today turns out to be missing some obstacles. The reason it’s missing this key information is probably because there’s no one in your organisation who has taken this road before.
Try this: Identify some of the known-unknowns and leave room (i.e. time) to discover new things along the way. You will face a number of hurdles along the way, be that technical constraints or simply how the market (users and customers) responds to what you’ve developed. This may sound all negative, but it’s not: some of the gold you’re looking for will in fact be tucked away slightly off the linear track that you might plot today. Good product management requires keeping your eyes and ears open to adjacent possibilities.
3. The road has dates
Only the most simple of maps include timeframes: they are the sort where a series of concentric circles shows how far you are likely to get in a matter of minutes. This works fine at the small scale and where the terrain is fairly homogenous, flat and with few obstacles (or at least many possible paths). This is not generally how Product Development goes. As such, putting timeframes on roadmaps can be a bad idea. You’re almost certainly oversimplifying things by doing so.
Instead, most maps portray distance – from which you are able to estimate how long you think it might take based on your velocity. Two things to note about this:
- In Product Development, we don’t have a perfect equivalent to “distance”. Most common is to use some form of “output” – a count of the number of stories, tickets, cards, storypoints or even the number of Acceptance Criteria. Be careful though: all of these entail a large degree of uncertainty and variability. Much better to measure output than input (i.e. hours/days) though. Just don’t be fooled into thinking that output is the same as Outcome though. Outcome >> Output >> Input. The days that a team put in to something is the input, much like the fuel you put in a car. How far that gets you (Output) depends on a whole raft of variables, not just the miles per gallon of the vehicle, but the traffic, the roads, the weather, etc.
- Velocity is a vector – which is a fancy way of saying it includes direction, not just magnitude. Scrum has popularised “velocity” as a term, but I’d suggest it is more like speed than velocity. A useful analogy here comes from Sailing, which has the concept of VMG (velocity made good). This tells you not how fast the boat is moving, but how quickly it is moving towards the next mark – where it is actually trying to get to. Some boats go faster in a straight line, but at an angle that is deeper. Others slower in a straight line, but at an angle that is closer to the next mark. Much like sailing, we should be optimising for VMG, not straight-line (in any direction) speed. Slower – but closer to the direction you actually want to go – can be good!
Try this: Don’t just use inputs. At least do an estimate or forecast of outputs. For this, you can use either your best guess as to how fast you think you are likely to go, or (even better) update your estimate based on how fast you have actually been going so far. Ideally, you would separate your forecast (or estimate) from the roadmap itself.
If you need to coordinate and align some other activity, first consider whether it is possible to decouple. If it really is impossible to decouple and you really do need a date, then do some forecasting, deciding what confidence-level you are happy to live with. Don’t forget to update your forecast with new data as it arrives.
(An aside: I’ve never understood why the most uncertain and risky pieces of work are often made subservient to other much less complex, less risky tasks – shouldn’t it be around the other way? The other question that often goes unasked is: why is it important to commit now? What would happen if you waited until you knew more? )
Where does Cost of Delay and CD3 fit in?
At the micro level, Cost of Delay and CD3 act like a metal detector. You wave it around you in the pool of near-options probing and sensing the Value and Urgency to help you figure out what your next step should be. When you get a strong hint that there is an asymmetric option with high Cost of Delay, go that way. Because you are dividing by Duration, the options that are likely to take longer get penalised. This has the excellent (and widely unappreciated) effect of encouraging people to break their ideas down, refining away the “nice to have’s” and unearthing the gold.
At the macro level, Cost of Delay acts a bit more like a radar sweep, helping you to sense where in the broader landscape the value and urgency might lie. Depending on your context, and in particular the maturity of the product (and associated business model) this can look very different.
For instance, if you are pre-Product Market Fit, you’re probably mapping out mostly information value that would come from testing hypotheses. If later in product maturity, you may be focusing more on the specific Push/Pull, Anxieties/Habits for the Job to be Done that you’re addressing. If it’s more at portfolio level for a well-established set of products, you may find that the four buckets of value are helpful for making sure the portfolio has some balance and where to cut the tail and start a new initiative/probe next.
At either micro or macro level though, Cost of Delay and CD3 can be used to order the options that a Roadmap reveals. Both together are useful in avoiding the classic hill-climbing algorithm problem, pushing you out of the comfort of local optimisations to go after value that is beyond your current local maxima. Sometimes you need to broaden the view and imagine what might be over the ridge right in front of you.
Remember, though: your compass is broken
Sadly, our intuition about Cost of Delay is generally pretty bad – we just don’t have the muscle memory or pattern recognition for it. To improve this, we have to fire up System Two and do a bit of thinking. Only then will we surface the assumptions we’ve been hiding and reveal the highest Cost of Delay opportunities, both near and far.
A good product roadmap should give us awareness of where we are, where we want to head and the different paths we could take. Product Roadmaps should be divergent – not closing down options but rather framing them, helping us make sense of the whole.
Then we can overlay Cost of Delay and CD3 on top of this, helping us to converge and bring the big picture into focus, acting as a guide for our decisions at the micro and/or macro-level. A well-developed Cost of Delay and CD3 detector and radar sweep helps improve our chances of success as we set off into the unknown.
(This post is sort of an extension of this one on Product Roadmaps, if you want to check that out too.)