What Makes a Good MVP Scope? The 5-Criteria Framework

The hardest part of building an MVP is deciding what not to build. Every founder has a feature list that is 3x bigger than their runway. The ones who ship fast and learn fast are the ones who cut ruthlessly.

Need to define your product scope? Use our interactive Feature Prioritizer to filter your absolute must-haves, or apply for a complimentary Free MVP Scope blueprint designed by our Senior Architect.

But cutting features feels like compromise. So founders keep adding "just one more thing" until the 3-week MVP becomes a 6-month product that is still not ready to launch.

The solution is not willpower — it is a framework.

The 5 Criteria for MVP Scope

A feature should be in your MVP if and only if it passes all 5 criteria.

1. It Is Required to Complete the Core User Journey

Every product has one core flow: the sequence of steps a user takes to get the primary value. This is the "critical path." Map it. Anything not on it is out.

For an invoicing app, the critical path is: Create client → Create invoice → Send invoice → Mark as paid. Every feature outside this path is a nice-to-have.

2. Without It, the Product Cannot Be Used at All

Some features feel optional but are table stakes. Authentication is not exciting, but without it you cannot deploy a multi-user product. These are "hygiene features." They belong in the MVP.

3. It Directly Tests Your Riskiest Assumption

Every MVP is a test of a hypothesis. What is the one thing you are most afraid is wrong?

If your hypothesis is "users will pay for automated reporting," then automated reporting must be in the MVP. If it is not, you cannot test it.

4. It Can Be Built in the Time Available

If a feature requires 3 weeks of a 3-week sprint, it is not MVP-ready. Either simplify it or cut it.

Ask: *"What is the simplest possible version of this feature that still delivers the core value?"*

5. Users Have Explicitly Asked For It

You should have user interview data before you build. If 7 of 10 users mentioned a specific pain, build the fix. Features invented in a vacuum are where roadmaps go to die.

A Practical Example

Idea: SaaS platform for freelance designers to manage clients and invoices.

Feature	Pass All 5?	In MVP?
Client management	Yes	Yes
Invoice creation	Yes	Yes
Email invoices	Yes	Yes
Payment tracking	Yes	Yes
Time tracking	No	No
Recurring invoices	No	No
Team collaboration	No	No

The MVP is 4 features. It is lean enough to ship in 2 weeks and still tests the core hypothesis.

The Scope Review Meeting

Before anyone starts building, read the scope out loud with the developer and designer. Every "simple" feature should be translated into user actions, edge cases, and a definition of done. "Invite teammates" might mean email invitations, permissions, pending states, expired links, resend flows, and billing seat changes. That is not one tiny feature.

The best scope meetings are slightly uncomfortable. They expose assumptions before those assumptions become missed deadlines. Add the out-of-scope decisions to the document, not just the approved features.

The Embarrassingly Simple Test

Paul Graham's advice: your MVP should be *embarrassingly simple*. If you are not slightly embarrassed by how little it does, you have not cut enough.

This is not about building something bad. It is about building the smallest thing that generates real signal. The market will tell you what to build next. Do not try to predict it — build the minimum and listen.

---

Written by Milad Kalhur *Founder & Chief Architect at Needmvp* Milad has designed, architected, and shipped over 40+ web applications for Y Combinator founders and VC-funded startups. Having pioneered the 3-week fixed-price MVP model, he actively consults on software development efficiency, database modeling, and high-performance serverless architecture.