Most roadmaps read like wishlists: every idea, sequenced by hope. A roadmap that survives contact with reality is the opposite — a short sequence of the smallest bets that de-risk the biggest questions.
Start from the riskiest question, not the biggest feature
Before writing a roadmap, list the top three questions that would sink the product if the answer turned out to be "no". Willingness to pay. Retention past week 2. Whether you can acquire customers below your target CAC. The first phase of the roadmap should answer the riskiest of those questions with the smallest possible build.
Cut the roadmap into 2–4 week phases
Each phase should have one goal, one metric, and one decision at the end (continue, adjust, or stop). Phases longer than a month tend to collect unrelated work and blur the decision point.
Every phase ends with a decision, not a demo
The output of a phase is not "we shipped X" — it's "we learned Y, and the next phase is Z because of it." If a phase can't produce a decision, it's either too big or aimed at the wrong question.
What to cut first
Anything that assumes the current product is already working. Polish, integrations, second-order features. Cut ruthlessly until the phase can actually be delivered in the window you've set — a shortened phase you finish beats a full phase you don't.