Deciding What to Cut From Your MVP Scope

We see the same pattern in almost every first product we are asked to review. The founder has a clear idea, a feature list that grew for months, and a launch date that keeps sliding.

Eric Ries defined the minimum viable product (MVP) as "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort". MVP scope is the list of features that version contains.

The hard part is not adding to that list. It is deciding what to take out without breaking the thing you are trying to learn. This post covers why MVP scope grows, a seven-step method we use to cut it, a test that sorts every feature into four groups, and the few things we never cut.

Why MVP Scope Grows Faster Than Anyone Plans

MVP scope grows because every feature sounds cheap when it is discussed alone. A settings page is "a day of work", a second user role is "just a flag", and an integration is "an API call". Each is small, but each one adds screens to design, states to test and edge cases to support, and the costs compound.

The second driver is fear of a bad first impression. Founders worry that early users will judge the product by what is missing, so they keep adding features that make the MVP look complete. In our experience early users judge it by one thing, which is if the job they came for works.

The third driver is that nobody owns the word no. Investors, advisors, early customers and the team all suggest additions, and without a written test for what belongs, the loudest request wins. That is how a first version quietly turns into what we call a v3 in disguise.

The cost is not only time. Product analytics firm Pendo found in its 2019 feature adoption report that 80 percent of features in the average software product are rarely or never used, based on usage data from 615 of its customer subscriptions. An MVP is the cheapest moment to avoid building that unused share.

How to Decide What to Cut From Your MVP Scope

Deciding what to cut from your MVP scope is a sequence of seven decisions, starting with the promise and ending with a written list of what you deferred. We run them in this order because each step gives the next one a test to apply, so the cuts stop being a matter of opinion.

1. Write the One Promise the MVP Must Prove

Start with a single sentence that names the user, the problem and the result. For example, a team building a contract tool might write that small business owners can produce a usable service agreement in under an hour without a lawyer.

Everything in the MVP exists to test that sentence. If a feature does not help prove or disprove it, the feature is a candidate to cut. The common mistake is writing three promises, one per customer type, which triples the scope before any feature is listed.

2. Map the Shortest Complete User Journey

List the steps a new user takes from arriving to getting the promised result, and stop at the first moment they get it. For the contract tool that might be sign up, pick a template, fill in details, edit a clause and download the document.

The journey has to be complete. A user should be able to start and finish the job inside the MVP, even if some steps are plain. We would rather ship one journey that works end to end than five partial features that each stop halfway.

3. List Every Proposed Feature, Including the Small Ones

Write down every feature anyone has suggested, from the core screens to the password reset email and the admin dashboard. Small items hide the most scope because nobody estimates them.

Next to each feature, note which journey step it serves, if any. Features that serve no step are usually the easiest cuts, and seeing them in a list makes that obvious to everyone in the room.

4. Sort Each Feature With a Must, Should, Could Test

Give each feature one label. The Agile Business Consortium's MoSCoW method defines Must Have items as the "Minimum Usable SubseT" a project guarantees to deliver, and adds Should, Could and Won't Have this time.

The useful part is the effort guidance. The same framework recommends no more than 60% of effort on Must Have items and around 20% on Could Have items, so there is room to absorb surprises. If your Must list already fills the whole budget, it is not a Must list yet.

5. Replace Features With Manual Work Where You Can

Many features exist to automate something that a person could do by hand for the first fifty or hundred users. Approvals, onboarding, reports and even matching can often run manually behind a simple form.

Manual work is slower per user but far faster to launch, and it teaches you what the automated version needs to do. We cut the automation and keep the outcome, then build the automation once the manual version is clearly the bottleneck.

6. Choose the Simplest Version of Each Feature You Keep

A kept feature still has a cheap version and an expensive one. A clause editor can allow plain text edits instead of conditional logic. A dashboard can be a weekly email, and payments can use a hosted checkout page instead of a custom flow.

The test is if the simple version still lets the user finish the journey and lets you measure the promise. If it does, ship the simple version and let real usage decide what deserves more depth.

7. Write Down What You Cut and When You Will Revisit It

Every cut goes into a deferred backlog with one line on why it was cut and what signal would bring it back. The Agile Business Consortium makes the same point about Won't Have items, which are documented so they are not quietly reintroduced.

A written backlog turns "no" into "not yet", which makes cuts easier for stakeholders to accept. It also gives you a ready list to prioritize once the first users show which gaps actually hurt.

A Cut Test That Sorts Every MVP Feature Into Four Groups

A simple test sorts every MVP feature into one of four groups, and we use it in scoping sessions so the conversation is about the journey rather than preferences. The table shows the groups and what happens to each.

Applied to the contract tool as an illustration, sign-up, templates and payment land in Keep, the clause editor lands in Simplify, and version history, electronic signatures and document sharing land in Cut. Users can still download a document and sign it offline, so the promise is fully testable.

Features Founders Usually Cut Too Late or Too Early

The features we most often see cut too late are the ones that add whole surfaces to the MVP rather than single screens. These are the usual suspects:

• Extra user roles and permission levels, which multiply every screen and test case.
• Settings and customization pages, which serve power users who do not exist yet.
• Admin dashboards, when a database query or a spreadsheet export would do for months.
• A second platform, such as native mobile apps next to a web app.
• Integrations with tools only some early users run.

The mistake in the other direction is cutting what makes the product trustworthy. Removing password reset, error messages, data export or basic security to save a week tends to cost more in support and lost users than it saved. We go through the cost of adding one more feature to your MVP in more detail, because the same arithmetic explains both mistakes.

What Never Gets Cut From an MVP, Even a Tiny One

Some things stay in every MVP we build, however small the scope becomes, because cutting them invalidates the learning. Minimal functionality is the goal, minimal quality is not.

The core journey has to work reliably, because if users hit bugs on the essential path, you cannot tell a weak idea from a broken product. Data that users enter has to be stored safely and be recoverable. Security basics such as proper authentication and encrypted connections stay in, because a breach in a first version is hard to recover from.

Architecture deserves the same care. A small MVP can still sit on a structure that will not need a rewrite. We cover the habits that make that possible in how to structure your codebase so it survives scaling. Our founder's playbook on MVP development covers how we weigh these trade-offs across a whole first build, with the aim of code that is minimal rather than thrown away.

Cut the MVP Scope to One Complete Journey and Ship

A good MVP scope is one promise, one complete journey and the smallest set of features that lets a real user finish it. Write the promise, map the journey, sort every feature with a clear test, swap automation for manual work where you can, and keep a written backlog of everything deferred. When we are unsure about a feature, we cut it and validate the MVP without building the full product.

If you want a second pair of eyes on a scope document before you commit budget to it, the team at Better Software can work through it with you.

Frequently Asked Questions

What Does MVP Scope Mean?

MVP scope means the set of features included in the first version of a product. We define it as the smallest feature set that lets one type of user complete one job end to end, so the team can test a single promise with real usage.

What Should an MVP Include?

An MVP should include one complete user journey, the features that journey cannot work without, and a way to measure the result. We also keep reliable core functions, safe data storage and basic security, because users will not trust a product that fails at those.

How Many Features Should an MVP Have?

There is no fixed number of features for an MVP. We count journey steps instead, and most first versions we scope need only a handful of screens. If the feature list cannot be explained in one sentence about one user, the MVP probably has too many.

How to Define MVP Scope?

To define MVP scope, we write the one promise the product must prove, map the shortest journey that delivers it, and label every proposed feature as keep, simplify, do manually or cut. Anything that no journey step depends on goes to a written backlog.

What Three Things Do You Consider in Creating Your MVP?

We consider the problem worth solving, the shortest journey that solves it, and the signal that proves it worked. Those three keep the MVP honest, because any feature that does not serve the problem, the journey or the measurement can wait for a later version.