"MVP" has drifted from meaning something specific to meaning "version one, but smaller." That drift is expensive, because a genuinely useful MVP boundary isn't about size — it's about what question it has to answer, and how honestly it can answer it.
Start from the decision, not the feature list
Before scoping anything, we ask: what decision does this MVP need to inform, and what result would make us not build the rest of it? If nobody can answer that, the project isn't ready to be scoped — it's still in discovery, no matter how much pressure there is to start building.
A genuine MVP boundary is the smallest thing that lets real users make the decision the product depends on — not the smallest thing that's technically impressive, and not a checklist of every feature a competitor has.
The two ways MVPs usually fail
- Too small to judge: a prototype so stripped-down that a bad result doesn't actually tell you anything, because real users never encountered the thing that was supposed to matter.
- Too big to ship: scope that quietly expands to 'basically the whole product,' which turns a two-month decision into a year-long bet nobody explicitly signed up for.
A boundary that holds
The scoping exercise that works best for us is writing the MVP boundary as a sentence a stakeholder can't quietly renegotiate mid-build: "We will know this works if [specific user group] does [specific action] at [a stated rate], measured over [a stated window]." Everything that doesn't serve that sentence gets a place on the roadmap, not in the build.
It feels restrictive while you're writing it and looks obviously correct six weeks later, once the build is underway and the temptation to add "just one more thing" shows up — which it always does.
What comes after the answer
The other half of a real MVP process is committing, in advance, to what happens for each possible result — not just the good one. What do you build next if the metric clears the bar? What do you change if it doesn't? Teams that skip this step tend to keep building regardless of what the data said, because nobody agreed in advance on what 'no' would look like.