Minimum viable product

A minimum viable product (MVP) is the smallest thing you can build and put in front of real users to test the riskiest assumption behind an idea. It is not a prototype, and it is not version one with some of the features removed.

The distinction is about purpose. A prototype answers whether something can be built or how it should look, while an MVP answers whether anybody outside the building wants it.

Cutting features from a planned release is not the same move either. That gives you a weaker version of a product nobody has validated, which is a slower way to learn the same bad news.

Key takeaways

• An MVP exists to test one assumption, not to launch a smaller product.
• If you cannot name the assumption, what you are building is not an MVP.
• Manual delivery behind a simple screen often beats writing software first.
• Agree the decision rule before the build, not after you see the result.

How it works

A minimum viable product works backwards from risk. You name the assumption that would sink the idea if it proved false, choose the cheapest honest test of it, agree in advance what result would change your mind, then build only what that test requires.

Naming the risk is the hard part. Most teams default to feasibility because engineers are in the room, when the assumption that actually kills products is usually demand.

The decision rule matters as much as the build. Write down in advance what result would make you stop — otherwise any outcome reads as encouragement, and the test has cost you money without buying information.

Viable is doing real work in that phrase. The slice has to be small, but whatever you ship must function properly, because users cannot tell a deliberate gap from a broken product — and they will judge you on the second.

Government service manuals use the phrase literally. The New South Wales digital service manual defines the minimum viable product as the quickest and simplest version of a service, carrying just enough features to meet basic user needs.

Alpha is where the risk gets named. The UK government’s service manual tells alpha teams to prototype only the parts they expect to be hardest, which it describes as doing the minimum you need to test your riskiest assumptions.

That same manual tells alpha teams to expect to throw their code away, which is the cleanest line anyone draws between a prototype and a first real release.

Method matters less than honesty about the result. Design thinking and human-centered design both push teams towards the user early, which is exactly where an MVP has to point.

Examples

Good examples share one trait: the build was deliberately too small to be proud of. Three patterns cover most of what teams actually ship as a first test.

The concierge test replaces software with people. A logistics startup takes orders through a form and dispatches them by hand for six weeks, which proves demand and exposes the real process before anybody writes a scheduler.

The single-flow build narrows scope instead of quality. A lender launches one loan product, in one region, with manual underwriting behind a clean application screen, then automates only the steps that volume justifies.

The pre-sale tests willingness to pay rather than interest. Hardware campaigns on crowdfunding platforms have worked this way since the early 2010s, taking priced orders against a specification before a production run is committed.

Each pattern buys the same thing — evidence about one assumption, early enough to act on. What they do not buy is certainty about the rest of the plan, which is why a single test rarely ends the argument.

Internal teams inside large firms use the same patterns under different names. A pilot in one region, one branch or one client account is an MVP whenever it is scoped to settle a question rather than to prove a point.

A startup inside an accelerator or a startup incubator is usually pushed down this path by its funding cycle, which is one of the quieter benefits of the model.

Plenty of first builds are not built in house at all. Agile outsourcing suits the work well, because an MVP wants a small team, short cycles and a hard stop, which is exactly what a scoped external squad can give you.

Related terms

• Agile outsourcing: running iterative delivery with an external team, a common way MVPs get built.
• Agile release train: a scaled delivery cadence for many teams, which sits well past the MVP stage.
• Business model canvas: the one-page view that surfaces which assumption is riskiest.
• Design thinking: a problem-framing method that decides what is worth testing.
• Startup: the setting the term came from, though large firms now use it routinely.

FAQ

Is an MVP the same as a prototype?

No. A prototype tests whether something can be built or how it should look, while an MVP goes to real users and tests whether they want it. The audience is the difference, not the amount of code.

How small is minimum?

Small enough to answer one question and no smaller. If you cannot say which assumption the build settles, what you have is a first release with an optimistic name.

Does an MVP have to be software?

No. A service run by hand behind a simple screen counts — it is often the fastest way to find out whether demand exists at all.

Who decides when to stop?

Whoever owns the decision the test informs, named before the build starts. Settling that question afterwards is how teams talk themselves into shipping anyway, which is the outcome the whole exercise was meant to prevent.

What happens after the MVP?

You kill the idea, change it, or start building the real thing with that assumption settled. All three count as success, because each one replaces a guess with evidence.

Find delivery partners who can build and staff a first release across Outsource Accelerator before you commit a full team.