Minimum Viable Product: Build the Smallest Honest Test of Value

A team removes reporting, administration, integrations, and most failure handling from a proposed product. The remaining workflow is small enough to ship.

It is not yet an MVP.

The release may still be unable to answer the question that justified it. A user might complete a demo while the team learns nothing about real value, repeat use, operating burden, or willingness to change behaviour.

Minimum scope matters only when the result remains an honest test.

For this article, an MVP is the smallest responsible version that lets a defined group attempt a consequential behaviour and gives the team evidence for a named decision.

Eric Ries’s current site describes an MVP as the simplest product version that begins learning with real users before a large commitment.

That is Ries’s practitioner framing, not empirical proof that the method works in every context. The operating test in this article makes the learning claim more specific.

The label is broader elsewhere. A five-startup study classified landing pages, paper prototypes, mockups, concierge services, and single-feature products as MVPs.

This article deliberately uses MVP for a test that exposes enough of the real value path and operating burden to support a product commitment. Earlier artefacts remain useful, but they cannot answer the same questions.

The word “responsible” carries weight. Security, accessibility, data handling, recovery, and truthful representation do not become optional because a product is early.

Start with the decision the MVP must change

“Validate the idea” hides several different decisions.

The team may need to decide whether to:

• invest in a production capability;
• narrow the customer or use case;
• replace a manual service with software;
• change the value proposition or commercial model;
• resolve a technical or operating uncertainty;
• stop the work.

Write one decision before discussing features:

We will use this release to decide whether [defined group] can reach [meaningful outcome] through [proposed mechanism] under [bounded conditions], and whether that warrants [next commitment].

This sentence exposes an MVP with no consequence. If every possible result leads to the same roadmap, the release is theatre rather than an experiment.

Use assumption mapping when the proposed product rests on several untested beliefs.

The MVP should target the assumption that can change the commitment, not the one that is easiest to instrument.

Define viability before minimum

Teams often negotiate “minimum” as a list of features. A stronger discussion begins with the conditions that make the test interpretable.

For one value path, define four forms of viability.

Behaviour viability

Can the intended person begin and complete the behaviour being tested in a realistic situation?

A clickable path may be enough to study comprehension. It is not enough to test whether a finance operator will rely on the result during a real approval.

Outcome viability

Can the behaviour produce an outcome the user can recognise and judge?

“The workflow ran” is an internal event. “The approver received a decision-ready request with its evidence intact” is closer to user value.

Operating viability

Can the team deliver, support, observe, and recover the bounded service without hiding an unsustainable dependency?

Manual work is allowed. Invisible work with no owner, limit, or record makes the test difficult to interpret.

Decision viability

Will the available evidence distinguish the plausible next choices?

If the release cannot tell a weak proposition from a poor implementation, or genuine value from intensive staff rescue, it may produce activity without a decision.

These four forms are an editorial synthesis, not a published industry standard. Their purpose is to stop “viable” from meaning merely deployable.

Match the artefact to the exposure you need

A sketch, interview, concept, prototype, pilot, and MVP can all reduce uncertainty. They do so through different exposures.

The GOV.UK Service Manual describes prototypes as ways to explore and test designs before committing to build. Unsuccessful versions can be discarded.

It also warns that prototype code may not meet live security, performance, or quality requirements and should not simply be copied into production.

That guidance is written for UK public services. The useful distinction transfers: realism of appearance does not make an artefact safe or ready for consequential use.

A systematic mapping and multi-case study characterises prototypes by purpose, scope, medium, method of use, and exploration strategy.

The model drew on 33 primary studies, a focus group at one company, and practitioner interviews at 11 other startups.

The startup cases were convenience-sampled. The model is useful vocabulary for describing a prototype, not evidence that one prototype type produces better product outcomes.

Use a prototype when the question concerns a representation of the experience. Use concept validation when the decision is whether a proposed response deserves the next bounded commitment.

In the narrower sense used here, choose an MVP when people must encounter enough of the actual value path and operating burden for their behaviour to answer the product question.

A pilot describes the release boundary: selected participants, conditions, support, time, and exposure. An MVP describes what is being made viable enough to learn from. A release can be both.

Choose one end-to-end value slice

A small feature is not necessarily a small product test.

Imagine a supplier-onboarding product. Shipping only the form builder tests whether administrators can create a form. It does not test whether a supplier can submit evidence and an approver can make a defensible decision.

The useful slice crosses the outcome:

eligible person enters a real situation
→ attempts the proposed behaviour
→ receives a usable result
→ downstream actor can act on it
→ team observes value, failure, and intervention

This may require fewer configuration options but more of the path around them. Identity, status, notification, recovery, and an audit trail can be part of the minimum when the outcome depends on them.

Cut variation before cutting the value path. A bounded customer type, input format, integration, or operating condition often reduces scope more honestly than removing the end of the journey.

Name exclusions plainly. “Only invoices in one currency with a named approver” is a testable boundary. “Basic invoicing” invites every reader to imagine a different product.

Build an assumption stack, then select the test

One release can expose several assumptions, but it should not pretend to resolve them all.

Map the stack:

• situation: the problem occurs under the stated conditions;
• behaviour: the intended person will attempt a different way of working;
• value: the result improves something that matters;
• trust: people can judge and rely on the result appropriately;
• feasibility: the mechanism can work under the bounded conditions;
• operability: the organisation can deliver and recover the service;
• economics: the value and cost could support the intended model.

For each assumption, state what the MVP can observe and what remains outside its reach.

A concierge service may test behaviour and value while saying little about automation cost. A single-tenant implementation may expose workflow failure while saying little about multi-tenant operations.

This is not a flaw if the boundary is explicit. It becomes a flaw when a positive result is reported as proof of the entire business.

Treat minimum quality as a test condition

An MVP does not need the completeness, scale, or polish of a mature product. It does need enough quality for failure to mean what the team thinks it means.

If participants abandon because the product is inaccessible, slow, unsafe, confusing, or unreliable, the team has not necessarily disproved the value proposition. It may only have tested its own neglect.

Define non-negotiable quality around the decision:

• protection appropriate to the data and consequence;
• access for the people included in the test;
• clear product states and known limitations;
• recovery from the failures likely in the bounded path;
• evidence that distinguishes user error, system error, and operating intervention;
• support that does not silently complete the job for the user.

Minimum features do not mean minimum responsibility.

The exact obligations depend on the product, users, jurisdiction, and potential harm. An internal note-taking aid and a clinical decision tool cannot share a generic MVP threshold.

Make manual work visible

Manual delivery can be a deliberate way to learn before automating uncertain work.

The danger is not manual work itself. It is allowing staff effort to make the proposition appear more capable, reliable, or economical than it is.

Create an intervention ledger:

• what triggered the intervention;
• who performed it and with which expertise;
• whether the user could see the boundary;
• time and delay introduced;
• error or judgement involved;
• whether the work would recur;
• what the result would have been without it.

Some interventions are part of the intended service. Others are temporary scaffolding. A third group reveals product capability that has not yet been built.

Do not total all manual minutes into one cost and call it learning. Classify the work so the next product decision can distinguish service design, automation, support, and product failure.

The five-startup study found that MVPs were used for learning, product design, communication, and cost-conscious development.

All five cases were small, still developing their products, and seeking seed funding. The qualitative study does not establish a universal process.

It does support a practical warning: the same artefact can serve several audiences, and those purposes can become confused.

An investor demonstration, a team-alignment prototype, and a customer-value test should not inherit one another’s claims without evidence.

Write the evidence contract before release

Feedback is not an evidence plan.

Define:

• eligible population: who can reasonably encounter the value path;
• exposure: which situation brings them to it;
• behaviour: what they must attempt or change;
• outcome: what useful result should become observable;
• counterevidence: what could look positive while value is absent;
• intervention: which staff or system help must be recorded;
• window: when the behaviour and outcome can reasonably occur;
• decision rule: which finding would continue, narrow, redesign, or stop the investment.

Include qualitative evidence where meaning, trust, or consequence cannot be inferred from events. Include telemetry where memory or a small sample cannot establish what happened across the release.

Do not choose a target number because an article calls it a benchmark. Set a threshold from the decision, baseline, exposure, expected variation, and cost of error.

The contract should also name confounders. A staffed onboarding call, free price, executive mandate, or selected enthusiast may be appropriate for the test, but each changes what behaviour can establish.

Bound the release and its failure

An MVP is easier to operate responsibly when exposure is deliberate.

Specify:

• eligible participants and excluded cases;
• permitted data and decisions;
• support ownership and response path;
• monitoring and known blind spots;
• rollback, recovery, or manual fallback;
• conditions that pause the test;
• what participants are told about limitations;
• how learning and closure will be communicated.

This is not a miniature launch plan. It is the boundary that keeps evidence and consequence proportionate.

If the team cannot observe a dangerous failure or recover a critical state, reduce the exposure before reducing the safeguard.

The useful unit of speed is the full path from decision to interpretable evidence, including recovery and waiting.

A hypothetical MVP decision

Consider a fictional product that helps operations teams approve new suppliers.

The original scope includes form configuration, policy rules, document extraction, risk scoring, integrations, reminders, dashboards, and a supplier portal.

The decision is narrower: should the company invest in a capability that assembles a decision-ready approval packet for one type of low-risk supplier?

The MVP supports one policy template, one document set, a named approver, visible missing evidence, and a final approval record. Staff manually check document classification behind the scenes.

The product does not claim automated risk assessment. Participants can see when a specialist has reviewed a document. Every intervention is recorded.

The evidence contract looks beyond packet submission. It asks whether eligible suppliers can provide the required evidence, whether approvers can reach a decision, which gaps require rescue, and whether the record is trusted.

A positive result would permit a larger test of document classification and operating cost. A negative result caused by unclear supplier evidence would return the team to the workflow design.

The example is fictional and makes no performance claim. Its purpose is to show how a smaller customer boundary can preserve an end-to-end value test.

An MVP brief

Before building, record:

1. Decision: the next commitment this release can change.
2. Population: the people and situations the result may speak about.
3. Value path: the consequential behaviour and recognisable outcome.
4. Assumption: the belief most capable of changing the decision.
5. Boundary: included variation, explicit exclusions, and exposure.
6. Quality: safety, access, clarity, recovery, and observability required for an honest test.
7. Manual work: intended service, temporary scaffolding, and hidden product gap.
8. Evidence: behaviour, outcome, counterevidence, intervention, window, and confounders.
9. Decision rule: continue, narrow, redesign, or stop.
10. Closure: what participants and the organisation will be told afterward.

An MVP is not the cheapest object a team can call a product. It is a deliberately bounded encounter with value, consequence, and uncertainty.

Make the scope small. Keep the test honest.

Sources

• Eric Ries: The Lean Startup and minimum viable product
• Making prototypes, GOV.UK Service Manual
• Minimum Viable Product or Multiple Facet Product? The Role of MVP in Software Startups
• An empirically based model of software prototyping

Read next

Startup Velocity: Shorten the Path from Decision to Evidence follows the whole loop through delivery, exposure, recovery, interpretation, and the next decision.