The MVP scope template.
How to cut a first version down to the product it should be, plus a one-page structure you can copy, fill in, and hand to any team. No email required, it is all on this page.
01
How to use this
An MVP scope is a one-page argument about what not to build. The template below is the structure we fill in with founders during scoping, and it works just as well without us. Write it before you talk to any development team, ours included, and send the same page to everyone. It makes every proposal you receive comparable, and it makes scope creep visible the moment it starts.
One warning before the template: an MVP is a learning instrument, not a cheap product. Its job is to answer the question your company is a bet on. If you already know the answer, or if your product is one where trust makes a half-measure fatal, a classic MVP may be the wrong move. We wrote about those cases separately on the blog.
02
The cutting rules
Before filling anything in, agree on the rules of the knife. These are the cuts that reduce cost without reducing what you learn.
- Cut audiences before depth. One kind of user, served completely, beats three served vaguely.
- Cut anything a human can do by hand for the first months: onboarding, reports, billing exceptions, support.
- Cut settings and configuration. Opinionated defaults make every user's experience comparable, which is the point.
- Cut platforms. One platform done well, chosen by where your first users actually are.
- Cut integrations that can be a manual step or a spreadsheet export for now.
- Never cut the reliability of the core journey. A broken experiment teaches you nothing.
- Never cut the data model thinking. Screens are cheap to change later, foundations are not.
03
The template, ready to copy
Eight numbered blocks, one page total. If a block will not fit in the space suggested, that is the template working: the scope is not clear enough yet.
- 1. The bet. One sentence: we believe [who] will [do what] because [why]. If this sentence will not write, stop here and do the customer conversations first.
- 2. The single user. Who exactly the first version serves. A specific person you could name, not a segment. Everyone else goes in the cut list.
- 3. The core journey. The one path that must work, written as steps: from the moment the user arrives to the moment they get the value. Aim for under ten steps.
- 4. Day one. The shortest list of things that must exist for the core journey to work. Be suspicious of anything here that the journey does not touch.
- 5. The cut list. Everything deferred, each with one sentence on why it can wait. This list is expected to be longer than day one. If it is not, cut harder.
- 6. The manual list. Everything a human will do behind the scenes for the first months, and who that human is.
- 7. The launch test. What you will measure after launch, and what result tells you the bet was right. A number and a deadline, agreed before the build starts.
- 8. The constraints. The real budget, the real deadline, and any compliance the domain forces. Teams can only respect constraints they know about.
04
Defending the scope
The template is easy to write and hard to keep. From the day it exists, reasonable people will bring reasonable additions, and each one will sound small. These rules keep the page in charge.
- Every proposed addition must name which block it changes and what gets removed to make room.
- Anything that does not serve the launch test goes to the cut list by default, not by debate.
- The cut list is reviewed after launch, not during the build. That is when you will finally know something.
- If the bet itself changes mid-build, stop and rewrite the page. That is not failure, it is the cheapest pivot you will ever make.
- Argue with the page, not with each other. That is what it is for.
05
What a good filled-in page looks like
A strong scope page reads almost disappointingly plainly: one user, one journey, a short day-one list, a long cut list, and a launch test with a number in it. When founders show us a page like that, the build that follows is usually calm, and calm builds are the ones that come in on budget.
A weak page reads impressively: three audiences, a dozen features, integrations everywhere, and no launch test. If your page looks like that, the fix is not a bigger budget. It is another pass with the knife, and it is free.
Want help filling it in?
Bring a rough draft, even a messy one. Scoping the first version is the part of this work we enjoy most, and the first conversation costs nothing.