A normal roadmap assumes the team understands the product well enough to sequence delivery. A zero-to-one roadmap often makes that assumption before the evidence exists. It turns guesses into dates, dates into commitments and commitments into a reason not to learn.
The solution is not to abandon planning. It is to acknowledge that an early product is running 2 systems at once: one to discover a repeatable customer outcome and another to keep the organization aligned while that discovery changes the plan.
One roadmap discovers the product. The other earns the organizational permission to keep discovering it.
Roadmap One: Evidence
The evidence roadmap begins with uncertainty, not features. What must be true for this product to matter? Which assumption would kill the strategy if it were false? What is the cheapest credible way to learn?
A useful evidence roadmap might sequence questions like these:
- Does this problem happen frequently enough to deserve a product?
- Can we change the user’s current behavior, not only collect positive feedback?
- Can the workflow produce reliable value under real constraints?
- Which segment reaches value fastest, and what do they have in common?
- Can the organization deliver that value repeatedly at an acceptable cost?
Features still appear, but as instruments. A prototype tests comprehension. A manual service tests willingness to change behavior. A narrow automation tests whether the system can deliver value reliably. The output of the roadmap is reduced uncertainty.
Roadmap Two: Commitments
The second roadmap tracks the promises around the product: a sales commitment, an integration dependency, a legal review, hiring, data access, operational readiness or an executive expectation. These are not administrative details. They determine which experiments are possible and how expensive it will be to change direction.
When hidden, commitments become surprise constraints. When visible, the team can distinguish a reversible product decision from an organizational promise that needs active renegotiation.
Evidence: What did we believe? What changed? What do we need to learn next?
Commitments: Who is planning around the current answer? Which promise becomes expensive if the answer changes?
Decision: What will we build, stop, narrow or renegotiate because of the new evidence?
Why Teams Confuse Motion With Progress
A feature roadmap creates visible motion. Tickets close. Screens appear. Demos improve. But a zero-to-one product can ship continuously without becoming less uncertain. The team adds capability around an unproven core and calls the resulting surface area a platform.
Evidence milestones are less theatrical: a segment retained, a workflow completed without intervention, a time-to-value threshold crossed, a customer willing to expand usage. They are also harder to fake.
The Transition To Scale
Zero-to-one should not remain permanently fluid. The moment a customer outcome repeats, the planning system needs to change. Reliability, instrumentation, onboarding, economics and operating capacity become first-class work. The evidence roadmap does not disappear; its questions move from “does this work?” to “where does this break?”
This is the bridge from product discovery to platform strategy. The product earns standardization one repeated behavior at a time. It earns scale when the organization can reproduce that behavior without heroics.
A Better Promise
Leaders still need a view of the future. Give them one—but make the type of confidence explicit. Separate what the team knows, what it is testing and what the company has committed to deliver. That distinction makes the roadmap more honest and stakeholder management more useful.
A zero-to-one roadmap should not pretend uncertainty has disappeared. It should show how the team intends to reduce it, and how the organization will adapt when the answer becomes clearer.