On this page
Define the single job a user must be able to finish, then test every feature against it: if someone can still complete that job without the feature, it does not belong in version one. Most first feature lists shrink by half or more. What survives is usually three to six features.
Almost every founder writes a version one that is really a version three. Not from carelessness, but because every feature on the list feels necessary when you imagine the finished product.
This guide is the method we use in the first week of every build. It takes about ninety minutes with a list and a blank page, and it works whether you have eight features in mind or forty.
Start with the one job
Before touching the feature list, write one sentence: the job a user must be able to finish for this product to be worth opening.
Not the vision. Not the market. One job, one user, start to finish. If you cannot write it in a sentence, that is the real problem, and no amount of feature cutting will fix it.
A platform connecting freelance designers with startups, with profiles, messaging, contracts, payments, and reviews.
A startup can find a designer, agree a price, and start work.
The second version is testable. Every feature can now be measured against it, which is the entire point. If you have not yet worked out who that user is, do that first, since the job depends on who is doing it.
The removal test
Take any feature and ask one question:
If I remove this, can a user still complete the one job?
If yes, it is not version one. Not bad, not unnecessary forever, just not now. If no, it stays.
The test is deliberately blunt. Most feature debates happen because there is no shared standard, so the loudest preference wins. A single stated job gives you a standard, and the arguments get much shorter.
Every feature is defensible on its own. That is precisely why lists never shrink without a test.
Running it on your list
Write the one job at the top of the page
Keep it visible the whole time. Every decision below refers back to it, and it is surprisingly easy to drift once you are deep in the list.
Get every feature out of your head
One flat list. Do not order it, group it, or judge it yet. Include the small things, because those are where scope quietly hides. A signup flow is not one item, it is several.
Run the test on each line
Ask the removal question and answer it in one word. Resist the urge to explain. If you find yourself writing a paragraph to justify keeping something, that is usually the answer.
Sort what is left into three piles
Build now, defer to version two, or delete. Write one line beside each explaining why. That reasoning becomes your cut list, and it is the document you will thank yourself for in three months when someone asks why a feature is missing.
What almost always gets cut
After enough of these sessions, the same items keep appearing in the defer pile. None are wrong, all can wait.
| Feature | Why it can wait |
|---|---|
| Admin dashboard | You are the admin. A database view or a spreadsheet does the job for the first few months. |
| Multiple user roles | Pick one user for version one. Roles multiply the surface area of everything else. |
| Notifications | Nobody has enough activity to be notified about yet. Email manually until they do. |
| Settings pages | Sensible defaults are faster to build and reveal what people actually want to change. |
| Onboarding tours | If the product needs a tour, the product needs simplifying, not a tour. |
| Search and filters | Useful at volume. At ten records, a plain list is better. |
| Analytics for users | They have no data yet. Build this once they do. |
What should survive
The short list is usually mundane, and that is the point.
- Whatever the one job requires, end to end, with nothing missing in the middle.
- Accounts, if the job needs anything saved or private.
- The single path through the product, even if it is unglamorous.
- Whatever stops it embarrassing you, which is usually less than you think.
If your surviving list is three to six items, that is a healthy first version. If it is past eight, you are probably describing version two.
Common mistakes
Cutting quality instead of scope
Cutting means the product does fewer things, not that it does them badly. A narrow product that works is credible. A broad one held together with hope is not.
Deferring the hard thing
If one feature is central and technically awkward, it is tempting to push it out and build the easy things around it. That produces a shell. Build the hard part first, since it is what the product actually is.
Treating the cut list as rejection
The defer pile is your roadmap, not a bin. Once real users arrive, they will tell you which items mattered, and the guesswork disappears.
If the exercise does not feel uncomfortable, it has not worked. A version one you feel slightly embarrassed by, that does one job properly, beats a complete product nobody has used. You can always add. Removing after launch is much harder.
Before you take this to a developer
- The one job is written in a single sentence
- Every feature has been through the removal test
- What survives is three to six items
- Every cut has a written reason beside it
- The defer pile is saved somewhere as version two
- You can describe the whole product in under a minute
Take the surviving list to whoever is building, and ask them to quote against that list only. Anyone who quotes without asking what you cut is pricing execution rather than judgment, and you can read more about what that costs in what an MVP costs in 2026.
Questions
How many features should an MVP have?
What if my product genuinely needs two user types?
Does cutting features mean building something low quality?
What if investors expect to see more?
This guide is reviewed and updated as the method changes. Last updated 26 July 2026.