How to scope a first release you will actually ship
Most first versions are late because of what went into them, not how fast the team worked. Here is the cutting method we use, and the three things that are never worth cutting.
A first release that takes eight months is rarely a team that worked slowly. It is almost always a scope that was never survivable, agreed in a room where cutting felt like pessimism.
Scoping well is a skill, and it is mostly the skill of deciding what not to build while everyone still feels optimistic.
Start from the one loop
Every product has a core loop: the sequence a user repeats that delivers the value. For a dictionary it is search, read, understand. For a marketplace it is list, discover, transact.
Write yours down as one sentence. Then sort every proposed feature into two piles: required for the loop to work at all, and everything else.
The second pile is almost always four to five times larger than people expect, and it is where your timeline went. Not because those features are bad, but because none of them were load-bearing and all of them were scheduled.
"MVP" has stopped meaning anything
The term now covers two incompatible things: a deliberately small product that is genuinely good at one job, and a broad product built badly. The second is what most teams actually ship, and it fails because users forgive a narrow product but not a broken one.
A more useful framing: narrow and finished. Fewer things, each properly done, including the error states and the empty states. A first release that does one job completely earns the right to a second release. One that does eight jobs at 60% does not.
Cut scope, not quality. Cutting quality is invisible in a plan and extremely visible to a user.
The cuts that are usually right
Things that feel essential and can nearly always wait:
- Accounts, if the value works without them. Sign-up is the largest single drop-off in most funnels. Let people use the thing, add accounts when there is state worth saving.
- Admin interfaces. You are not the user. A database client or a script is fine for months.
- Settings. Every preference is a fork in behaviour to build and test. Pick a sensible default; add the toggle when people ask for it.
- Onboarding flows. A tour is often a patch over an interface that is not obvious. Fix the interface first.
- The second platform. Web then mobile, or one mobile platform then the other. Doing both at once more than doubles the work and halves the feedback speed.
- Localisation. Unless a specific market is the launch market. Translating a product still changing shape means retranslating it.
The three things not to cut
Cutting these looks like speed and is debt with a high interest rate.
1. The unhappy paths
Error states, empty states, loading states, offline. These are perhaps a fifth of the build and most of the perceived quality. A product that handles failure gracefully feels solid even when small. One that shows a blank screen when something goes wrong feels broken regardless of how good the happy path is.
2. Measurement
Ship without analytics and your first release teaches you nothing. You will not know which parts get used, where people stop, or whether the loop closes. You do not need a warehouse; you need to know that the core loop completes and where it does not.
3. The ability to deploy quickly
If shipping a fix takes a day of manual work, you will ship fewer fixes, and the first weeks after launch are when fixes matter most. A basic pipeline is a couple of days of work that pays back in the first fortnight.
Slice by user journey, not by layer
The most common planning mistake is building horizontally: all the data models, then all the API, then all the screens. Nothing works until everything works, and you learn nothing until the end.
Slice vertically instead. Build one complete path end to end, thin but real, then widen it. After week two you have something clickable. That changes the conversation from imagining the product to reacting to it, which is where the useful feedback lives.
A realistic shape
For a focused first release, roughly:
| Phase | Time | Output |
|---|---|---|
| Discovery | 1 to 3 weeks | Agreed loop, scope, risks, clickable prototype |
| Build | 6 to 12 weeks | Two-week cycles, working software each cycle |
| Launch | 1 to 2 weeks | Store review, monitoring, a watched first week |
Eight to sixteen weeks total for something narrow and finished. If your plan says six weeks for something broad, the scope is wrong rather than the estimate.
Write down what you cut
A practice that costs nothing and prevents a recurring argument: keep an explicit "not in v1" list, visible to everyone, with a one-line reason each.
It converts "we forgot" into "we decided", stops the same feature being re-litigated monthly, and becomes your v2 backlog already sorted by the discussion you had when you had the most context.
The test for a good scope
Two questions, and you want yes to both:
- If we built only this, would anyone use it? If no, you have cut something load-bearing.
- Could we build this properly, including the unhappy paths, in the time we have? If no, cut again.
Most plans fail the second question and nobody says so until week ten.