"Minimum viable product (MVP)" might be the most misused term in software. Ask five people to define it and you'll get five different products: a rough sketch, a stripped-down version of the "real" thing, a pitch deck with a login screen attached, a fully-featured app built too fast to trust. Somewhere in that confusion, the actual point of the term got lost.
Where the term came from
The idea was never about building something small for its own sake. It was about building something real enough to learn from, without spending the time or money it takes to learn the wrong lesson slowly. The word "minimum" was never the point. The word "viable" was.
What it became
Somewhere along the way, "MVP" started meaning whatever was convenient for whoever was saying it. To an agency quoting a project, it means the cheapest version they can justify. To a founder prepping for investors, it means whatever isn't embarrassing to demo. To an engineer, it sometimes just means "the thing before the real thing", a placeholder everyone quietly agrees to rebuild later.
None of these match the original intent, and the mismatch is expensive. Aim for "cheapest" and you build something too thin to learn anything real from. Aim for "not embarrassing" and you build something so padded with polish it stops being minimal at all and takes three times as long to find out if anyone wants it.
What getting it wrong actually costs
The cost isn't always visible right away, which is what makes the mistake so common. A team scopes a "cheapest possible" version, ships it, and gets a trickle of signups that neither confirms nor denies anything, because the version that shipped was too thin to represent what the product is actually for. Or the opposite happens: a team builds something impressively complete, spends four months and a real budget on it, and only then discovers the one assumption that mattered was never tested, because it was buried under a dozen features nobody needed yet to find out.
Both of these get called "the MVP" afterward, in the post-mortem. Neither one was ever built to answer a specific question, which is the only thing that separates a real first version from an expensive guess.
Finding the question you're actually unsure about
Most founders can describe their product fluently and struggle, when pushed, to name the one thing they don't already believe is true. That's usually because the real uncertainty is uncomfortable to say out loud , not "will people like the design" but "will anyone actually change their existing behaviour for this," or "will this work fast enough to be worth the switching cost," or "is the person I think has this problem the person who'll actually pay to solve it." The comfortable questions get answered by a demo. The uncomfortable ones are the only ones worth building something real to find out.
A useful test: if you already know what the answer will be, it's not the right question to build around. Build around the one where you'd genuinely be surprised either way.
An MVP is the smallest version of a product that a real person can use, for the actual reason they'd use it, in a way that produces a real answer to the thing you're genuinely unsure about.
Break that down and every word is doing work. "Smallest" doesn't mean shallow, it means nothing unnecessary, which is a much higher bar than it sounds. "Real person" doesn't mean a friend humoring you over coffee. "Actual reason" means the core job the product exists to do, not a guided demo flow that skips the hard parts. And "the thing you're genuinely unsure about" is the part most teams skip defining entirely, which is exactly why so many MVPs answer no question at all — they just exist, technically finished, and nobody learns anything from them.
If you can't say what question your MVP is supposed to answer, you don't have an MVP yet. You have a smaller guess.
What happens to it once the question is answered
One more misconception worth clearing up: a real first version isn't disposable. The instinct to treat it as a throwaway prototype — something to be discarded the moment it's answered its question — comes from the same confusion that made "MVP" mean "unfinished" in the first place. If it was built properly, on a foundation sized honestly for what it needed to prove, the parts that turned out to matter don't get thrown away. They get built on. The parts that don't matter — because the answer to the real question changed the plan — get cut without much loss, because they were never the point. A first version built on a rushed, thin foundation forces a full rebuild regardless of what the answer turns out to be. A first version built properly only rebuilds the parts the answer actually changed.
That distinction is worth more than almost anything else in this conversation, because it's the difference between an MVP that was money well spent and one that has to be paid for twice — once to build it, and again to build the real thing after throwing it away entirely.
The objection worth taking seriously
"Won't a smaller product make a worse first impression?" is a fair question, and the answer depends entirely on who's forming the impression. If it's an investor deciding whether to fund the next stage, a thin but honest first version genuinely can look underwhelming next to something more polished , that's a real trade-off, not an imaginary one. If it's a real user deciding whether to keep using something that solves their actual problem, polish matters far less than whether the core job gets done well. Knowing which audience the first version is actually for changes the entire calculus, which circles back to the same point from the start: define the question before deciding how much to finish the answer needs.
