The definition people get wrong
An MVP is not a bad version of your product. It's the smallest thing that takes one person all the way from their problem to it being solved. "Minimum" describes the scope of the promise, not the quality of the work.
This distinction decides how you cut. Given a product with five features, most people build all five at 20% quality. The result is a demo where nothing quite works — which teaches you nothing, because no user ever completed a real task. The correct cut is one feature at 100%, all the way to the end.
| Cut by quality (wrong) | Cut by scope (right) |
|---|---|
| Five half-working features | One feature that finishes the job |
| Users get stuck everywhere | Users get stuck at the edges you deliberately excluded |
| Feedback is about bugs | Feedback is about whether the problem was worth solving |
| Can't charge for it | Can charge for it |
What to cut, in order
There's a fairly reliable order to this, and it holds across most software products.
- Settings and preferences — pick a sensible default and ship it
- Onboarding flows — talk to your first ten users directly instead
- Admin panels — you have a database and you know how to query it
- Team accounts, roles, and permissions — start with one user per account
- Integrations — a CSV export solves most of this on day one
- Billing automation — an invoice sent by hand is a valid payment system for ten customers
- Anything triggered by "but what if we get a thousand users"
Three MVPs that aren't products
The concierge
You do the work manually for each customer while they experience it as a service. Slowest to run, fastest to learn from, because you see every step where the process actually breaks.
The Wizard of Oz
The interface looks automated; a human is behind it. Legitimate when you're testing whether the output is valuable, not whether you can automate it — and only when nobody is misled about something that matters to them, like who is reading their data.
The single page
One page describing the product with a real way to commit — a deposit, a waitlist with a follow-up call, a pilot form. Tests reachability and interest, not usage. Weakest of the three, and by far the fastest.
A worked example
Scoping yours
- Write the one job it must finishOne sentence, one user, one outcome. "A freelancer gets a list of twenty local businesses with a drafted email for each."
- List every step that job requiresBe literal. Include the boring steps — logging in, getting the data out.
- Delete every step that isn't on the shortest pathNot "defer". Delete, then see if the job still finishes.
- Write down what shipping it will teach youIf the answer is "whether people like it," sharpen it. "Whether anyone runs it a second time in the same week" is a real question.
- Set a date, and cut scope to meet it rather than moving itThe date is the forcing function. Moving it removes the only constraint doing useful work.
Common mistakes
- Building five features at 20% instead of one at 100%
- Treating "minimum" as permission to ship something broken
- Adding a settings page before there is a single user with a preference
- Building for a scale you don't have — the thousand-user problem you'll never reach if the first ten don't return
- Shipping without deciding, in advance, what the result would teach you
Key takeaways
- An MVP finishes one job completely for one person
- Cut scope, never quality — half-working features teach you nothing
- Concierge, Wizard of Oz, and a single page are all legitimate MVPs
- Decide what shipping should teach you before you build it
Try it yourself
Write your product's feature list, then cross out everything not required for one user to complete one job once. Whatever survives is your MVP. If nothing survives, the job wasn't specific enough — write a narrower one.