Define Your MVP by What You Need to Learn

A team plans a booking platform with customer accounts, payments, scheduling, messaging and reporting. To create an MVP, it removes reporting and reduces the account features. The result is cheaper, but the central uncertainty may remain untouched: will customers trust this business enough to book the service online?

Feature subtraction is not a test strategy. Before deciding what to remove, establish what the business needs to learn.

The Lean Startup methodology positions the MVP within a cycle of building, measuring and learning. Its practical implication is that the product should serve an evidence-gathering purpose. Shipping something small is useful only when its use can inform a decision.

An established SME may be testing a new customer portal, a subscription service or an internal product. The relevant uncertainty could concern demand, usability, operational feasibility or the economics of delivery. These require different tests.

Choose the uncertainty that could most seriously undermine the investment. Resolving a minor design preference while leaving the service’s commercial premise untested is a poor use of an early release.

“Customers will like the portal” is too broad. It does not define which customers, what they will do or what response would change the plan.

A more useful assumption might be: customers who currently request repeat orders by phone will be willing and able to submit a correct repeat order through a self-service page. That statement identifies a group, a behaviour and a task. It can be investigated.

The next step is to define what the evidence must show. Choose the criteria before examining the result. For a small early test, the business may need qualitative understanding rather than a statistically precise conversion estimate. Be explicit about the decision the evidence can support.

The teaching material on hypothesis-driven entrepreneurship uses explicit assumptions and experiments to guide venture decisions. In practice, a short test brief should answer four questions:

• Which assumption are we investigating?

• Which people or operating conditions are relevant?

• What behaviour or outcome will we observe?

• What would lead us to continue, change direction or stop?

Keep the result open to disagreement. If every possible response can be described as validation, the test has not been designed to challenge the idea.

Also distinguish interest from commitment. A positive interview response can reveal a need, but it does not establish willingness to complete a purchase, change an established habit or use a service repeatedly.

A clickable prototype can test whether people understand a proposed flow. It cannot show whether a live integration works or whether customers will return after several weeks. A manually delivered service can test the value of an outcome, but may conceal the cost of delivering it at scale.

Choose accordingly:

The smallest credible test may involve very little software. It may also require a working product if the uncertainty depends on real use, performance or integration.

GOV.UK’s discovery guidance supports investigating user needs and constraints before committing to a build. That investigation can help determine which type of evidence the project actually lacks.

An MVP can be narrow without being careless. If customers cannot understand the offer, receive confirmation or get help when something goes wrong, poor results may reflect an incomplete service rather than weak demand.

For the repeat-order example, the first release might support only one product category and existing customers. It still needs accurate product information, an understandable submission process and a reliable way to confirm receipt. The team must know how to handle an incorrect order.

Define what users are being offered and what is still experimental. Do not imply that unavailable features or service capacity already exist. If a person performs part of the work behind the scenes, plan and record that effort so the test does not produce misleading economics.

Privacy, security and accessibility also belong in the scope where the service requires them. Calling a product an MVP does not make sensitive information less sensitive. Collect only the data needed for the test, set appropriate access and arrange deletion or retention deliberately.

A credible MVP gives users enough of the service to test the intended assumption fairly.

Include support and recovery in that minimum. A pilot customer should not become stranded because the team treated exception handling as a later feature.

Track the actions that answer the question. For a repeat-order portal, that might include whether customers start unaided, submit accurate orders and return for another order. Record the assistance they needed and the reasons they stopped.

Do not make a single headline metric carry the whole interpretation. A low completion rate could reflect an unclear interface, the wrong audience, unavailable products or little need for self-service. Qualitative observation can help distinguish those explanations.

Keep the test conditions visible. Who was invited? What relationship did they already have with the business? Were staff actively encouraging use? Did the trial occur during an unusual period? These details affect what the result means.

If the team changes the product during the test, record the change and when it occurred. Mixing several versions into one result can make it difficult to identify what users actually experienced.

Review the operating effort alongside customer behaviour. A service may be attractive to customers while requiring too much manual intervention to sustain. That finding can guide the next technical experiment rather than force an immediate choice between full launch and abandonment.

Schedule a review around the evidence the test was designed to produce. Summarise what was learned, what remains uncertain and which commitment is now justified.

The next step may be another focused test, a limited release, a change in proposition or a stop decision. Avoid automatically converting every request from test participants into the next development backlog. Some requests reveal a genuine obstacle; others belong to a different customer group or a later service.

Preserve the assumptions that remain untested. Success with a small group of existing customers does not settle acquisition, scale or expansion into another market. It can still provide a sound basis for the next bounded investment.

When scoping software development, make the learning objective part of the brief. A useful MVP creates a product experience and leaves the business better informed about what deserves to follow.