The Short Answer
How do you decide which features go in an MVP?
Start from the one thing the MVP must prove and the metric that will show it. Map the shortest path a user takes to get value, and include only the features that path needs. Sort everything else with MoSCoW, keep Must Haves to no more than about 60% of the effort, and write the rest on a “Won't have this time” list.
Most MVPs do not fail because the team built badly. They fail because the team built too much, too slowly, and learned too little before the money ran out. Scoping is where that is decided.
Why Scope Decides Everything
The Standish Group's CHAOS research found that only 20% of software features are used often, while 50% are hardly ever or never used. For an MVP that matters twice over. Every unused feature costs build time, and every feature you add makes it harder to tell what users actually responded to.
Eric Ries's original definition of an MVP is about learning “with the least effort”. Scope is how you control the effort. It is also the biggest driver of cost and time: see what a $15k MVP includes vs a $50k quote and how long an MVP takes.
Five Steps to an MVP Scope
- 1
Write the hypothesis in one sentence
Who will do what, and why. For example: “Independent gyms will pay £49 a month to replace paper class bookings.” If you cannot write it in one sentence, you are not ready to scope.
- 2
Pick the success metric before launch
A number and a date, such as “10 paying gyms within 60 days of launch.” Deciding it afterwards makes almost any result look like success.
- 3
Map the core flow
List the steps from a user’s first visit to the moment they get value: sign up, add classes, share the booking link, a member books. Each step is a candidate Must Have.
- 4
Sort every other feature with MoSCoW
Must, Should, Could, or Won’t have this time. Anything that is not on the core flow starts as a Should or lower and has to argue its way up.
- 5
Write it down and get it signed off
One document with the hypothesis, metric, flow, prioritised features and the Won’t list. This is what developers quote against and what stops scope creeping during the build.
MoSCoW and the 60% Rule
What is MoSCoW prioritisation?
MoSCoW sorts requirements into Must Have, Should Have, Could Have and Won't Have this time. It comes from the DSDM agile framework, which defines Must Haves as the Minimum Usable SubseT the project guarantees to deliver, and recommends they take no more than about 60% of the effort.
The definitions from the Agile Business Consortium, which maintains DSDM, are more precise than most people use them:
| Category | DSDM definition | In an MVP |
|---|---|---|
| Must Have | The Minimum Usable SubseT the project guarantees to deliver | The core flow; without it the hypothesis cannot be tested |
| Should Have | Important but not vital; painful to leave out, but the solution is still viable | Things users will ask for, but can live without for a few weeks |
| Could Have | Wanted or desirable, but less impact if left out | The contingency pool, dropped first if time runs short |
| Won't Have this time | Agreed not to be delivered in this timeframe | Your version-two list, written down so it stops coming back |
The effort guidance is the part most teams skip. DSDM recommends getting Must Have effort to a level where the team is confident of delivering, typically no more than 60%, with a pool of Could Haves of around 20%. The Should and Could Haves are the contingency. If everything is a Must, there is no slack, and the first wrong estimate makes the project late.
Sort Your Features
The starter list below is a typical subscription product. Replace it with your own features and rough effort in days, then move features between categories until Must Haves fall under 60%.
Interactive tool
Sort your feature list with MoSCoW
Edit the starter list or add your own features with a rough effort in days. Effort shares exclude Won’t Haves, as DSDM recommends.
- Sign up and log in 3d
- Create and edit the core record 6d
- Take payment 4d
- Email notifications 2d
- Admin dashboard 5d
- Team accounts and roles 6d
- Mobile app 20d
26 days in scope. Must 50% · Should 27% · Could 23%
Must Haves are within DSDM’s typical ceiling of 60% of effort.
What Most MVPs Need, and What They Do Not
Every product is different, but the same features come up again and again. A useful default is to buy or borrow anything that is not your core idea.
| Feature | Usual MVP decision | Why |
|---|---|---|
| Sign-up and log-in | Must, using a proven auth service | Needed to use the product; building your own adds security risk |
| The core flow | Must, built properly | This is what the MVP is testing |
| Payments | Must if the hypothesis is about paying | Willingness to pay is the strongest signal there is |
| Analytics on the core flow | Must | Without it, you cannot measure the success metric |
| Email notifications | Should | Helpful, but a manual email works for the first users |
| Admin dashboard | Should or Could | The founder can often use the database or a simple tool at first |
| Team accounts and roles | Could or Won’t | Adds permissions and testing across every screen |
| Native mobile apps | Won’t, unless the idea needs a phone | Often doubles the build; a mobile-friendly web app tests most ideas |
| Integrations with other tools | Won’t, except the one your users cannot work without | Each adds build time and dependency on someone else’s API |
If the hypothesis depends on something technically uncertain, scope a proof of concept first. Our guide to MVP vs prototype vs proof of concept explains the difference.
MVP Scope Document Template
This is the document to fill in before asking anyone for a quote. Giving several developers the same written scope is also the only fair way to compare their prices.
Template
MVP scope document template
Copy it into a doc and fill it in before you ask anyone for a quote.
MVP SCOPE DOCUMENT
1. The one thing this MVP must prove
[One sentence. e.g. "Independent gyms will pay £49 a month to replace paper class bookings."]
2. Success metric, decided before launch
[Metric, target and date. e.g. "10 paying gyms within 60 days of launch."]
3. Target user
[Who, and the problem they have today.]
4. Core user flow
[Numbered steps from first visit to the moment of value.]
5. Must Have (the minimum usable subset)
- [Feature]: [acceptance criterion]
6. Should Have
- [Feature]
7. Could Have (contingency)
- [Feature]
8. Won't Have this time
- [Feature]: [why it waits]
9. Platforms and integrations
[Web / iOS / Android. Payments, email, CRM, etc.]
10. Data and compliance
[Personal data held, where it is stored, UK GDPR notes.]
11. Ownership and handover
[Repository, credentials, documentation, IP assignment.]
12. Budget, timeline and decision-maker
[Fixed price or estimate, target launch date, one named person who signs off scope.]Two sections matter more than they look. The acceptance criterion under each Must Have (“a member can book a class from a phone in under a minute”) is what decides whether the work is finished. The ownership section makes sure you end up with the code: see software ownership and IP.
Scoping Mistakes
- Scoping the vision, not the test. The MVP is not version one of the full product. It is the smallest thing that tests the hypothesis.
- Everything is a Must. If cutting a feature would not stop you testing the hypothesis, it is not a Must Have.
- No Won't list. Features that are not written down as out keep coming back in every meeting.
- Building for scale too early. Plan for hundreds of users, not millions. Clean, well-structured code is what lets you scale later.
- No measurement. If the success metric is not tracked from launch day, the MVP cannot answer its question.
Once the scope is written, it can be priced as a fixed project. See fixed-price MVP development, or send Loomstrat your scope for a written price and timeline.
Frequently Asked Questions
How many features should an MVP have?
As few as the core user flow needs to test your hypothesis, often three to five. There is no right number; the test is whether removing a feature would stop you learning what the MVP is meant to teach you.
What is MoSCoW prioritisation?
A method from the DSDM agile framework that sorts requirements into Must Have, Should Have, Could Have and Won’t Have this time. DSDM defines Must Haves as the Minimum Usable SubseT and recommends they take no more than about 60% of the effort.
What should an MVP scope document include?
The hypothesis, the success metric, the target user, the core flow, prioritised features with acceptance criteria, a Won’t-have list, platforms and integrations, data and compliance notes, ownership and handover terms, and the budget, timeline and decision-maker.
Should an MVP be a mobile app or a web app?
A mobile-friendly web app tests most ideas faster, since it is one build with no store review. Build native apps first only if the idea depends on phone features such as the camera, location or notifications.
How do I stop scope creep during an MVP build?
Agree a written scope with a Won’t list before the build, record every new idea in a change log, and only add something by swapping out something of equal size. Keep Should and Could Haves as contingency.
What percentage of features are actually used?
The Standish Group’s CHAOS research found 20% of features are used often, 30% sometimes or infrequently and 50% hardly ever or never. That is the strongest argument for a small MVP scope.
A good MVP scope fits on two pages and makes at least one person uncomfortable about what was left out. That discomfort is a sign the scope is doing its job.