Minimum refers to scope, not quality. A broken product does not test your hypothesis — it tests whether people tolerate bugs.
10 min read · Level 2
Minimum refers to scope, never to quality — a broken product does not test whether people want the thing, it tests whether they tolerate bugs, and you already know the answer. The deeper discipline is that an MVP without a stated hypothesis is not an MVP, it is just building. If you cannot say in one falsifiable sentence what this would prove or disprove, you will ship it and learn nothing except that launching is hard.
A Minimum Viable Product is the smallest thing you can build that lets a real user get real value, and that teaches you whether your core assumption is right.
It is distinct from a prototype (a mock-up that tests comprehension and desire) and a proof of concept (a narrow build proving something is technically possible).
Because the MVP's purpose is learning, not launching. Every feature you add before you have learned anything is a bet placed before you have seen the cards.
And because 'minimum' is routinely misread as 'rough'. A minimal product that works properly for one workflow teaches you a great deal. A broad product that half-works teaches you that people dislike broken software, which you already knew.
Scheduling for logistics firms. The core assumption: ops managers will switch from a spreadsheet if rota-building drops from three hours to under thirty minutes.
Wrong MVP: vehicle tracking, driver app, invoicing, reporting, mobile, integrations. Six months. Tests nothing in particular, because if it fails you cannot tell which assumption was wrong.
Right MVP: import your driver list, set availability, generate a rota, export to a spreadsheet. Three weeks. One workflow, done properly.
If ten managers use it for four consecutive weeks, the assumption holds and you have earned the right to build more. If they use it once and go back to the spreadsheet, you have learned that in three weeks instead of six months — and the conversation about why is now specific enough to be useful.
First-time founders often build an MVP with no hypothesis attached, so there is no way to interpret the result. If you cannot say in one sentence what this build would prove or disprove, you are not building an MVP — you are just building.
The second mistake: shipping something genuinely broken and concluding the idea failed. Users cannot separate 'I don't want this' from 'this doesn't work'. Neither can you.
One sentence, falsifiable. 'Ops managers will switch if it takes under 30 minutes.' Everything else follows from this.
One path from start to value. Not a product — a path.
Settings, admin, onboarding polish, edge cases, mobile. All of it can wait.
Minimum scope, real quality. The narrow thing must actually work or the test is invalid.
'Ten users complete the workflow four weeks running.' Decide now, or you will rationalise whatever happens.
Four to eight weeks. If it needs six months it is not minimal, and you should cut scope rather than extend.
Once discovery has given you a clear assumption worth testing with a build rather than a conversation.
If the assumption can be tested with a conversation, a landing page or a pre-sale, do that instead. Building is the most expensive way to learn anything.
Before building inventory or warehousing, Zappos' founder photographed shoes in local stores, listed them online, and bought them at retail when an order came in. It was unprofitable by design. It answered the only question that mattered: would people buy shoes online without trying them on?
The cheapest MVP is often a manual process that loses money per transaction. You are buying an answer, not a business model.
The recognisable failure: vehicle tracking, a driver app, invoicing, reporting and integrations all shipped together after six months. When it lands flat, nothing can be learned, because there is no way to tell which of the five assumptions was wrong.
One workflow, done properly, tests one thing. Five features shipped together test nothing you can act on.
Create a free account to read the rest and apply it to your own startup.