Roadmaps look precise. Milestones, sequencing, dates that suggest things are understood and under control. What they don't show is how many of those dates depend on decisions that haven't been fully made yet. Scope shifts. Dependencies clarify. Teams move forward on assumptions that still need testing. The roadmap compresses all of that into a timeline.
Part of the confusion comes from where roadmaps sit. They're not strategy; strategy sets direction. They're not tactics; tactics are how the work gets done. A roadmap lives between the two, translating intent into a sequence of bets over time. That's what makes them useful. It's also what makes them fragile.
Leaders often read a roadmap as a commitment. Teams experience it as direction. When priorities shift or new information surfaces, changes get treated as execution problems. Usually, the underlying assumptions just changed.
The issue isn't using roadmaps. It's treating them as fixed when they're built on things still in motion. A better approach makes the uncertainty visible: name the open decisions, separate what's known from what's assumed, and keep dates conditional.
Because the work isn't just building what's on the roadmap. It's making and revisiting the decisions that determine whether the roadmap holds at all.
