The MVP is not an ugly version of your product

"Let's ship an MVP" usually means, in practice, "let's build the same thing but worse and in half the time". And that is exactly the misunderstanding that has turned the minimum viable product into an excuse for building without thinking.

An MVP is not a small product. It's an experiment shaped like a product.

What almost every MVP actually tests

They test whether the team is capable of building it. Which, barring surprises, you already knew.

What they don't test is the only thing that matters: whether anyone cares enough to pay, to change a habit, or to leave their current tool. And that question almost never needs code to be answered.

Before building, there are three things you can know without building

• Whether the problem exists outside your head. People already talk about it: in reviews of similar products, in forums, in your competitors' support. In their own words, too, which later serve you for the copy.
• Whether someone already solves it. Almost always yes, even if with a spreadsheet or with a competitor you didn't consider competition. That doesn't invalidate the idea: it tells you what you're really competing against.
• Whether there is measurable demand. Searches, size of communities, number of reviews, downloads. It doesn't prove they will pay you, but it does distinguish between "small market" and "non-existent market".

None of the three requires a line of code. All of them require a couple of days of honest research, which is exactly what people in a hurry skip.

The correct order is boring

1. Write down the assumption that scares you. Not "we want to launch in Q4", but "we believe that X would pay Y for Z". If writing it down doesn't scare you a little, it isn't the critical assumption.
2. Look for whether the answer is already out there. Validating a business idea starts by looking at the data that already exists, not by generating new data.
3. Design the cheapest test that can kill it. A landing page, twenty conversations, an ad, a pre-sale. A good test is one that can go wrong.
4. Decide in advance which result means "no". Without that number written down beforehand, you will always find a way to read the data as a yes.
5. Only then build. And build only what's needed for the next question.

Why this step gets skipped

Because building is comfortable and validating is uncomfortable. Building gives you the feeling of progress and depends only on you; validating depends on people who can tell you your idea isn't interesting. Besides, the serious version of validation is perceived as expensive: a proper market study was historically sold for weeks of work and five figures.

That calculation was reasonable five years ago. Today the mechanical part — demand, competitors, channels, voice of the customer — can be gathered in hours. What stays expensive is continuing to build things nobody asked for.

Conclusion

An MVP is measured not by how little you built, but by how much you learned. If when you finish it you can't say which assumption died and which survived, you didn't launch an MVP: you launched a worse version of your product and gave it a nice name.