Minimum refers to scope, not quality. A broken product does not test your hypothesis — it tests whether people tolerate bugs.
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.
Apply this to your own startup in My Full Journey (free account).