What Features Should an MVP Have? A Prioritization Framework
Most feature-prioritization advice hands founders a scoring matrix: rate impact, rate effort, rate confidence, multiply it out, rank the spreadsheet. That works for teams comparing dozens of candidate features against each other. It’s overkill for the much more common situation — a founder with a rough feature list, trying to decide what actually belongs in version one.
Here’s a faster test: three questions, applied to each feature, no spreadsheet required.
The Three-Question Test
For every feature on your list, ask:
- Does removing this feature stop the core user journey from working?
- Does this feature test something you genuinely don’t know yet about your customers?
- Is this feature required for the product to operate safely or reliably?
If the answer to all three is no, the feature is a candidate to defer — not because it’s a bad idea, but because it’s not what version one exists to prove. If the answer to any one of them is yes, it likely belongs in the MVP.
Why This Beats a Scoring Matrix for a First MVP
Formal frameworks like RICE, MoSCoW, or the Kano model are genuinely useful once you’re comparing a long backlog against limited engineering capacity — situations where nuance between “high priority” and “medium priority” actually matters. For a first-time MVP, that nuance is mostly noise. What you actually need is a fast, defensible way to separate “must exist for version one” from “everything else,” and a scoring exercise often takes longer than the decision it’s meant to inform.
If you later find yourself managing a genuinely long backlog with a team that needs a shared scoring language, how to use RICE scoring for MVP feature prioritization and MoSCoW prioritization for MVP features are worth reaching for. For scoping a first MVP solo or with a small team, the three-question test gets you to a decision faster.
Question 1 in Practice: The Core Journey Test
Picture your MVP’s single core journey from start to finish — the one you defined before scoping anything. For each candidate feature, ask whether a user could still complete that journey without it. If yes, it’s not required for launch, whatever else it might offer.
Example: For a booking platform, “select a time slot” fails this test if removed (the journey breaks). “Leave a review after the appointment” passes — the booking journey completes fine without it.
Question 2 in Practice: The Unknown Test
An MVP exists to generate evidence about things you don’t yet know — will people pay, will they return, does this workflow actually fit how they work. A feature earns its place if it’s specifically there to test one of those unknowns, even if it’s not part of the core journey itself.
Example: A “willingness to pay” test — showing a price before the feature is fully built — can justify inclusion even though it’s not part of the core journey, because it answers a real unknown cheaply.
Question 3 in Practice: The Safety and Reliability Test
Some features aren’t about the customer experience at all — they’re about keeping the product from breaking or causing harm. Basic error handling, essential security measures, and safeguards against obviously abusive use fall here. These often don’t show up on a founder’s initial feature list because they’re invisible until something goes wrong, which is exactly why they need to be asked about deliberately. For the fuller picture of what falls into this non-feature category, see what should an MVP include.
Applying the Test to a Real List
Take a sample MVP feature list for a scheduling tool:
| Feature | Core journey? | Tests an unknown? | Safety/reliability? | Include in v1? |
|---|---|---|---|---|
| Book an appointment | Yes | — | — | Yes |
| Cancel/reschedule | Yes | — | — | Yes |
| Email confirmation | — | — | Yes (reliability) | Yes |
| SMS reminders | No | No | No | Defer |
| Loyalty rewards | No | No | No | Defer |
| Payment at booking | No | Yes (willingness to pay) | — | Yes, if pricing is the key unknown |
| Multi-language support | No | No | No | Defer |
Notice how the table separates the feature from the reasoning — that’s the actual value of the test. It forces you to name why something belongs, not just assert that it does.
What to Do When Multiple Features Pass
Occasionally the three-question test still leaves you with more “yes” answers than your budget or timeline can absorb — several features all genuinely test something you don’t know, for instance. When that happens, don’t reach for a scoring matrix by default. Instead, ask which unknown is the riskiest one to leave unanswered: which assumption, if wrong, would sink the whole idea versus just one feature of it. Prioritize testing that assumption first, even if it means genuinely useful but lower-risk questions wait for a second release. This keeps the test’s simplicity intact while still giving you a tiebreaker when you need one.
When to Say No, Even to a Feature You Like
The hardest part of this test isn’t applying it — it’s trusting the result when it excludes something you’re personally excited about. A feature failing all three questions doesn’t mean it’s a bad idea. It means version one isn’t the place to prove it. Keeping that list visible (rather than deleting deferred ideas) makes it easier to say no now without it feeling permanent. For more on protecting that boundary once development starts, see how to avoid feature creep in your MVP. The test doesn’t get easier with practice because the features get less appealing — it gets easier because you trust the filter more than your first instinct.
Want Help Applying This to Your Actual Feature List?
MVPHUB works through exactly this kind of prioritization with founders before development starts, so version one stays focused on what actually needs testing. Book a free consultation with MVPHUB to run your feature list through it.
Book a free consultation with MVPHUBFrequently Asked Questions
What features should an MVP have?
Only the features required to complete one core user journey, test your central business assumption, and operate safely. A useful test is asking whether removing a feature would stop the core journey from working, or would test something you genuinely don't know yet — if not, it can usually wait.
Do I need a formal scoring framework like RICE or MoSCoW to prioritize MVP features?
Not necessarily for a first MVP. Formal scoring frameworks help when you're comparing a long list of competing features with a team, but a small founding team can often make faster, equally sound decisions with a simple three-question test applied to each feature.
What's an example of a feature that fails the three-question test?
A loyalty points system for a marketplace MVP: it doesn't block the core transaction journey, it doesn't test whether people will use the marketplace at all, and it isn't required for safe operation. It's a reasonable feature — just not for version one.
How many features usually pass this test for a typical MVP?
Fewer than founders expect — often somewhere between 5 and 10 for a focused single-journey MVP. If significantly more features pass, it's worth checking whether the core journey has actually been kept narrow enough.
