Modern Product Roadmapping

The Roadmap, as an artifact, is increasingly hard to defend in Agile organizations. When a stakeholder asks me for one, and they often do, I try to explain to them it’s like asking someone how long it takes to swim from Great Britain to the US.

The answer would be a guess at best, and even after a couple of days of swimming, I’d still have no idea. I’d probably drown and never arrive at my intended destination.

The point of being agile is not committing to horizons you can’t yet see. That gives you the flexibility to adjust your course when new information arrives.

So there’s a problem. Stakeholders want something to hold on to, to measure progress against, or to have an opinion on. But you can’t give them a future feature list — that’s what I call a traditional roadmap. Even the best development teams hate it, often demanding more ‘vision’ from product management.

So there’s definitely value in roadmaps, even as we can almost be certain they’re factually incorrect. We need something that brings the same comforting feeling of control and progress to our stakeholders, without losing the ability to adjust and revise.

Traditional vs. Modern Roadmap

When you break down a traditional roadmap, you can clearly see its components: