Treat an MVP, or minimum viable product, as an experiment with a specific question attached. Calling it a cheap version of your product misses the job it has to do. The only thing that makes it minimum is that everything not needed to answer that question has been left out.
Start with the belief that could make the product fail
Every product rests on one belief that, if wrong, makes the rest irrelevant. Usually it is some form of "people with this problem will change what they currently do in order to use this." Write that sentence down before anything is designed. If you cannot, you are not ready to build.
This matters because the rest of the work depends on that belief. Design, engineering and budget all follow from it. When the belief is vague, the first version cannot tell you much. When it is written down clearly, the MVP has something specific to test.
Build the smallest thing that can give you a clear no
The test is not how little you can build. The test is whether what you build can prove the assumption wrong. A landing page can validate interest. It cannot validate whether people will complete a complex workflow, and pretending otherwise wastes the round you raised on the strength of it.
That is why the smallest version still has to reach the real question. If the assumption is about completing a complex workflow, the MVP has to test that workflow. If the assumption is only about interest, a landing page may be enough.
Put it in front of real users before you trust it
Internal demos validate that your team understands the idea. That was never in doubt. Put the MVP in front of people who have the problem, who did not sit in the planning meetings, and who have no reason to be kind about it.
A demo can make the idea look understood inside the team. Real users show whether people with the problem will actually respond to the thing you built.
Agree what failure means before the data arrives
Agree the threshold before you see the data. If fewer than a stated proportion of people complete the core task, the assumption was wrong and you change direction. Teams that skip this step always find a way to read the numbers as encouraging.
The threshold gives the result its meaning. Without it, the same numbers can be made to sound positive after the fact. With it, the team knows what the result says about the assumption.
Build the small version properly
The common advice is that an MVP should be disposable. The successful ones are never thrown away, they are extended under pressure. Build the small thing properly. It costs very little more and it saves the rewrite that otherwise arrives six months later at the worst possible moment.
Use an MVP to learn sooner, and to spend the rest of the budget on something you now have evidence for.
