What a real MVP includes
"Minimum viable product" has been stretched to mean almost anything. Here's the version that actually earns the name, and the parts teams wrongly cut.
"MVP" has quietly come to mean "the least we could ship." That's not what it was ever supposed to mean. A minimum viable product is the smallest thing that is genuinely viable, able to test whether people want what you built and will act on it. Miss the "viable" and you've just shipped an unfinished product with a flattering name.
Here is what a real one includes, and what it doesn't.
One complete path, done properly
An MVP does one thing all the way through. A user should be able to arrive, do the core job, and reach the outcome without hitting a dead end or a "coming soon." Breadth is the enemy here; depth on a single flow is the whole point. Ten features at fifty percent teach you nothing. One feature at one hundred percent teaches you whether the idea is real.
A real way to say yes
Viability means someone can commit. That usually means the ability to pay, sign up, or otherwise take the action that proves intent. A product people admire but can't act on hasn't tested demand. It has tested politeness. If the point is to learn whether people want it enough to move, the moving has to be possible.
Enough polish to be judged fairly
There's a floor below which feedback becomes noise. If the thing is confusing or visibly broken, users react to the breakage, not the idea. You don't need a beautiful product to learn. You do need one clear and trustworthy enough that when someone declines, they're declining the concept, not the bugs.
A way to see what happened
An MVP you can't measure is a story, not an experiment. You need to see what people did: where they arrived, where they dropped, whether they came back. Without that, you're left guessing, and guessing is exactly what the MVP was meant to replace.
What it leaves out
- Scale. It does not need to handle a thousand users. It needs to handle the ones you can actually get in front of.
- Edge cases. Handle the main path. Note the rest. Don't build for problems you don't have yet.
- Everything on the roadmap. The roadmap is a list of bets. An MVP tests the first one. The others wait for evidence.
The real test
The question an MVP answers is not "does it work?" It's "do people want it enough to act?" Build the smallest thing that can answer that honestly. No less, and, just as importantly, no more.
