A roadmap is a hypothesis, not a promise

Every roadmap I've ever inherited arrived wrapped in confidence. Quarters mapped out, dates attached to features nobody had validated, and a quiet understanding that everyone involved would pretend not to notice when half of it slid. We call this planning. It's closer to fortune-telling with a Gantt chart.

The trouble with a roadmap-as-promise is that it forces you to lie early. Once a date is public, the conversation shifts from “is this the right thing to build?” to “how do we protect the date?” Teams stop asking whether the idea works and start asking how to make the story of the idea work. That's how organisations end up shipping precisely on time, precisely into nothing.

I write roadmaps as hypotheses instead. Each bet reads: we believe doing X will move Y, here's the cheapest way to find out, and here's what would make us change our mind. Some entries are confident and get a date. Most don't, they get a next experiment and an honest label of what we don't yet know.

The surprising part is how well this goes down with stakeholders. Nobody actually wants a false promise; they want to know they won't be ambushed. A hypothesis roadmap gives them something better than certainty: it gives them the conditions under which we'd change course, in advance, in writing. When the course does change (and it always does) it reads as the plan working, not the plan failing.

A roadmap kept as a promise breaks slowly and painfully, usually in front of the board. A roadmap kept as a hypothesis breaks quickly and cheaply, usually in a research session on a Tuesday. One of those feels like failure. The other one is the job.