The phrase "minimum viable product" has been repeated into meaninglessness. In practice most teams read it as a smaller version of the thing we were going to build anyway, which is why so many first releases are simultaneously too thin to be useful and too expensive to have been a test.
The version we hold ourselves to is longer but more useful: build the smallest version capable of proving the biggest assumption.
Start from the assumption, not the roadmap
Every venture rests on a small number of things that must be true. Usually one of them is load-bearing — if it is false, nothing else matters.
For a marketplace it might be that supply will show up before demand. For an operations tool it might be that the people using it will change a workflow they have run for years. For a consumer product it might be that anyone will come back a second time without being reminded.
The useful question is not "what is the smallest product we could ship?" It is "what is the cheapest thing we could build that would tell us whether that assumption holds?" Those two questions produce very different plans.
The test is not always software
Sometimes the fastest way to test an assumption involves building nothing at all. A landing page, a manual service behind a form, twenty structured conversations, a prototype that only works if you tap in exactly the right order — each of these can settle a question that would otherwise cost a quarter of engineering.
- If the assumption is about willingness to pay, you need a price in front of a real buyer, not a feature.
- If it is about willingness to change behaviour, you need someone to actually try changing it, however crudely you support them.
- If it is about whether the thing is technically possible, then and only then are you building software first.
The trap of the impressive demo
The failure we watch for most closely is the version that is small in scope but still large in effort — polished, demo-ready, and carefully arranged so that the risky assumption never gets tested.
If your first build cannot come back with a no, it was not a test. It was a head start on a decision you had already made.
A good early build should be genuinely capable of embarrassing you. That is the property that makes it worth doing.
None of this is an argument for shipping something bad. It is an argument for being precise about what a first version is for. Once the assumption holds, the case for building properly is much easier to make — and you are building on something you actually know.