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
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
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?
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
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.)