MVP Scope: How to Define and Cut Features Ruthlessly

What MVP Actually Means

MVP = Minimum Viable Product, but most founders interpret this wrong.

MVP is NOT:

• A crappy version of your full vision
• Everything you want to build, just buggier
• The smallest thing you can technically ship

MVP IS:

• The smallest thing that tests your core hypothesis
• Good enough that users will actually try it
• Complete enough to provide real value

Your MVP should answer one question: Will people use this to solve their problem?

The One-Feature MVP

The best MVPs do one thing well.

Examples:

• Dropbox MVP — File sync between devices. That's it.
• Twitter MVP — Post short messages. That's it.
• Stripe MVP — Accept payments with 7 lines of code. That's it.

What is your one thing? If you can't answer in one sentence, your scope is too big.

The Feature Cutting Framework

For every feature, ask:

1. Is this needed to test the core hypothesis? If no, cut it.
2. Can users get value without this? If yes, cut it.
3. Is there a manual workaround? If yes, cut it and do it manually.
4. Will this feature be obvious within 30 seconds? If no, probably cut it.

Common features you can cut:

• Admin panels (use database directly)
• Email notifications (send manually)
• User settings (hardcode reasonable defaults)
• Multiple user roles (start with one role)
• Integrations (build when users ask)
• Mobile app (responsive web is enough)
• Analytics dashboard (use Mixpanel/PostHog)

The Time Box Technique

Set a hard deadline: 30 days to launch.

Work backwards:

• Week 4: Polish, testing, launch
• Week 3: Payments, deployment, legal pages
• Week 2: Core feature implementation
• Week 1: Auth, database, basic UI

If a feature doesn't fit in this timeline, it's not MVP. Add it to a "v1.1" list and move on.

The deadline is sacred. Miss it, and you'll add features forever.

MVP Scope Template

Fill this out before building:

Product: [Name]

One-sentence description: [What does it do?]

Core hypothesis: [What are you testing?]

Target user: [Who specifically?]

Core feature: [The ONE thing users must be able to do]

Success metric: [How will you know it works?]

Absolute requirements:
1. [Feature]
2. [Feature]
3. [Feature]

Cut (add to v1.1):
- [Feature]
- [Feature]
- [Feature]

Launch date: [30 days from now]

Real Example: Feedback Tool MVP

Let's scope a customer feedback collection tool:

Full vision: Feedback widgets, NPS surveys, analytics dashboard, user segmentation, integrations with Slack/Email/Intercom, team collaboration, white-labeling...

MVP scope:

1. User can sign up and log in
2. User can create one feedback widget
3. Widget can be embedded on any website
4. User can view collected feedback in a list
5. User can pay for the service

Cut for v1.1:

• Multiple widgets (MVP: one widget per account)
• Analytics dashboard (MVP: simple list view)
• User segmentation (MVP: no segmentation)
• Integrations (MVP: check dashboard manually)
• Team features (MVP: single user accounts)

Result: Can be built in 2 weeks instead of 3 months.

Signs Your Scope is Too Big

• You've been "building MVP" for more than 60 days
• You have more than 5 features on your list
• You're building features users haven't asked for
• You keep saying "just one more thing"
• You're embarrassed by how simple it is (good sign, actually)

Remember: If you're not embarrassed by your MVP, you launched too late.