You've Got Scope. Now You Need a Sequence.
Last week, we forced the question every founder tries to avoid: If you can only build one flow, what is it? (Part 6). You named your primary success path. You cut the "nice-to-haves." You earned the right to actually plan the build.
So now you're building a roadmap.
And it probably looks like a plan. You've got milestones, a timeline, maybe a spreadsheet that maps features to weeks. It feels directional. It feels like progress.
Here's the problem: it's a fiction.
The Roadmap Confidence Trap
You are about to begin building. And the thing propping up every sprint, every standup, every week of engineering work is a document nobody in the room can defend with evidence.
How do you know the features in Week 3 are the right ones? Because they felt right when you sequenced them. How do you know the timeline is realistic? Because someone SWAGed it and nobody pushed back. How do you know the order matters? You don't. You guessed.
This is normal. Every early-stage roadmap is built on guesses. The danger isn't guessing — it's forgetting you're guessing.
When founders treat a roadmap like a delivery schedule, they optimize for output. Features get shipped. Boxes get checked. The team is busy. And three months later, someone asks, "What did we prove?" — and you can hear the crickets from the parking lot.
Your Roadmap Is a Sequence of Bets
A 0→1 roadmap exists to expose assumptions. Full stop.
Every item on it is an implicit bet: that your users will behave a certain way, that the market cares about this capability, that the technical approach will hold, that your distribution channel will produce results. The roadmap just happens to also produce software along the way.
If you don't make those bets explicit, you have no way to know whether what you ship actually proved anything — or just consumed time.
The question that should drive every roadmap decision at this stage isn't "What do we need to ship next?"
It's
"What do we need to learn next?"
Why Traditional Prioritization Breaks at 0→1
At an established product, you have KPIs. You have user data. You can run a RICE score or a MoSCoW exercise and feel reasonably confident about what to build next. The entire apparatus of product management — sprint planning, velocity tracking, impact estimation — is designed for environments with observable feedback loops.
At 0→1, you have none of that. There are no KPIs to impact yet. There is no baseline to measure against. And your confidence score for everything is effectively zero.
When confidence is low across the board, RICE stops being a prioritization tool and starts being a way to justify building the easiest things first. Confidence scores become theater.
And yet, most founders use the tools anyway. They run prioritization exercises designed for optimization-stage products on exploration-stage problems. Then they wonder why execution feels directionless despite everyone being busy.
The reason is structural: you are applying a scoring system that measures impact on known outcomes to a phase where the outcomes themselves are unknown.
What reduces the biggest unknown fastest? What de-risks the thesis? Those are the only two questions that matter at this stage. Everything else is premature optimization.
Granularity Is a Proxy for Honesty
Here's a test: look at how far out your roadmap extends with detail.
If you have a detailed, week-by-week plan stretching out 6 months — you are lying to yourself. Nobody can predict a 0→1 product trajectory six months out. You can (and should) have a North Star for where you want to be in Q4, but pretending you know which specific user stories will get you there in July is pure fantasy.
The teams that pretend they can are the ones that spend quarters executing a plan that stopped being relevant in Month 2.
A honest 0→1 roadmap looks roughly like this:
- Next 4 weeks: Granular. Specific stories, specific bets, specific "what we'll learn" criteria attached to each.
- Weeks 5–12: Directional. Goals and themes, loosely sequenced, explicitly tied to assumptions that may shift based on what the first 4 weeks reveal.
- Beyond 12 weeks: Strategic intent only. Not features. Not timelines. Just the questions you hope to have answered by then.
If your plan is equally detailed across all three horizons, the precision is cosmetic. You're creating the appearance of control over a process that doesn't have any yet.
The Apollo Test
I have been obsessed with the Apollo program since I was a kid. It is my all-time favorite case study in engineering, experimentation, and iteration. (Side note: if you haven't watched From the Earth to the Moon — the HBO miniseries, not the Jules Verne novel, although that's great too — do yourself a favor and watch it this weekend. You're welcome.)
Here's what most people miss about Apollo: NASA didn't plan 10 missions in detail and then execute them in sequence. They planned the next mission based on what the previous mission proved.
The Gemini program was designed as a deliberate staircase: Gemini 6A and 7 proved you could rendezvous in orbit. Gemini 8 achieved the first-ever docking. Each step built on the last. Then Apollo took that same approach and ran with it. Apollo 7 proved the command module worked in Earth orbit. Apollo 8 was redesigned mid-program — they literally changed the mission profile — to send humans all the way to the moon, because the results from 7 said they could. Apollo 9 tested the lunar module in Earth orbit. Apollo 10 took it to lunar orbit as a dress rehearsal. Each mission was built to answer one critical question, and what they learned shaped what came next.
The entire program was a learning sequence. That's how you put humans on the moon in under a decade with 1960s technology.
Your roadmap should work the same way. Your level of uncertainty is comparable. The difference is that NASA designed each mission to teach them what to build next. Most startups just... build the next thing on the list.
This doesn't mean you stop shipping to "learn." It means you ship in order to learn. Shipping is the only way to generate the evidence that tells you the next step. But if what you ship isn't designed to test an assumption, you're just typing code.
What a Learning-First Roadmap Actually Exposes
When you switch from "what are we building?" to "what are we learning?", uncomfortable truths surface fast.
- That feature your co-founder championed for three weeks? It doesn't test any assumption. It's a pet project wearing a product hat.
- That "Phase 2" you keep pushing to "later"? It contains the riskiest assumption in your entire thesis — and you've been avoiding it because it's hard.
- That metric you're tracking (DAUs, signups, page views)? It tells you people showed up. It says nothing about whether the thing you built solved the problem you defined. You're measuring foot traffic, not revenue.
This is where most teams hit a wall. The learning-first lens doesn't just change what you build. It changes what you're willing to confront.
The Checkpoint You're Probably Missing
Before your next planning cycle, run your roadmap through these three questions:
- For each item in the next 4 weeks: What specific assumption does this test? If you can't name one, the item is output — not learning.
- For the quarter: What will you know at the end of Week 12 that you don't know now? If the answer is "we'll have shipped features" — you don't have a learning plan. You have a to-do list.
- The pivot trigger: What result would cause you to change direction? If nothing on your roadmap has a trigger for "we need to rethink this," you've committed to a path without committing to evaluating it.
That third one is the hardest. We covered kill criteria in Part 4, but here's where it gets real: a roadmap without checkpoints is a one-way ticket. You'll spend the quarter, look back, and realize you were executing a plan nobody was testing.
Tying It Together
We are seven articles deep. Here's where it all connects.
Your thesis (Part 1) defined what you're solving and for whom. Your validation (Part 2) pressure-tested whether the market signal was real. Your business model (Part 3) checked whether the economics work. Your kill criteria (Part 4) defined what failure looks like. Your risk analysis (Part 5) identified what could go wrong. Your One Flow (Part 6) scoped what to build first.
The roadmap is where all of that either compounds — or unravels.
If your roadmap is a learning sequence, each sprint makes the next one smarter. The thesis gets sharper. The evidence gets harder. The decisions get clearer.
If your roadmap is a delivery schedule, each sprint just adds code. Nothing compounds. And three months from now, you'll be sitting in front of your board with a long list of things you shipped and no story about what any of it proved.
You're Closer Than You Think — And That's When It Gets Dangerous
The irony of 0→1 is that the moment you feel like you finally have a plan is usually the moment you're most at risk of executing the wrong one.
You've done the hard thinking. You've constrained scope. You've defined success. And now there's a powerful gravitational pull to just go — to stop questioning and start shipping.
That pull is the most dangerous thing in your startup right now.
Next week, in the final article of this series, we'll talk about what happens when execution starts and the roadmap meets reality — because most 0→1 products don't fail from one big mistake. They drift. And drift is almost always invisible until it's expensive.
Start With the Diagnosis
If you've been reading this series and thinking, “I see the gaps, but I’m not sure how exposed we actually are” — that’s the right reaction.
These articles are meant to sharpen your lens. But insight without structure doesn’t change decisions.
Before you rewrite your roadmap, pressure-test the bet behind it.
I built a focused 8-minute diagnostic to assess whether your current quarter is designed to produce real proof — or just motion.
It won’t fix your strategy.
It will show you where it’s fragile.
Take the Decision Debt Diagnostic and see where you actually stand.
Or if you already know: Let's talk.