The doctrine of the minimum viable product has saved countless founders from the opposite mistake, building for years in secret and launching something elaborate that nobody wanted. But the doctrine has a failure mode of its own that gets far less attention, which is the product stripped so far past minimal that it is no longer viable at all, a version so thin that it gives no one a genuine reason to use it and therefore teaches the founder nothing about whether the real idea works. Founders who absorb minimum without understanding viable end up launching something that fails not because the idea was wrong but because they never built enough of it to find out.
The confusion is in the word viable, which the enthusiasm for minimal tends to erase. An MVP is supposed to be the smallest version that still delivers real value to a real user, small enough to build fast but complete enough to actually work as a solution to the problem it targets. Strip below that threshold and you have not built a lean version of your product; you have built something that does not do the job, and when users do not adopt it, you learn nothing, because their rejection tells you only that this broken fragment was not worth using, not whether your actual idea would have been. The over-minimal MVP is a test that cannot return a meaningful result.
Minimal is not the goal, learning is
The point of an MVP was never to build the least possible thing for its own sake; it was to learn whether the idea works with the least possible investment, and those are different objectives that the culture of minimal often conflates. Minimising the build is only useful insofar as it still produces a real answer, and a build minimised to the point where it cannot produce a real answer has optimised the wrong variable, saving effort at the cost of the very knowledge the exercise existed to gain. A founder chasing minimal for its own sake can proudly ship something tiny and fast and completely uninformative.
Reframing the goal as learning rather than minimising changes where you draw the line. The question stops being how little can I build and becomes what is the least I can build that still gives a real user a real reason to use it and therefore gives me a real signal about whether this works. That threshold is often higher than the minimal enthusiasts suggest, because a genuine reason to use something usually requires the product to actually solve the problem at least once, in at least one complete path, well enough that a user would choose it. Below that, you are not testing your idea; you are testing a fragment nobody asked for.
What the minimum actually needs
A viable minimum has a specific property: it does one real thing completely, rather than many things partially. The common over-minimal mistake is to include shallow versions of every planned feature, producing a product that gestures at the full vision but does nothing well enough to be genuinely useful, which pleases no one and validates nothing. The better minimum picks the single most important thing the product is for and does that one thing properly, all the way through, so that at least one kind of user gets real value from at least one real use, and the founder gets a clean signal from their response.
An over-minimal MVP is a test that cannot return a meaningful result. Rejection tells you only that this fragment was not worth using, never whether your actual idea would have been.
This is why depth in one thing beats breadth across many for an early product. A tool that solves one real problem completely can win a user and teach you that the core idea has legs, while a tool that half-solves five problems wins no one and teaches you nothing, even though the second sounds more like the full product you eventually want. The discipline is to resist spreading the minimal build across the whole vision and instead concentrate it on the one path that matters most, accepting a narrow product that works over a broad one that does not. Narrow and real beats wide and hollow every time at this stage.
Build enough to get a real answer
The practical guidance is to calibrate the minimum by the answer you need rather than by an abstract ideal of leanness: build enough that a real user, using the product for real, would give you an honest signal about whether the idea works, and no more. Sometimes that threshold is genuinely low and a very small build suffices; sometimes the nature of the problem means the minimum useful version is larger than the minimal doctrine would suggest, and honouring that reality is not a betrayal of the lean idea but a correct application of it. The right size of an MVP is set by what it takes to learn, not by a preference for small.
For founders in a specific market, this calibration matters because the bar for a real reason to use something is set by what your particular users actually need, and a product that would be viable for one audience may be too thin for another, which only direct knowledge of your users can tell you. The core correction to the minimal doctrine is simple: keep the build as small as you can while keeping it viable, and let learning rather than minimalism decide where that line falls. Ship the smallest thing that still works well enough to give you a real answer, and you get the lean advantage without the trap of testing a fragment that was never going to tell you anything.