"MVP" gets used to mean "version one" or "the cheap version," and that misunderstanding produces MVPs that are either bloated or useless. A minimum viable product is a test: the smallest thing you can build that validates or kills your core assumption about whether people want this. Defining one well is an exercise in ruthless focus on the one thing you need to learn.
Start with the hypothesis
Before scoping features, name the riskiest assumption your product rests on — usually "a specific group of people has a problem painful enough that they will use (and pay for) this specific solution." The MVP exists to test that assumption. Everything in it should serve the test; everything that does not is premature. If you cannot state what the MVP is trying to learn, you are building a small product, not an MVP.
Scope to the core value
Include only what is needed to deliver the one core value and prove the hypothesis. This is harder than it sounds because everything feels essential. The discipline: for each proposed feature, ask whether the central value can be experienced without it. If yes, it waits. An MVP does one thing that matters, well enough to be real.
- Cut every feature not required to deliver the single core value.
- Keep it genuinely usable — 'minimum' constrains scope, not quality; a broken product tests nothing.
- Manual is fine — do things by hand behind the scenes rather than building automation you may never need.
- Instrument it — build in the measurement that will tell you whether the hypothesis held.
The 'viable' matters as much as the 'minimum'
A common failure is stripping so much that the product does not actually deliver value — that is a minimum invalid product, and it tests nothing except users' patience. The core experience has to work well enough that a real user gets real value, or the experiment is contaminated: you will not know whether they rejected the idea or just the broken execution. Cut scope aggressively; cut quality of the core, never.
The output of an MVP is not revenue — it is a validated or invalidated hypothesis. Decide up front what result would tell you to build more, pivot, or stop, and make sure the MVP produces that signal. An MVP that ships but generates no clear learning has failed at its only real job.
A SaaS MVP is an experiment: a stated hypothesis, scope cut to the single core value that tests it, kept genuinely usable, and instrumented to produce clear learning. Define it that way and it does what an MVP is for — telling you fast and cheaply whether to invest more — instead of becoming a small, unfocused product that leaves you no wiser.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.