MVP Features: What to Build (And What to Skip)
Introduction
You've validated your idea. You've talked to users. You're ready to build.
Now comes the hardest decision: what features actually make it into your MVP?
This is where most founders stumble. They know they should "build less," but they don't know which less to build. So they hedge. They include "just a few more" features to be safe. And before they know it, their 4-week MVP becomes a 4-month project that still doesn't answer their core question.
Feature selection isn't about trimming a wishlist. It's about strategic focus. The features you choose define what you'll learn, how fast you'll learn it, and whether you'll have runway left to act on what you discover.
In this guide, you'll learn:
- How to identify which features actually belong in your MVP
- A practical framework for prioritizing ruthlessly
- The difference between "must-have" and "feels essential"
- Common feature traps that kill momentum
- How to say no to features without second-guessing yourself
Let's get surgical.
Core Concept Explanation
What Makes a Feature "MVP-Worthy"?
Not every feature belongs in an MVP. The bar is simple but brutal:
A feature belongs in your MVP if—and only if—removing it would prevent users from experiencing your core value proposition.
That's it. Not "would be nice." Not "competitors have it." Not "users might expect it."
If a user can still test your core idea without the feature, it doesn't belong in V1.
The Feature Hierarchy
Think of MVP features in three tiers:
Tier 1: Core Value Features These are the features that are your product. Without them, there's nothing to test. For a scheduling app, this might be "create and share a booking link." That's the entire product at its nucleus.
Tier 2: Enabling Features These make the core value accessible. Authentication, basic navigation, essential data display. They don't deliver value themselves, but without them, users can't reach the value.
Tier 3: Enhancement Features These improve the experience but don't change the fundamental value. Better onboarding, email notifications, integrations, analytics dashboards. Nice to have. Not MVP material.
Your MVP should include Tier 1, the minimum viable Tier 2, and zero Tier 3 features.
What MVP Features Are NOT
Let's kill some common misconceptions:
MVP features are not "lite versions" of full features. You're not building a feature at 50% quality. You're building fewer features at 100% quality within their narrow scope. A half-working feature teaches you nothing except that half-working features frustrate users.
MVP features are not determined by competitors. What competitors have is irrelevant. They're solving for retention and growth. You're solving for validation. Different games, different rules.
MVP features are not what users say they want. Users will always ask for more. Your job is to identify what they actually need to experience your core value. Those are often different things.
MVP features are not what makes you feel safe. If your feature list doesn't make you nervous, you haven't cut enough. Discomfort is a signal you're doing it right.
Step-by-Step Breakdown: How to Decide What to Build
Here's a systematic process for defining your MVP feature set:
Step 1: Write Your One-Sentence Value Proposition
Before touching a feature list, complete this sentence:
"My product helps [specific user] achieve [specific outcome] by [how it works]."
Example: "My product helps freelance designers track project time and invoice clients by automatically logging hours and generating invoices."
This sentence is your filter. Every feature must directly serve this promise.
Step 2: Identify the Core User Action
What's the single most important thing a user does in your product?
For the time-tracking app: "Log time against a project."
Not "create a project," not "send an invoice," not "view reports." Those might support the core action, but they're not the action itself.
If a user can do this one thing, you can test your hypothesis. If they can't, you have no MVP.
Step 3: Map the Minimum Path
Work backwards from the core action. What's the absolute minimum a user needs to get there?
For the time-tracking example:
- Sign up (or sign in)
- Create a project
- Start/stop a timer
- See logged time
That's four features. Not fourteen. Four.
Everything else—invoicing, reports, integrations, team features—can wait.
Step 4: Apply the "Would They Leave?" Test
For each feature on your list, ask: "If this feature doesn't exist, would users abandon the product before experiencing core value?"
- No authentication? Users can't access the product. Keep it.
- No project categories? Annoying, but users can still track time. Cut it.
- No weekly reports? Users can manually add up their hours. Cut it.
- No mobile app? Users can use the web version. Cut it.
Be honest. Most features fail this test.
Step 5: Separate "Day 1" from "Week 2"
Create two lists:
Day 1 (Launch): Only features required for a user to complete the core action once.
Week 2 (First Iteration): Features you'll add after observing real user behavior.
The Week 2 list isn't abandoned—it's deferred. You'll build many of these features eventually. But you'll build them informed by data, not assumptions.
Step 6: Validate Against Your Learning Goal
Your MVP should answer a specific question. Does your feature set enable that answer?
If your question is "Will users pay for automated invoicing?" but your MVP doesn't include invoicing, you can't answer it. Add invoicing.
If your question is "Is time tracking valuable enough to pay for?" and you're including invoicing, you're muddying your results. Cut invoicing.
Features serve learning goals. Not the other way around.
Common Mistakes
Mistake 1: Building for Edge Cases
Founders love to ask "but what if..." questions.
- What if a user has 50 projects?
- What if two people edit the same record?
- What if someone wants to export to CSV?
Edge cases matter in mature products. In an MVP, they're distractions. Your first users won't hit edge cases—they'll barely scratch the surface. Handle the happy path. Worry about edge cases when you have enough users for edge cases to exist.
The fix: If fewer than 20% of your expected users will encounter a scenario, don't build for it.
Mistake 2: Copying Competitor Feature Sets
Your competitor has 40 features because they've had 4 years of user feedback and a team of 20 engineers.
You're not competing with their current product. You're testing whether your core idea has merit. That requires surgical focus, not feature parity.
The fix: Look at what competitors built first, not what they have now. Better yet, ignore competitors entirely until you've validated your core.
Mistake 3: Confusing "Professionalism" with Features
Some founders add features to look legitimate. Admin panels, detailed settings, comprehensive user management.
Your early users don't care about polish. They care about whether you solve their problem. A raw product that delivers value beats a polished product that doesn't.
The fix: Ship the minimum that works. Add "professional" features when users ask for them (and not before).
Mistake 4: Building for Scale Before You Have Users
"But what if we get 10,000 users?"
You won't. Not at launch. And if you do, that's a champagne problem—you can fix scalability issues with the money and momentum you'll have.
Building for scale on day one means you'll spend weeks on infrastructure that serves zero users while your actual product sits unfinished.
The fix: Build for 100 users. You can refactor later with real data about what actually needs to scale.
Mistake 5: Letting Technical Elegance Drive Scope
Engineers (including founder-engineers) love clean architecture. Reusable components. Proper abstractions.
But MVP code is throwaway code. It's meant to be replaced once you've learned. Investing in elegant architecture for features you might delete in two weeks is wasted effort.
The fix: Embrace messiness. Ship fast. Refactor if (and only if) the feature survives user contact.
Mistake 6: Including Features Because They're "Easy"
"It only takes an hour to add dark mode."
That hour could ship a feature users actually requested. "Easy" doesn't mean "valuable." Every feature adds cognitive load, QA surface area, and documentation needs—even small ones.
The fix: The question isn't "can we build this?" It's "should we build this?" Easy features that don't serve learning are still waste.
Best Practices and Frameworks
The One-Feature MVP
Imagine your product could only do ONE thing. What would it be?
Build that. Just that. The constraint isn't limiting—it's clarifying.
Dropbox's MVP was literally a video showing file syncing. Twitter started as SMS updates. Instagram launched with filters and sharing—no stories, no reels, no shopping.
One feature, executed well, is enough to validate demand.
The MoSCoW Method
Categorize every potential feature:
- Must have: Product literally doesn't work without it
- Should have: Important, but users can work around absence
- Could have: Nice to have if time permits (it won't)
- Won't have: Explicitly out of scope for MVP
Be ruthless with the "Must" category. Most founders put 15 features in "Must" when only 3 truly qualify.
The Feature vs. Workaround Test
For any feature you're considering, ask: "Can users accomplish this goal with a workaround?"
- Need reporting? Users can export and make a spreadsheet. (Cut it.)
- Need notifications? Users can check the app manually. (Cut it.)
- Need user accounts? Users can't access their data. (Keep it.)
If a workaround exists, the feature isn't core.
The 10-User Test
Imagine you're manually onboarding your first 10 users. What's the absolute minimum they need to experience value?
You'd probably skip:
- Automated emails (you'll send them manually)
- Password reset (you'll reset it for them)
- Comprehensive error handling (you'll fix issues in real-time)
- Fancy onboarding flows (you'll walk them through it)
Build only what you can't manually compensate for.
The "No User Has Asked For This" Filter
If zero users have explicitly requested a feature, it doesn't belong in your MVP.
This sounds extreme, but it's liberating. Instead of guessing what users might want, you're responding to demonstrated demand.
Obvious exceptions: core functionality required for anyone to use the product. But for anything optional? Wait for the ask.
Feature Freeze
Once you've defined your MVP scope, freeze it. New ideas go on a "Post-MVP" list. No exceptions.
This protects you from the "just one more feature" trap that turns 3-week MVPs into 3-month projects.
Real-World Examples
Example 1: The Over-Scoped MVP
A founder wants to build a CRM for real estate agents. Their feature list:
- Contact management
- Property listings
- Email integration
- Calendar sync
- Lead scoring
- Automated follow-ups
- Document storage
- Mobile app
- Team collaboration
- Reporting dashboard
Estimated build time: 4 months.
Problem: They don't know if real estate agents will switch from their current CRM. They're betting 4 months on an assumption they could test in 4 weeks.
Better approach: Build only contact management with basic property tagging. Get 20 agents to try it. Ask: "What's missing that would make you switch from your current tool?" Then build that.
Example 2: The Right-Sized MVP
A founder wants to help SaaS companies collect user feedback. Their hypothesis: "Product managers want a simpler way to collect feature requests from users."
Instead of building a full feedback portal, they build:
- A single embeddable feedback widget
- A simple list view of collected feedback
- Basic authentication
That's it. No voting, no roadmaps, no integrations.
Launch in 2 weeks. 15 product managers install the widget. 8 say they'd pay for voting and prioritization features.
Now the founder knows:
- The core concept resonates
- What specific features to build next
- That demand exists before investing in complexity
Example 3: The Strategic Deferral
A founder is building an expense tracking app for freelancers. They initially planned:
- Receipt scanning with OCR
- Bank account integration
- Automatic categorization
- Tax report generation
- Multi-currency support
After applying the framework:
Must have (Day 1):
- Manual expense entry
- Category selection
- Simple list view
Deferred to Week 2:
- Receipt photo upload (no OCR yet)
- Basic export
Deferred to Month 2+:
- Everything else
The founder launches in 3 weeks. Users immediately ask for receipt photos—so that feature gets built first. Nobody asks about multi-currency. It gets dropped entirely.
By deferring, the founder built exactly what users wanted and skipped what they didn't.
FAQs
How do I know if I've cut too much?
You've cut too much if users can't complete your core value proposition. If they can sign up, do the main thing, and get value—even in a clunky way—you've cut the right amount.
Err on the side of cutting too much. You can always add features. You can't un-waste the time spent building unnecessary ones.
What if users expect certain features as "table stakes"?
Question this assumption. What users say they expect and what actually determines their behavior are often different.
Early adopters are more forgiving than you think. They're looking for a solution to their problem, not a polished product. If you solve the problem, they'll tolerate missing "table stakes" features.
Should I build features that make the MVP look more "complete"?
No. Looking complete is a vanity metric. Learning fast is the goal.
If a feature doesn't contribute to learning whether your core idea has merit, it's waste—no matter how professional it makes you look.
How do I handle feature requests during the MVP phase?
Write them all down. Thank users for feedback. Don't build them yet.
Wait until you've talked to 20+ users. Look for patterns. The features 5+ users independently request are worth considering. The features one user really wants are probably not.
What if my MVP feels embarrassingly simple?
Good. You're doing it right.
If your MVP makes you nervous to show people, you're at the right level of minimalism. Your first users don't need impressive—they need useful.
Can I skip features if I'm building a two-sided marketplace?
Marketplaces are harder because you need minimum value for both sides. But the principle still applies: what's the minimum for a seller to list and a buyer to purchase?
Often you can fake one side. Be the first seller yourself. Manually recruit initial supply. Only build the tools once you've validated the demand side.
Conclusion
Feature selection is where discipline meets strategy. Every feature you include delays your learning. Every feature you cut accelerates it.
The founders who win aren't the ones with the most features. They're the ones who built the right features—the ones that tested their core assumption with minimal waste.
Your MVP isn't a showcase of what you can build. It's a surgical tool for learning what you should build.
Key takeaways:
- A feature belongs in your MVP only if removing it breaks core value delivery
- Build for your first 10 users, not your first 10,000
- Edge cases, competitor parity, and "professionalism" aren't MVP concerns
- The discomfort of cutting is a signal you're doing it right
- Every deferred feature is a bet you'll make with better information later
Cut deeper than feels safe. Ship faster than feels comfortable. Learn more than you build.
Ready to Define Your MVP Scope?
If you're struggling to decide which features make the cut—or you keep adding "just one more thing"—working with an experienced MVP team can bring clarity. The right partner will push back on scope creep and help you launch a focused product that answers the questions that actually matter.
Related guides: