Minimum viable product (MVP)
What is a minimum viable product (MVP)?
A minimum viable product, or MVP, is the first working version of a piece of software: it does one clear job for real users and nothing else. The point is not to impress but to test the assumption the project rests on, before the whole budget is spent. What it teaches — who uses it, where they get stuck, what is missing — decides the second version.
Example
A delivery company wants a customer portal. The first list has 14 features: booking, tracking, invoices, claims, reports, an address book, notifications and more. Instead of all of it at once, the first version has three screens — sign in, book, track — and goes out to 40 customers.
Six weeks later the data says something different. 60% of sign-ins are for tracking alone; booking is used by 20 customers; invoices are asked for by three. If the full scope is taken as 100 units of budget, this first version is about 25 of them — and it is what showed that the next stage should bring status notifications rather than an address book. The numbers are illustrative; the value is that the decision about the remaining three quarters is made after watching, not before.
Why it matters for a business
An MVP is not an unfinished product. What goes into it is complete: it works, it keeps data correctly, it is backed up and access is controlled. The scope is minimal, not the quality. The difference shows in operation — unfinished work accumulates repairs, while a deliberately narrow scope simply waits for the next stage.
The gain is threefold: the risk is tested on real people, the specification for stage two rests on observation rather than assumption, and for the right kind of product the first revenue starts earlier. For that to work, the scope is chosen around one assumption and comes with a measure — a KPI agreed in advance that says what will count as success.
On large projects we start with an MVP and build in stages, which is how we deliver web software without the first invoice paying for features nobody asked for.
What to ask
- Which assumption does this version test, and which number will answer it?
- Which real users will have it, and how does it reach them?
- What is deliberately left out of stage one, and when is that revisited?
- Will this code be built on, or is it meant to be thrown away after the test?
- Who collects the feedback, and when is the stage-two decision made?