Prioritizing product features for a minimum viable product (MVP) means ruthlessly identifying the smallest set of capabilities that deliver the core value proposition to early adopters — and cutting everything else to ship faster.
According to Lenny Rachitsky on Lenny's Podcast, the biggest mistake first-time founders make is building a product that tries to solve five problems at once. The best MVPs solve one problem so well that the first 100 users tell everyone they know.
According to Gibson Biddle on Lenny's Podcast, Netflix's early success came from asking one question relentlessly: 'does this make customers happy in a hard-to-copy, margin-enhancing way?' For your MVP, strip that down further: does this deliver the one core promise?
According to Chandra Janakiraman on Lenny's Podcast, the biggest trap in early product development is optimizing for launch completeness rather than learning velocity — the MVP should be designed to answer a specific hypothesis, not to be a polished product.
What Makes a Good MVP?
An MVP is not a buggy product with missing features. It is the minimum capability required to:
- Deliver the core value proposition to early adopters
- Validate or invalidate the key product hypothesis
- Generate enough signal to decide the next bet
Minimum Viable Product: A version of a product with just enough features to be usable by early customers who can then provide feedback for future product development. The key word is "viable" — it must work for its target use case.
The 4-Step MVP Prioritization Framework
Step 1: Define the One Core Use Case
An MVP should serve one persona in one scenario better than any existing alternative. Write it as: "[Persona] can [core action] without [key pain point]."
If you can't write this sentence, you don't have an MVP — you have a feature list.
Step 2: Map to Must-Have vs Nice-to-Have
For every proposed feature, ask:
- Without this, can the core use case still be completed? If yes, it's Nice-to-Have.
- Without this, does the product break the core promise? If yes, it's Must-Have.
Be brutal. Most teams overestimate Must-Haves by 3-5x.
Step 3: Apply the Kano Model
- Must-be quality (threshold): Security, data integrity, core workflow. Non-negotiable.
- Performance quality: Features where more is better (speed, export options). Include only baseline.
- Attractive quality (delighters): Unexpected features that create delight. Cut from MVP.
Step 4: Sequence by Learning Priority
For each Must-Have, ask: "Will shipping this teach us something critical about user behavior?" Sequence by learning value, not engineering convenience.
Common Feature Categories to Cut from MVP
- Advanced admin controls (ship basic first)
- Analytics and reporting (log data; build UI later)
- Integrations (except the one that unblocks the core use case)
- Mobile app (ship web first unless mobile is the core use case)
- Multi-language support
- Advanced permission models
- Bulk operations and import/export (unless core to the workflow)
Step-by-Step MVP Prioritization Process
- Write the one-sentence product hypothesis — what you believe to be true about customer need
- List all proposed features with estimated engineering effort
- Score each feature: Must-Have (1) or Not Required for Core Use Case (0)
- Cut all zeroes — no exceptions without a compelling learning argument
- Estimate scope — sum Must-Have effort estimates; if > 3 months, cut more
- Define success metrics — what signal in the first 90 days confirms or denies the hypothesis?
Common Pitfalls to Avoid
- Scope creep from stakeholders: Every stakeholder has a "must have" that is actually a "would be nice" — use the core use case test to adjudicate
- Building for the demo, not the user: MVPs shaped by investor demos include impressive UI that doesn't help users achieve outcomes
- No clear hypothesis: An MVP without a hypothesis is just a small product, not a learning vehicle
- Skipping the onboarding: Users abandon products in the first 5 minutes; even an MVP needs basic onboarding
Success Metrics for MVP Launch
- 40%+ of early users say they would be "very disappointed" if the product went away (the Sean Ellis test)
- Core use case completion rate >60% in first week
- Qualitative feedback validates the core value hypothesis
- Learning velocity: team makes first major product decision within 60 days of launch
Explore more at PM interview prep and PM learning tools.
Learn from successful MVP strategies at Lenny's Newsletter.
Frequently Asked Questions
How do you prioritize features for an MVP?
Use the core use case test: if a feature is not required to complete the one core job your MVP promises, cut it. Apply Must-Have vs Nice-to-Have ruthlessly — most teams overestimate Must-Haves by 3-5x.
What should be included in an MVP?
Only features that directly enable the one core use case for the target persona. Everything else — analytics UI, advanced admin, integrations, mobile app — can be shipped in v2 after validating the core hypothesis.
How do you know if your MVP is too small?
An MVP is too small if it can't deliver the core promise end-to-end. If early adopters can't complete the key workflow and get value, the MVP doesn't test the hypothesis — it just frustrates users.
How long should MVP development take?
For most software products, 2-4 months is a reasonable MVP timeline. If you're still building after 6 months, you've either over-scoped or the hypothesis wasn't crisp enough to force cuts.
What is the Sean Ellis product-market fit test?
The Sean Ellis test asks early users: 'How would you feel if you could no longer use this product?' If 40%+ say 'very disappointed,' you've found product-market fit. It's a simple, validated signal for MVP success evaluation.