Every product roadmap is a statement of confidence about the future. Most of that confidence is unearned. The roadmap says “Q3: Launch mobile app.” What it actually means is “assuming we hire two mobile engineers by May, assuming the design is approved by June, assuming our API changes in Q2 don’t create blockers, assuming user research confirms mobile is the right priority.”
The Assumption Audit
The most useful thing you can do with a roadmap is enumerate every assumption underneath each item. Write them down explicitly. Then ask: which of these assumptions, if wrong, would cause this roadmap item to fail or be significantly descoped?
The assumptions that matter most are rarely about technology. They’re about customer behavior, market timing, team capacity, and internal dependencies. Technology is usually the most predictable variable in the equation.
What to Do Instead
Build your roadmap in layers. The next 6 weeks should be commitments: specific deliverables with owners and acceptance criteria. The next 3 months should be targets: directional bets with explicit assumptions listed. Beyond 3 months should be themes: strategic directions, not features.
Review your assumptions monthly. When reality contradicts an assumption — and it will — update the roadmap, don’t force the work to match the plan. A roadmap that never changes is a roadmap that no one is actually using to make decisions.
