I've watched a hundred founders mis-define "MVP" over the last decade. They've all read the same blog posts and walked away with the definition — minimum viable product, the smallest version of the product you can launch. Technically correct, but operationally useless. By that definition, every lousy version-one of every product is an MVP. An MVP becomes a thing you ship. That's the wrong unit of measurement.
Eric Ries, when he coined the term, made a much more specific point that got lost. An MVP, in the original framing, is an experiment. It's the smallest possible thing you can build to learn one specific thing about whether your business will work. The output is not a product. The output is learning. If your MVP teaches you nothing because you didn't define what you were testing — congratulations, you shipped a product, but not an MVP.
So when a founder says "we're building an MVP," the question that matters is: what are you trying to learn?
Some examples to make this concrete.
If you're trying to learn whether anyone will pay for something, the MVP might be a landing page with a Stripe checkout that returns "sold out, we'll email you" — and you measure how many people clicked through and entered a card. You learned price sensitivity. You did not build a product. Cost: a weekend. Learning value: enormous.
If you're trying to learn whether a workflow is even possible manually, the MVP might be you, personally, doing the workflow by hand for ten customers, with a Notion doc as the "interface." You learned whether the workflow holds up. You learned where the actual pain points are. Cost: two weeks. Learning value: you now know what software you actually need to build instead of what you guessed you needed to build.
If you're trying to learn whether the technical approach scales, the MVP might be a stripped-down end-to-end pipeline with no UI at all, just a CLI and a log file. You learned whether the architecture you sketched on the whiteboard survives contact with reality. Cost: a month. Learning value: you know whether to keep building or pivot before you've sunk a year into the wrong substrate.
Notice that none of these are "your product with features stripped out." They're three different experiments testing three different risks, and they all get called MVPs because the word has been laundered into uselessness.
Here's the operational fix.
Before you start the MVP, write down — on paper, in a Notion doc, on a whiteboard, somewhere — the one riskiest assumption your business depends on. Not two. Not three. The one that, if false, kills the business. Then design the cheapest possible experiment that tests that assumption. That is your MVP. When the experiment is done, you either have evidence the assumption holds (in which case you've found the next-riskiest assumption, and you go again), or you have evidence it doesn't (in which case you pivot or kill the idea before you've spent a year on it).
If you cannot articulate the riskiest assumption — if you find yourself writing "we'll learn whether people like it" or "we'll learn whether the product works" — you haven't actually defined the experiment. You're just building a product and calling it an MVP. That's allowed; you might even succeed. But don't lie to yourself about what you're doing.
The most expensive mistakes I've seen in twenty years of advising founders all share a structure. The founder is convinced of the product. They spend six months building "the MVP," which is in fact a fully-featured version of the thing they always wanted to build. They launch. Nobody bites. They are now broke, and they have learned only one thing: this specific built product, in this specific built form, did not connect with this specific audience. They cannot easily say whether the problem was the product, the audience, the messaging, the pricing, or the channel — because they conflated five experiments into one big launch. So they pivot, which usually means rebuilding most of it, and the cycle repeats. After two pivots most founders run out of runway.
The way to avoid this is to separate the assumptions. Test the audience first — does this audience even exist, can you reach them, do they pay attention? Test the problem second — is the problem real, is it painful enough that they currently pay for, or hack around, a solution? Test the willingness-to-pay third — would they actually swipe a card for what you're proposing? Test the product last — when you build something, does it solve the problem in a way that closes the loop on pay-to-value? Each of these is an MVP. Each one should cost orders of magnitude less than the next. Each one should produce evidence you can write down in a single sentence.
The "build it big, launch it big" approach is not an MVP, it's a bet. Bets sometimes pay off, and there are founders who did exactly this and won — but the reason you remember them is selection bias, not strategy. For every founder who YOLO-built a polished product and got it right on the first try, there are fifty who did the same thing and lost their savings.
Final point: the MVP is not a phase of the product, it's a discipline of the team. Companies that ship MVPs in this experimental sense never really stop. They're always running the next experiment, the next pricing test, the next channel test. The MVP becomes a habit, not a milestone. The companies that don't do this stop running experiments the moment they have a "product," and they stop learning, and they slowly lose to whichever competitor kept the loop going.
If you internalize one thing from this, let it be: the MVP is an experiment, the output is learning, and "what are we trying to learn?" is the question every team-meeting agenda should start with. The rest is engineering.