A working framework for deciding what makes the MVP, what gets cut, and what waits for v2 — with the exact matrix I use in client engagements.
Feature prioritization is the single highest-leverage decision in MVP development. Get it right and a small team ships a sharp product in a quarter. Get it wrong and a competent team ships a bloated v1 in three quarters, having missed the actual hypothesis along the way.
Most founders treat prioritization as a feeling — "this seems important." The result is a feature list that grows under pressure and never shrinks. Prioritization is supposed to do the opposite. It is supposed to shrink the list on purpose.
Start with the hypothesis, not the feature list
If you haven't written your one-sentence hypothesis yet, stop. You can't prioritize features against an unstated goal. The hypothesis is the ruler. Without it, every feature looks equally important.
The format, again, because it matters:
If we give [specific user] the ability to [specific action], they will [observable behavior] because [underlying motivation].
Every candidate feature gets exactly one question: does this feature directly test the hypothesis, or does it merely support a feature that does? Only the first category is in scope for the MVP. The second category — supporting infrastructure that doesn't itself produce learning — is the most common place where MVP scope quietly doubles.
The two-axis matrix
Once you have the hypothesis, drop each surviving feature into a 2×2 grid.
The axes
- Impact on the hypothesis: high or low. Does shipping this feature meaningfully change what we learn from the MVP?
- Build effort: high or low. Days, not weeks, of engineering time. Use a relative scale, not a precise estimate.
The quadrants
- High impact / low effort: build first. These are the obvious wins. Your sprint one.
- High impact / high effort: build next, but only after the easy wins are in. Often these are the features that produce the most learning, but they take real time.
- Low impact / low effort: be suspicious. These feel cheap and harmless and they are how scope bloats by 30%. Cut most of them. If a feature is genuinely cheap and you can't think of a learning it produces, that's a signal it's a comfort feature, not a hypothesis feature.
- Low impact / high effort: cut entirely. This is where MVPs go to die. "We should also build [X]" is the phrase that ends quarters early.
The matrix is a forcing function. It makes you defend every feature explicitly against two criteria. Features that can't earn their place on the grid get cut, which is the entire point.
Pressure-test by writing the journey
Once you have your shortlist, write the end-to-end user journey using only those features. Where does the user start? What's the first action? What's success? What's the next session?
If the user can complete the core action end-to-end, your scope is honest. If they can't, you either cut too much or you forgot a load-bearing feature you'd mentally assumed was in scope. Both are common. The journey is what surfaces them.
This is the moment most founders discover they need one more feature they hadn't named — usually something around onboarding, authentication, or post-purchase confirmation. Add it explicitly. Don't let it sneak in as "obviously we need this."
Name the cuts out loud
Document the out-of-scope list in your PRD. Not vaguely. Not as "some features will be deferred." By name.
- "No team accounts in v1. Single-user only."
- "No native mobile apps in v1. Responsive web only."
- "No social login in v1. Email/password only."
- "No exports in v1. View-only data."
- "No admin dashboard in v1. We'll query the DB directly when we need to."
An explicit out-of-scope list is a gift to your engineering team, your designer, and your future self. It is the document that gets pointed at three months later when someone says "wait, I thought this would be included."
The MoSCoW shortcut, if you prefer
Some founders find a flatter framework easier than a 2×2. MoSCoW splits features into Must, Should, Could, Won't.
- Must: the MVP fails without this. Usually 5–8 items.
- Should: important but the MVP can ship without it. Defer to v1.1.
- Could: nice to have. Defer to v2 or never.
- Won't: explicit no. The most important column.
MoSCoW works. The 2×2 matrix produces the same answer with slightly more discipline. Pick the one you'll actually use.
Common prioritization failures
"Everything is a Must"
If your Must column has more than 10 items, you are not prioritizing — you are listing. Force-rank. Cut the bottom half. Re-rank. Cut again. Done when the column hurts.
"It's only a small feature"
Small features compound. Three small features add a sprint. Ten add a month. The cumulative cost is invisible because each individual decision feels harmless.
"Our competitors have it"
Parity is a v2 problem. Your MVP is competing against the user's current behavior, not against established products. The current behavior is usually a spreadsheet, a workaround, or doing nothing. You don't need feature parity to beat a spreadsheet.
"The investor expects to see it"
Investors expect to see a working product that proves a hypothesis. They do not expect to see a feature list. Build the demo around the hypothesis. The investor will follow.
Prioritizing for design instead of learning
If your prioritization is driven by what looks impressive in screenshots, you are building a portfolio piece, not an MVP. Visible features are not the same as valuable features.
What this looks like in practice
A real example from a recent engagement. The founder's initial list had 23 features. After the hypothesis test, 14 survived. After the 2×2 matrix, 7 made the MVP. The journey map surfaced one missing item (post-payment email), bringing it to 8. The build came in at $54K instead of the original $112K projection — for a product that shipped two months earlier and proved the hypothesis decisively.
The cut features didn't disappear. Six of them shipped in v1.1 after the MVP told us which ones the users actually missed. The other nine are still cut, three months later. The users never asked for them.
The features users don't ask for are the features you didn't need to build.
This is the exact prioritization exercise we run inside the MVP Blueprint engagement. The framework above is the framework you'd use. If you want it done with you, that's what the engagement is for.