First version
You know what to build. Now you decide how much of it.
What is the smallest version that’s still worth showing?
Scope kills more products than competitors ever will, and it does it politely.
Everyone agrees on building something small, right up to the moment somebody has to name the thing being cut. Then every item comes back with a reason attached, and the reasons are all good. That’s the trap: you never lose an argument about scope. You accumulate small reasonable victories until the first version takes seven months.
I’ve been the person making those arguments. On one project I fought to keep a settings screen nobody had asked for, because the flow felt incomplete without it. It cost about two weeks. When we finally launched, I checked: eleven people had opened it. I had defended it with the word quality, which is a word I have learned to distrust when it comes out of my own mouth in a scoping meeting.
What works for me now is deciding what this version has to prove, in one sentence, before deciding what it contains. Everything that does not serve that sentence goes, not because it’s bad, but because it’s not this one. Most of it never comes back, which tells you what it was worth.
And the deadline is not pressure. It’s the most honest scoping tool you have, and the only one that does not negotiate.
Three ways to lose
time here.
- Building the version you would be proud to show instead of the version that answers the question.
- Polishing the part you enjoy. It’s always the interface, and it’s almost never the part that’s actually at risk.
- Treating “we can add it later” as free. Later is where the entire roadmap already lives.
Somebody outside the team can use it without you narrating over their shoulder. Not admire it — use it.
What to check
before you commit.
Everything at this stage comes back to one question — What is the smallest version that’s still worth showing? Each of these takes a different run at it, and gives you a verdict rather than a score.
They are free and they take under a minute. That is the point: the cheapest thing you can do at this stage is find out you were about to be wrong, and the most expensive is finding out a quarter later.
There’s a version
where I help.
A working session on scope
Bring the argument you’re currently having. We settle what the first version has to prove and what comes out of it, and you get the reasoning in writing so your team can push back on it.
Four questions on that page tell you whether this is worth it for you — including when it’s not.
Words this check uses.
- Reversible decision
- One you could undo quickly and quietly, where almost nobody outside the team would notice and nothing else gets built on top. How long a decision deserves depends on this, not on how important it feels.
- Scope creep by agreement
- How first versions grow: every item comes back with a good reason attached, nobody loses the argument, and small reasonable victories accumulate until the release takes months.
- Smallest version
- The least you can build that still answers the question you’re actually asking. Not a demo — usable by somebody who is not you.
About this stage.
What should go in a first version?
Whatever answers the question you built it to answer, and nothing else. If you cannot say in one sentence what the first version is testing, you are not scoping, you are guessing at a feature list.
How small is too small for a first version?
It is too small when it can no longer answer its question. That is the only limit that matters. Missing onboarding, missing settings and missing half the features are all fine if somebody can still do the one thing you need to watch them do.
How long should a first version take?
Six weeks is the number I keep arriving at, and both times I hit it I did so by cutting more than felt safe. Past about eight weeks the version you ship is answering a question you asked in a different market.