What Features Actually Belong in Your MVP (And What Doesn't)

Every founder arrives with a list of 40 features. The MVP ships with 6. Here's how to figure out which 6.

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.

The Core Job Test

Every product does one thing better than alternatives. Ask: "What is the single job a user hires this product to do?"

Examples:

• Notion: capture and organize information
• Stripe: accept a payment
• Slack: communicate with a team without email

Every feature in your MVP must directly enable or support that core job. If it doesn't, it goes in version 2.

The MoSCoW Framework

Categorize every feature into:

• Must Have: The product is broken without this
• Should Have: Strongly improves the experience, but not blocking
• Could Have: Nice, but users won't miss it at launch
• Won't Have (now): Save for later

Only build Must Haves in your MVP. Ruthlessly push everything else.

Features That Almost Never Belong in an MVP

• Admin dashboards (use the database directly at first)
• Email notification systems (do it manually with Gmail)
• Referral/affiliate programs (you don't have users yet)
• Multiple pricing tiers (charge one flat price)
• Multi-language support (do one language perfectly)
• Native mobile apps (a responsive web app is enough to validate)
• Advanced analytics (Mixpanel/PostHog free tier is enough)
• Social login with 5 providers (one auth method is enough)

Features That Almost Always Belong in an MVP

• User authentication (sign up, login, password reset)
• The one core feature (the reason the product exists)
• Basic billing (even if just a Stripe payment link)
• Empty states (what users see before they have data)
• Error handling (broken UI destroys trust immediately)
• A way to contact support (email or chat)

The User Story Filter

For each proposed feature, write a user story:

"As a [type of user], I want to [do something] so that [I get this outcome]."

If you can't write a clear user story — or if the user type is hypothetical — cut the feature.

The 3-Week Constraint

At NeedMVP, we use time as the ultimate filter. If a feature can't be built well in the time available, it doesn't ship. Simple.

This constraint forces both client and team to get ruthlessly honest about what actually matters. Every feature you don't build is:

• Developer time saved
• Bugs avoided
• Launch date moved forward

The Dependency Test

Some boring features belong because the core feature cannot succeed without them. Permissions may be essential in a team product. Import may be essential if users cannot start from an empty account. Export may be essential if buyers fear lock-in. The question is not whether the feature is exciting; it is whether the core job works without it.

This is where founders make both mistakes: cutting necessary plumbing because it is not flashy, and adding flashy features that do not reduce risk. Map dependencies around the core journey, then cut everything outside that map.

The Backlog Is Not a Trash Can

Cutting a feature from the MVP doesn't mean it's dead. A prioritized backlog is one of the most valuable outputs of the MVP process. It becomes the roadmap for version 2, the foundation for investor conversations, and a guide for your future engineering team.

Ship the minimum. Learn fast. Add what users actually ask for.

---

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.