By Mehdi HassanHow do you decide which features go into an MVP?
You decide which features go into an MVP by testing each one against two questions: does a user need it to complete the core job, and does it help prove or disprove your riskiest assumption? A feature that answers yes to either goes in. A feature that answers no to both goes on the version-two list, however good it is.
Most scoping goes wrong because it starts from the feature list. Founders write down everything the product will eventually do, then try to trim it, and the trimming becomes a negotiation where every feature has a defender. Starting from the assumption flips the question from "what can we cut?" to "what is the least we need to learn this?" That's a much easier conversation.
Scoping is the first step in our MVP design and development guide, and it drives everything after it: design effort, build cost and timeline. Below is the worksheet we use, followed by examples of cuts that kept the point of the product.
What is the riskiest assumption, and how do you find it?
The riskiest assumption is the belief your business depends on that you have the least evidence for. If it turns out to be false, nothing else matters. Finding it is the most valuable hour you'll spend on an MVP, because it tells you what the product has to test.
List every assumption behind the business: that the problem exists, that this audience feels it strongly, that they'll try a new tool, that your approach solves it, that they'll pay this price, that you can reach them. Then score each one on two things: how bad it would be if it were wrong, and how little evidence you have. The one that scores highest on both is your riskiest assumption.
Assumption type | Example | What the MVP must include to test it |
|---|---|---|
Demand | Clinic managers want automated shift scheduling | Enough of the scheduler to use on a real week |
Behavior | Freelancers will log time daily | A logging flow fast enough to become a habit |
Trust | Finance teams will accept AI-categorized expenses | Categorization plus an easy way to review and correct it |
Willingness to pay | Agencies will pay monthly for client reports | Real billing, not a waitlist |
Feasibility | We can match listings accurately from messy data | The matching engine on real data, even with a plain interface |
Different assumptions produce very different MVPs. A trust risk needs the review and correction flow to be excellent. A willingness-to-pay risk needs real checkout. A feasibility risk might need almost no interface at all.
What does an MVP scope worksheet look like?
An MVP scope worksheet is a table with every candidate feature in a row and four columns: which job step it serves, what it proves, what happens if it's missing, and a decision. Filling it in takes an afternoon and ends most scope debates, because each decision is tied to a reason.
Write the assumption and the core job at the top
One sentence each. For example: "Clinic managers will switch from spreadsheets to an automated scheduler," and "Create next week's rota from staff availability."
Map the core job as steps
From the user's first visit to the result. Typically five to eight steps: sign up, add staff, enter availability, generate rota, adjust, share.
List every candidate feature
Everything anyone has suggested. Don't filter yet; getting ideas onto the page is what lets you set them aside.
Fill in the columns for each feature
Which step does it serve? What does it prove? What happens if it's missing: blocked, worse, or no difference?
Decide: in, manual, or later
In if the job is blocked without it. Manual if you can do it by hand for the first users. Later for everything else.
Check the result end to end
Walk the core job with only the in and manual items. If a user can complete it and you can measure the assumption, the scope is done.
For example, suppose you're scoping the clinic scheduler
For example, suppose the clinic scheduler's feature list has 22 items. Running the worksheet: staff profiles, availability entry, rota generation, drag-to-adjust and sharing a rota link are in, because the core job is blocked without them. Shift-swap requests become manual: staff text the manager, who edits the rota. Payroll export, multi-location support, a mobile app, SMS reminders and custom roles go to later.
The resulting MVP is small, but it tests the real assumption: will a manager use it to produce next week's rota instead of the spreadsheet? This is a hypothetical example to show the method, not a report on a real product.
How do you use the MoSCoW method for an MVP?
The MoSCoW method sorts features into Must have, Should have, Could have and Won't have this time. It works for an MVP only if Must have is defined strictly: the features without which the user cannot complete the core job or you cannot test the assumption. Anything looser and the Must column swallows the backlog.
In practice, we treat Should and Could as one bucket, version two, because in a first release the difference rarely matters. The useful split is between what blocks the test and what doesn't. Won't have is the column people skip, and it's the most important one: writing an item down as explicitly out stops it creeping back in mid-build.
Pros
- Simple to explain to co-founders and investors
- Forces an explicit out-of-scope list
- Works well in a group workshop
Cons
- Must have inflates without a strict definition
- Doesn't tie features to the assumption on its own
- Should and Could split rarely helps in version one
Which MVP cuts keep the value of the product?
The cuts that keep an MVP's value remove breadth while keeping the core job complete. You can cut audiences, platforms, configuration and automation, as long as one type of user can still get one result from start to finish. Cutting depth inside the core flow is what destroys the point.
- Cut audiences, not steps. Serve one user type first. A marketplace can launch with one side recruited by hand.
- Cut platforms. One responsive web app instead of web plus iOS plus Android.
- Cut automation for manual work. Concierge onboarding, hand-sent reports and manual approvals are fine for your first users.
- Cut configuration. Ship sensible defaults instead of settings pages.
- Cut integrations for imports. A CSV upload often replaces the first three integrations.
- Keep the result screen. The moment the user sees the outcome is the one thing never to simplify.
How does MVP scope affect cost and timeline?
MVP scope is the biggest driver of both cost and timeline, more than the stack or the team's hourly rate. Every extra user role, integration or platform multiplies the screens to design, the states to build and the cases to test. A tight scope is the cheapest way to get to launch.
It also makes estimates honest. A fixed scope can be priced as a fixed project; a loose one can only be priced by the hour, which shifts the risk to you. Our guides on MVP development cost and MVP timeline show how scope moves each number. Your build approach matters too: no-code vs custom code compares the options, and best tech stack for a SaaS MVP covers the custom route.
Scoping also feeds your marketing. The features you cut still exist in your pitch as a roadmap, but the launch message should focus on the one job you do well. Our guide to features vs benefits helps turn that scope into copy.
How do you keep MVP scope from creeping?
You keep MVP scope from creeping by writing the version-one list down, naming one person who can approve changes, and giving every new idea a home on the version-two list. Most scope creep comes from good ideas with nowhere else to go.
Run every change request through the worksheet: which job step does it serve, what does it prove, and what happens if it's missing? If it's genuinely blocking, swap something out of equal size rather than adding. After launch, let real usage decide what comes next; our guide to feature discovery and adoption helps you see which features people actually find and use.
