How to Build a Minimum Viable Product That Answers One Expensive Question

A product team can cut half its backlog and still build too much. It can also show customers a rough screen in an afternoon and build too little to learn anything useful. Neither outcome is determined by feature count.

A minimum viable product is the smallest credible test that can change a product or business decision. “Minimum” refers to the scope needed to produce useful evidence. “Viable” means that the test is realistic, safe, and reliable enough for the observed response to mean what the team thinks it means. The “product” is the vehicle for the test; it need not be a small version of the eventual release.

That interpretation follows the purpose of the method. The Lean Startup describes the MVP as the way to begin learning quickly within a build-measure-learn loop, while its larger principle is to test a vision continuously rather than perfect a product before customers encounter it (The Lean Startup methodology). Steve Blank makes the operational point more directly: the MVP required to test customers is different from the one required to test pricing or a feature, because the thing built has to match the hypothesis (Steve Blank on hypothesis-specific MVPs).

This changes the first question. Do not ask, “What is the fewest number of features we can ship?” Ask, “What uncertainty is blocking our next decision, and what is the least elaborate test that could resolve it?” That focus gives engineering, design, sales, and leadership a shared reason to exclude work that cannot improve the evidence.

An MVP is a decision instrument, not a small release#

The usual “version one, but thinner” model starts from a future feature set and removes items. A useful MVP starts from a consequential unknown and adds only what is necessary to test it. The first approach minimizes a product. The second minimizes the cost and time of credible learning.

Suppose a B2B team is considering an automated workflow. It may be uncertain whether target users recognize the problem, whether they can complete the proposed workflow, whether the result is valuable, whether a buyer will approve it, or whether the technical mechanism can work under the required conditions. A thin slice of the whole envisioned product touches every uncertainty while resolving none of them well. One focused test may not resemble the final product at all.

The Harvard Business School MVP development summary describes MVP development as a process of making the smallest effort needed to learn, usually through focused experiments and iteration. That wording matters. A team does not “finish the MVP” once and graduate automatically to full production. It runs a bounded test, learns, and decides what uncertainty deserves attention next.

Put the question before the artifact#

An MVP begins with a decision that could genuinely go in more than one direction. Examples include whether to pursue a segment, revise a proposition, continue a workflow design, investigate a technical constraint, or stop investing. If every possible result leads to the same build plan, the exercise cannot reduce decision risk.

Turn that decision into one bounded hypothesis. “Operations teams need better reporting” is too broad: agreement could mean sympathy, curiosity, or a real intention to change. “Eligible operations managers can use this proposed report to identify the exception they would act on next” connects a participant, context, behavior, and consequence. It also exposes what the test still will not establish, such as whether a buyer will approve the product or whether users will return over time.

Then identify the riskiest assumption: the unknown whose failure would change the direction most. Public-sector service guidance gives the same practical advice at the alpha stage—prototype enough to test the riskiest assumptions, not necessarily the entire journey (GOV.UK Service Manual). Scope follows uncertainty, not the sitemap.

Know which artifact you are actually making#

Teams often use prototype, proof of concept, pilot, MVP, and first release as if they marked successive degrees of polish. A better working distinction is the claim each artifact can support.

These categories can overlap. A realistic prototype may be the vehicle for an MVP test of task completion. A manual service may be the vehicle for testing whether an outcome has value. A proof of concept may answer the riskiest question when technical feasibility is what blocks the decision. The label should follow the claim, not the appearance of the artifact.

The distinction also prevents prototype code from drifting into production by accident. GOV.UK notes that a code prototype may be realistic enough for user research while lacking the security and performance needed for a live service (guidance on making prototypes). Visual realism and release readiness are separate properties.

Write the learning contract before production begins#

The most useful MVP deliverable is often a one-page learning contract. It prevents a team from changing the question after seeing the result, calling any activity “engagement,” or adding features because the test feels uncomfortably small.

Write the contract in this order:

1. Name the blocked decision. State what the team will start, stop, change, or investigate after the test. Include the point after which the information would arrive too late to matter.

2. Select one riskiest assumption. Phrase it as a bounded claim about a named participant, situation, behavior, or constraint. Keep other assumptions visible as unresolved; one test does not become stronger by pretending to answer several questions.

3. Define the relevant behavior. Specify who must participate, what context must be present, what task or choice they will face, and what will be observed. When the claim concerns actual use, polite approval is weak evidence. Task completion, a concrete commitment, or use of the delivered outcome is closer to the claim.

4. Choose the least elaborate credible test. Match the artifact to the unknown. A problem interview or observation can investigate whether the problem exists. A concept test can expose misunderstanding. A task-focused prototype can test whether users complete the core job. A manual delivery can test the value of an outcome. A proof of concept can test a mechanism. A limited pilot can reveal what happens during continued use.

5. Set interpretation rules before the session. Describe what would strengthen the hypothesis, what would weaken it, and what would leave the result inconclusive. There is no universal conversion rate, sample size, or pass mark for every MVP. A threshold is useful only when its basis and the decision it triggers are explicit.

6. Set stop conditions and the next action. Stop when the decision has enough relevant evidence, when recruitment or instrumentation makes the result invalid, when further exposure creates unacceptable harm, or when a declared resource boundary is reached. Map each possible result to a next action before enthusiasm has a chance to reinterpret it.

Preserve the test version, participant eligibility, deviations, observations, and missing data. This is not bureaucracy for its own sake. If the message changes halfway through or half the intended participants cannot access the task, the apparent result may describe the test setup rather than the proposition.

Choose the test that is nearest to the uncertainty#

Distance between the observation and the claim is the hidden source of many false positives. A click can support a claim about response to a message. It cannot establish that the product can deliver an outcome, that users will keep using it, or that a procurement team will approve it. Likewise, a successful technical demonstration can support feasibility under its tested conditions while saying nothing about whether the problem matters.

The same test can also produce different evidence for different participants. An end user completing a workflow may reduce usability uncertainty. A security reviewer accepting the data path may reduce an adoption constraint. A budget holder agreeing to a defined next step may reduce buying-process uncertainty. In B2B work, “the customer” is often several people whose decisions cannot be collapsed into one enthusiastic interview.

This is why measurement begins with the claim rather than a dashboard. Observe the event closest to the uncertainty, and record enough context to interpret it. If the hypothesis concerns comprehension, ask the participant to explain or act on the proposition. If it concerns workflow completion, use realistic inputs and watch the task. If it concerns outcome value, deliver the outcome and observe what changes. If it concerns buying viability, include the stakeholders and requirements that can actually block the evaluation.

Negative results need the same discipline. When eligible participants do not understand the proposition, first ask whether the message and recruitment represented the intended situation. When they understand but do not attempt the task, motivation, timing, or audience may be wrong. When they attempt but cannot complete it, interaction or technical failure may be the cause. When they complete it but reject the result, the value mechanism is under pressure. Broken recruitment or instrumentation is not a negative product result. It is an inconclusive test.

Viability means credible behavior without avoidable harm#

“Minimum” does not grant permission to remove whatever is inconvenient. Keep anything needed to make the target behavior believable and interpretable: the core outcome, realistic information, sufficient reliability, access for eligible participants, and honest disclosure of what is manual, simulated, limited, or unfinished.

The exact baseline changes with exposure. An internal clickable prototype using fictitious data does not need the operating capability of a customer-facing pilot. A live test connected to customer systems carries very different obligations. NIST’s Secure Software Development Framework notes that security practices often have to be added explicitly to development lifecycles rather than assumed to be present (NIST SP 800-218). “We are only testing” does not erase the attack surface created by a live integration.

Privacy must follow the same logic. For organizations subject to the UK GDPR, the Information Commissioner’s Office says data protection begins at the design stage, continues through the lifecycle, and requires limiting personal information to what is necessary for the stated purpose (ICO guidance on data protection by design). Other jurisdictions impose different duties, but the product judgment travels: collect less data, restrict access, disclose the test honestly, and do not confuse minimal features with minimal care.

Do not expose real customers or their data merely to make an MVP feel more realistic. If the intended learning can come from synthetic data, a restricted environment, or a manual process, the smaller exposure may produce a cleaner test. If real conditions are essential, the safeguards are part of the minimum credible scope.

An MVP is complete when the predeclared evidence can support the blocked decision or a stop condition has been reached. It is not complete because a sprint ended, a demo ran, or the team has grown tired of testing. The result may be “continue,” “change the test,” “investigate another uncertainty,” or “stop.” Learning does not owe the original idea a favorable verdict.

Make the first cut at the decision#

Before discussing features, write one sentence: “We need to decide whether ___, and this test will change that decision by observing ___ from ___ under ___ conditions.” If the blanks cannot be filled without vague words such as interest, engagement, or feedback, the team is not ready to scope the artifact.

Once the sentence is precise, remove everything that does not protect credibility, safety, the target behavior, or interpretation. What remains may be a screen, a manual service, a technical experiment, or a narrow live product. Its form is secondary. The decision it can improve is the reason it exists.

Frequently asked questions#