How to Scope Your MVP Before You Build Anything
Most founders treat an MVP as a smaller version of the product they eventually want to sell. That framing is why so many first builds take six months and still answer nothing.
An MVP is not a smaller product. It is the smallest experiment that can tell you whether people will change their behaviour for what you are offering.
Start with the decision, not the feature list
Before you scope a single screen, write down the decision this build has to inform. In most early companies it is one of three:
- Will people use this at all?
- Will they pay for it?
- Will they come back next week?
Write the decision in one sentence and keep it above your feature list. When a feature does not change that decision, it does not belong in version one.
If you cannot name the decision your MVP informs, you are not building an experiment. You are building a bet you cannot lose or learn from.
Separate the product from the proof
Every feature list hides two different things: the product and the proof. The product is what you want to have one day. The proof is the smallest thing that convinces a stranger to act.
For a booking product, the proof is not a calendar engine with timezone handling. It is a page where someone can pick a slot and pay. For a marketplace, the proof is not a matching algorithm. It is one transaction completed between two real people, even if you coordinate it by hand.
Strip the build down to the proof, then ship it.
Put a cost on every screen
For each screen, write three numbers: what it costs to build, what it costs to maintain, and what you learn if you are wrong about it. Most scope arguments disappear when a screen that costs two weeks and teaches nothing is compared with one that costs three days and settles a question.
Cut in this order:
- Anything that only matters after you have users.
- Anything that is hard to change later only in theory.
- Anything that exists because a competitor has it.
- Anything you could do manually for the first twenty customers.
Give yourself a deadline you believe
An MVP without a date becomes the product. Pick a date six to eight weeks out and treat the scope as the variable, not the date. If you are running late, remove a feature instead of moving the launch.
What to keep
Keep the parts that are expensive to learn and cheap to build: the core action, the payment path, and the way you hear from users. Everything else is a first draft, and first drafts are supposed to be rough.
The goal of the first build is not to look finished. It is to make the next decision obvious.