MVP Explained for Business Leaders: What a Minimum Viable Product Is and Is Not

A minimum viable product gives you a working version with which to test the product's core assumptions. Its scope should follow what you need to learn.

It is not an excuse for poor quality, a half-designed interface or a backlog containing everything the team postponed.

An MVP is a small enough live product to test an important business assumption with real behaviour, while still being viable for the users and context in which it is released.

The emphasis should be on learning.

The leadership question is:

What is the smallest responsible investment that can generate the evidence we need before committing more capital?

MVP thinking begins before software

A team should not jump directly from idea to MVP build.

First understand:

• who has the problem;
• how they solve it today;
• how painful or valuable the problem is;
• what assumptions must be true for the opportunity to work;
• which assumption carries the most risk.

GOV.UK's service guidance captures a useful sequence: discovery is for understanding the problem and deciding whether it is worth progressing; alpha is for prototyping and testing different solution approaches; beta is where a selected idea begins being built for real.

Commercial products do not have to copy government delivery terminology, but the principle is sound: learn before you scale the build.

Minimum does not mean incomplete

Imagine a marketplace for specialist equipment.

A bad “MVP” might include:

• user registration;
• listings;
• messaging;
• payments;
• delivery;
• ratings;
• admin;

all implemented poorly because the team tried to build the future platform in six weeks.

A more useful first live product might test only the riskiest assumption:

Will enough verified buyers transact with a curated group of sellers if matching and fulfilment are partially manual behind the scenes?

The front-stage product can be viable while the back-stage operation remains deliberately manual.

That generates evidence about demand before automating everything.

Viable for whom?

“Viable” depends on context.

A consumer social product can tolerate different constraints from:

• medical software;
• financial workflows;
• employee payroll;
• enterprise procurement;
• a safety-critical operational system.

For a B2B product, viability may require:

• access control;
• audit logs;
• data export;
• security review;
• support process;
• service reliability.

Those are not optional simply because the product is early.

Minimum scope should reduce unnecessary feature breadth, not essential responsibility.

Identify the assumption, then choose the test

Common product assumptions fall into five groups.

1. Problem

Do users actually experience the problem often and strongly enough?

Test with:

• interviews;
• observation;
• existing behavioural data;
• support evidence;
• workflow analysis.

You may not need software yet.

2. Desirability

Will users choose the proposed solution?

Test with:

• landing pages;
• waitlists;
• concierge service;
• clickable prototypes;
• sales conversations;
• pre-orders where appropriate and transparent.

3. Usability

Can people understand and complete the core task?

Test with prototypes.

GOV.UK's prototyping guidance recommends creating and testing prototypes before committing to production, precisely because they let teams explore design ideas at lower risk.

4. Feasibility

Can the difficult technical part work?

Test with a proof of concept, technical spike or integration experiment.

5. Viability

Can the product produce sustainable value for the business?

Test with:

• willingness to pay;
• acquisition economics;
• operating cost;
• retention;
• transaction margin;
• sales cycle;
• support burden.

An MVP becomes especially useful when several of these need to be tested with real use over time.

What an MVP must contain

A good MVP normally needs:

One clear user

Do not build simultaneously for consumers, enterprise administrators, partners and every theoretical future segment.

One valuable job

Define the core outcome the user is trying to achieve.

A complete core journey

The user should be able to reach the promised outcome, even if many secondary features are absent.

Measurement

The product should capture the evidence required to assess the hypothesis.

Operational support

Someone must handle failures, questions and exceptions.

Security and privacy proportional to the context

Early-stage does not mean exempt from basic safeguards.

What to leave out

Good MVP scope aggressively removes features that do not test the main risk.

Candidates often include:

• advanced personalisation;
• complex roles not required by early users;
• full automation of low-volume back-office tasks;
• edge-case integrations;
• sophisticated analytics for customers;
• cosmetic settings;
• broad geography;
• multiple pricing models;
• native apps when responsive web can test the same behaviour.

The criterion is not “nice to have”.

Ask:

Does this feature materially help us test the central hypothesis or safely deliver the core outcome?

If not, defer it.

The concierge MVP

Some of the best early products use humans behind the scenes.

Suppose the long-term vision is an AI-assisted procurement platform.

Instead of building automated supplier matching, pricing intelligence, workflow orchestration and document generation immediately, the team could:

• collect buyer requirements through a simple interface;
• manually match suppliers;
• use existing tools to prepare comparisons;
• deliver the result through the product;
• measure whether buyers value the outcome.

If customers do not value the result, the team has learned cheaply.

If they do, automation can target the parts proven to matter.

MVP quality still matters

The core path should be trustworthy.

Users should not have to excuse:

• broken forms;
• lost data;
• insecure authentication;
• inaccessible critical interactions;
• misleading payment flows;
• obvious errors.

The product can be narrow and still professionally implemented.

There is a difference between minimum scope and minimum competence.

Define success before release

Write the hypothesis explicitly.

Example:

We believe independent restaurants will place repeat wholesale orders through a digital storefront if it reduces ordering time and provides reliable availability.

Then define evidence:

• 30 target restaurants onboarded;
• meaningful activation rate;
• first order completed;
• repeat order within an agreed period;
• acceptable support effort;
• acceptable gross margin.

The exact thresholds depend on the business. The important part is deciding what would change the investment decision.

Measure behaviour, not compliments

Early users are often polite.

“I love the idea” is weak evidence.

Stronger evidence includes:

• completed task;
• payment;
• repeat use;
• referral;
• time saved;
• workflow replaced;
• user returning without prompting.

Behaviour has friction. That makes it useful evidence.

An MVP should be designed to answer a decision

At the end of the first release period, leadership should be able to choose:

• Scale: evidence is strong enough to invest more.
• Improve: the problem is real but the solution needs adjustment.
• Narrow: one segment or use case is much stronger than the rest.
• Pivot: a different solution appears more valuable.
• Stop: evidence does not justify further investment.

If the team cannot imagine stopping, it is probably not running an experiment. It is running a small first phase of a project whose conclusion was decided in advance.

MVP versus version one

A version-one product often means the first planned production release of a known proposition.

An MVP has a stronger learning purpose.

The distinction matters because a team may legitimately need a broad version-one release when:

• the business case is already proven;
• users are migrating from an existing product;
• contractual requirements define minimum functionality;
• operational continuity matters more than proposition validation.

Do not force every software delivery into MVP language.

The architecture should preserve learning speed

For an MVP, optimise architecture for:

• safe change;
• observability;
• reliable core flows;
• manageable cost;
• ability to replace assumptions.

Avoid premature complexity such as:

• microservices for a tiny team without a scaling need;
• elaborate event infrastructure before event volume exists;
• custom infrastructure where managed services suffice;
• abstractions for hypothetical future markets.

At the same time, do not create an unmaintainable prototype and call it production.

The right architecture supports the current experiment without making the next sensible step unnecessarily expensive.

A practical MVP brief

Before development, document:

This makes “MVP” a governance tool rather than a negotiation over feature count.

The practical takeaway

A good MVP is small because the question is focused, not because the team is careless.

Start with the uncertainty. Use cheaper research or prototypes where they can answer it. Build a live product only when real use is the evidence you need. Then measure behaviour strongly enough that leadership can make the next investment decision with less uncertainty than before.

Further reading

• GOV.UK Service Manual, How the discovery phase works: https://www.gov.uk/service-manual/agile-delivery/how-the-discovery-phase-works
• GOV.UK Service Manual, How the alpha phase works: https://www.gov.uk/service-manual/agile-delivery/how-the-alpha-phase-works
• GOV.UK Service Manual, Making prototypes: https://www.gov.uk/service-manual/design/making-prototypes

Abrasim's Product & Technology work uses MVP thinking as an investment discipline: isolate the risky assumption, choose the cheapest credible test, and build only as much production product as the next decision requires.