“MVP” has quietly become one of the most misused terms in product work. It's supposed to describe the smallest thing that tests a real assumption. Too often, it describes a smaller version of a plan the team had already fully decided on.
Minimum is a discipline, not an apology
“MVP” is often used to excuse a smaller version of an already-decided plan, rather than to test the riskiest assumption directly. That's scope-cutting, not learning, and it usually still takes just as long to build.
A genuine minimum version is designed backwards from the specific uncertainty it needs to resolve, not forwards from the full feature list.
Speed comes from clarity, not shortcuts
Teams that ship fast usually aren't cutting corners. They've simply agreed on what they're trying to learn before writing a line of code. Everything else becomes easier to defer.
What this looks like in practice
A team convinced people want a marketplace could spend three months building listings, payments, messaging and reviews: a “minimum” version of the full vision. Or they could spend a week manually matching the first ten buyers and sellers by hand, no software at all, just to learn whether the matching problem is real and who actually pays for it. The second version teaches more, faster, and it's the one most teams are tempted to skip because it doesn't feel like “building the product” yet.
In plain terms
A Minimum Viable Product isn't a smaller, buggier version of the final product. It's the smallest thing you can put in front of real people to find out if your biggest assumption is actually true. If it doesn't teach you something you didn't already know, it's not a minimum version of anything. It's just a smaller build.