Roadmaps are political documents
A roadmap doesn't describe what you'll build. It describes what a group of people could agree on, on one Tuesday, under specific pressure.
The fiction we maintain
Product teams treat roadmaps as plans. The honest description is: a roadmap is a negotiated artifact. It reflects the organizational forces present at the moment of its creation - whose priorities had the most gravity that quarter, what got escalated, what got traded for something else, what engineering said it could do in six weeks. It is a snapshot of internal politics dressed in a Gantt chart.
None of this makes roadmaps useless. It makes them a different kind of document than the one we pretend they are.
What gets lost in the negotiation
When a roadmap is assembled by committee under deadline, a particular kind of item disappears: the structurally important thing that has no internal champion, no loud constituency, and no obvious quarterly metric. Discovery foundations. Foundational architecture decisions. Positioning clarity. The work that makes everything else coherent.
That work is quiet. It doesn't show up as a velocity point. It doesn't have an advocate in the stakeholder meeting. And so it gets deferred, perpetually, until the thing built without it collapses.
The tell
The tell that a roadmap is primarily political is this: it contains everything that each stakeholder wanted and almost nothing that any stakeholder is visibly not getting. A roadmap that has made real choices - that has said no, in writing, to things people wanted - is a rarer document. It's also a more useful one.
Delivery planning as structural conviction
Delivery planning that starts from strategy rather than from politics looks different. It sequences the build by what each milestone needs to teach you, not by what it needs to satisfy. It acknowledges uncertainty explicitly and makes the decision logic visible, so that when a constraint changes, the plan can adapt without a political renegotiation.
Using it correctly
The fix isn't to reject the roadmap. It's to be honest about what it is. Use it to manage expectations, communicate direction, and create accountability. But do not confuse it with the structural thinking that should precede it - the work that decides what's worth building before the organization gets involved.