MVP Scope: A Cut-List Method for Deciding What Goes In

Teams usually build an MVP by adding: one more feature seems small, and each one is easy to justify alone. Six months later the "minimum" product has forty features and no users. Cutting works better than adding, because a cut forces you to say why something has to stay.

This post describes a cut-list method. You start with everything you want, then remove items using five tests until what remains is the smallest thing that can answer your most important question.

What an MVP is for

Before cutting, agree on the purpose. An MVP (minimum viable product) is the smallest release that lets you learn whether a real person will use your product for a real job. It is an experiment with a user attached. It is not a cheap version of the final product.

That gives you the first rule: an MVP is built to answer one question. Write it down. Examples:

• "Will independent physiotherapists pay to replace their paper appointment book?"
• "Will a buyer complete a purchase from a store they found on social media?"
• "Will small teams invite a colleague after their first week?"

If you have three questions, you have three MVPs. Pick the one whose answer would change your plans most.

Step 1: Write the full list

Gather the team for 30 minutes and write every feature, screen and idea on its own card or row. Do not discuss yet. Include the boring things: sign-up, password reset, settings, notifications, an admin view, a privacy page. Those are exactly the items that quietly eat weeks.

A typical early list might hold 30 to 60 rows. That is fine. The point is a complete inventory to cut from.

Step 2: Define the one job

Write one sentence for the core job the user comes to do:

"A [user] can [action] so that [outcome]."

Imagine a hypothetical booking app for home cleaners: "A homeowner can book a cleaner for a specific time so that they do not have to call around." Everything on your list now faces a test: does it directly help that sentence happen?

Step 3: Run the five cut tests

Go through the list row by row and ask each question in order. A feature that fails a test gets a label, not an argument.

Test 1: Is it on the path of the core job?

Trace the shortest route from "I need this" to "done". Features on that path stay for now. Everything else gets tagged off-path. In the cleaner example, searching, picking a time slot and confirming are on the path. Reviews, favourites, referral codes and a loyalty program are off-path.

Test 2: Can we do it by hand?

For each remaining feature, ask whether a person on your team can do it manually for the first 20 or 50 users. Instead of automated invoicing, you send an invoice from your accounting tool. Instead of a smart matching engine, someone picks the cleaner and replies by message. Manual work is slower and does not scale, but it costs hours instead of weeks, and it teaches you exactly what the automation will need to do. Tag these manual first.

Test 3: Does it reduce a risk we must learn about?

Some features are worth building even if they are not on the shortest path, because they test a dangerous assumption. If your whole plan depends on cleaners accepting jobs within ten minutes, a notification flow that makes that possible is a risk test. Tag these risk. If a feature is neither on the path nor a risk test, it moves to the later pile.

Test 4: Is it required by law, safety or payment rules?

Some things cannot be cut: a privacy policy where you collect personal data, consent where the law needs it, secure handling of payment details (usually by using a payment provider rather than building your own). Check the rules for your market and tag these mandatory. Be honest here, though. "We might need it" is not a legal requirement.

Test 5: Would a user notice if it were missing?

Imagine the first user with the feature absent. Would they fail to complete the job, or would they simply never think of it? If the second, cut it. Features nobody misses are the safest cuts.

Step 4: Sort into four piles

After the tests, every row belongs in one pile.

Pile	Meaning	Example (hypothetical cleaner app)
Build	On the path, a risk test, or mandatory	Time slot picker, booking confirmation, payment via provider
Do by hand	Needed, but a person can do it for now	Matching cleaners, sending reminders, refunds
Later	Real value, not for the first release	Reviews, favourites, recurring bookings
Never	Does not serve the core job	Referral codes, in-app chat

The Build pile should now be a fraction of the original list. If it is still more than about 10 to 15 items for a first release, run the tests again with stricter eyes.

A worked example, with the reasoning shown

Imagine a team building a tool for small clinics to send appointment reminders. The one job: "A receptionist can send reminders to tomorrow's patients in under two minutes."

Full list includes: patient import, reminder templates, SMS sending, email sending, two-way replies, analytics dashboard, multi-clinic accounts, billing, calendar sync, staff roles.

• Build: patient import (a simple spreadsheet upload), one reminder template, SMS sending through a provider, a basic account and sign-in.
• Do by hand: billing (the founders invoice the first clinics directly), onboarding (a call and a shared sheet).
• Later: two-way replies, calendar sync, multi-clinic accounts, staff roles.
• Never, for now: analytics dashboard. Why? The first question is whether clinics send reminders at all. Counting how many were sent can be done by a query run by the team.

The result is a product a developer can finish in a few weeks, and one that answers the actual question: do receptionists adopt this?

Step 5: Write the build list and a kill rule

Turn the Build pile into a short document:

1. The one question the MVP answers.
2. The one-sentence job.
3. The build list, with each item described in one line.
4. The "by hand" list, with who does each task.
5. A decision rule written before launch: "If fewer than X of our first Y users complete the job in two weeks, we stop and revisit the idea." Choose X and Y yourselves, based on your own context. Do not borrow numbers from a blog post.

The decision rule is the part teams skip, and it is the part that makes the MVP an experiment.

Mistakes we see in MVP scoping

• Cutting polish instead of features. A confusing core flow ruins the experiment. Keep the path clear, cut the sidebar of extras.
• Hiding scope in "small" items. Settings, roles and notifications look small and are not. Ask each for a one-line description of what it does before it earns a place.
• Letting one stakeholder's favourite feature bypass the tests. Run the favourite through the same five questions, in public.
• Confusing manual with shameful. Founders doing tasks by hand is the cheapest user research available.

FAQ

How many features should an MVP have?

There is no fixed number. A useful sign is that one person can describe the entire product in a few sentences, and that you can build it in weeks, not quarters.

What if investors or clients expect more?

Show them the cut list. A visible Later pile with reasons shows planning, not a lack of ambition.

Talk to us

If you are deciding what to build first and want to pressure-test your scope with a design and engineering team, get in touch. Email hello@risingstation.com or visit risingstation.com/contact-us.