- Product
- Strategy
- Startups
How to scope an MVP you can actually ship in twelve weeks
The failure mode is never building too little. It is building four half-finished things instead of one that works. A practical method for cutting scope without cutting the product.
We have run this exercise with something like sixty founding teams. The pattern is consistent: the first scope everyone brings is roughly three times what they can build, and cutting it feels like admitting defeat. It is not. A product that does one thing completely beats a product that does four things partly, every single time.
Write down the core loop first
Before you list a single feature, write one sentence describing the loop a user repeats to get value: a user does X, the product responds with Y, and that makes them come back to do X again. If you cannot write that sentence, you do not have a scoping problem — you have a product problem, and no amount of engineering will fix it.
For a booking product it might be: a customer finds an available slot, books it in under a minute, and gets a reminder that means they show up. Everything in v1 either serves that loop or waits.
The three-question test
For every proposed feature, ask three questions in this order:
Does the core loop break without it? If yes, it is in. If no, continue.
Can a human do it manually for the first hundred users? If yes, do that instead of building it.
Will we learn something in month one that changes how we build it? If yes, wait until month two.
Question two is the one that saves the most time. Onboarding, invoicing, moderation, matching and support all feel like they need automating on day one. They do not. Doing them by hand is how you find out what the automation should actually do.
Nobody has ever regretted launching without an admin dashboard. Plenty of teams have regretted spending three weeks building one before they had users to administer.
What always makes the cut
A few things are non-negotiable even in the smallest v1, because retrofitting them is expensive and because users notice their absence immediately:
Authentication that works on mobile. Half your traffic, and a broken login means zero of it converts.
A real error state for every network call. Silence when something fails destroys trust faster than the failure.
Analytics on the core loop. If you cannot see where people drop out, you are guessing in month two.
A way to contact a human. Your first hundred users are your research programme.
What almost never makes the cut
Multi-language support, granular permissions and roles, a public API, dark mode, native mobile apps alongside the web app, and any integration that fewer than a third of your users have asked for. Each of these is reasonable eventually. None belongs in twelve weeks.
Handling the feature you cannot let go of
There is usually one feature the founder is emotionally attached to that does not survive the test. The compromise we use: build the smallest visible version of it — a static page, a waitlist button, a hard-coded example — and measure whether anyone touches it. If they do, it earns a sprint in v2 with real evidence behind it. If they do not, you saved a month.
A twelve-week shape that works
Two weeks of discovery and design, eight weeks of build in four two-week sprints with a deployable build at the end of each, then two weeks of hardening, analytics and launch. Nothing new enters scope after week four. That constraint is the whole method — everything above is just how you decide what goes in before the door closes.
