Minimum Viable Product: Choose Your First Test
A minimum viable product (MVP) is an early product version used to learn about customers with the least necessary effort, following Eric Ries’s definition. Choose the first MVP test by identifying the assumption that most affects the next product decision, then selecting the simplest format that can test it.
What is a minimum viable product?
An MVP makes a product idea testable before a larger investment. For a functional MVP, Harvard Business School’s overview describes “minimum” as a limited core and “viable” as actually working to solve a customer problem. The scope must still support the question being investigated.
In the Lean Startup methodology, an MVP begins a build–measure–learn cycle: develop an initial version, measure customer response, and use the findings to decide whether to continue or change direction. The purpose is to reduce uncertainty about what to build and whether customers want it.
A useful scope check is to ask what removing each feature would prevent the test from revealing. Keep the parts needed for the observation; defer features that address later questions. Define success in terms of the learning needed for a decision, alongside the behavior that would supply that evidence.
How to choose the first MVP test
Start with the assumption whose failure would most change the next investment. Separate uncertainty about the customer, the offer, price, usability, and continued use. Steve Blank explains that different hypotheses require different MVPs; an early test can use a slide or wireframe when that is enough to generate the required learning.
Write down three things before choosing a format:
- The decision: what investment or product direction the result will inform.
- The unknown: the assumption that needs evidence before making that decision.
- The observable action: what participants must actually do for the result to address the unknown.
Choose one primary uncertainty for the first test. Keep problem understanding separate from acceptance of a proposed solution, and keep initial interest separate from ongoing use. This separation makes the next decision clearer: which assumption gained support, which remains unresolved, and what still needs testing.
Specify the experiment before running it. Strategyzer’s Test Card formalizes four elements: the hypothesis, how it will be tested, what will be measured, and the threshold for success. Add the intended participants, observation period, and next action to make the test usable as an investment decision.
Common MVP formats and what to test with them
Use the following selection guide to match the format to the intended observation. The comparison applies the hypothesis-first approach described by Blank; the evidence limits follow from what each format allows participants to do.
| Question to investigate | Test format | Observation to record | Limit on the conclusion |
|---|---|---|---|
| Does the offer attract interest? | Offer page or demonstration | Responses to a clearly stated invitation | Interest in the offer, without evidence of routine use |
| Can participants understand and complete the core interaction? | Clickable prototype | Task completion, misunderstandings, and obstacles | Interaction with a simulation, without live fulfillment |
| Will customers purchase and receive the service? | Manually fulfilled MVP | Purchases, completed delivery, and fulfillment effort | Demand under the tested conditions, without automated delivery economics |
| Will customers use the core function again? | Narrow working release | Successful use and return use during the observation period | Behavior among the participants and conditions actually observed |
For interaction testing, GOV.UK’s prototyping guidance describes formats ranging from paper sketches to interactive code and recommends choosing the form that meets the current research need. For fulfillment testing, record the work required to deliver the promised result, including manual assistance.
Match the conclusion to the action. Treat a request for information as interest, a purchase as evidence about the tested offer and price, and return use as evidence about continued use over the period observed. Avoid combining these into one undefined measure of “validation.”
MVP versus prototype
A prototype helps explore and test a design before committing to implementation, as explained in GOV.UK’s Service Manual. An MVP is defined by its learning purpose. In Blank’s account, early MVPs can include wireframes and other representations.
The practical implication is that a prototype can serve as an MVP for a design hypothesis. To investigate actual purchase, delivery, or repeat use, choose a test that exposes those behaviors. An interface walkthrough supplies evidence about the interaction studied; keep conclusions about other behaviors for tests that observe them.
How to scope and build an MVP
Turn the chosen question into a short test specification. Apply the Test Card’s hypothesis, experiment, measurement, and threshold structure before producing the artifact.
- Define the participants and problem. Identify the intended customer group and record the current way of addressing the problem.
- Set the learning goal. State the assumption and the result that would support or challenge it.
- Specify the smallest complete test. Include the steps needed to reach the offer, take the measured action, and receive any promised outcome.
- Prepare observation and support. Record the relevant actions, failures, assistance, and work required for fulfillment.
- Run and review. Compare the observations with the preselected criterion, then record the next decision and remaining uncertainty.
Keep required features tied to the measured action. Put additional capabilities on a later list with the question each would address. Include truthful availability, clear terms, and a way to resolve failures in the initial scope. For tests involving personal data, specify what information is necessary, who can access it, and how long to retain it.
Treat prototype code separately when preparing a live release. GOV.UK cautions that prototype code may lack production security and performance, and should not simply be copied into production.
What to measure in an MVP test
The Lean Startup methodology calls for actionable metrics that connect observations to learning. Select measurements around the primary question:
- Interest: record qualifying responses alongside the number of relevant participants exposed to the offer.
- Usability: record completion of the core task, errors, and assistance required.
- Willingness to pay: record purchases at the stated price and terms; track free participation separately.
- Continued use: record return behavior over a period suited to the product’s expected use.
- Delivery effort: record fulfillment time, support, and exceptions, including work done manually.
Report the counts behind any rate, along with the observation period and recruitment method. Record where participants drop out so the result can be reviewed step by step. Preserve qualitative feedback to investigate reasons for observed behavior, while keeping it distinct from the behavior itself.
Define the success threshold before collecting results. Select it around the decision at stake and the meaning of the measured action. A signup threshold and a repeat-use threshold address different uncertainties; use the criterion relevant to the question being tested.
A real MVP example: Zappos
Harvard Business School’s MVP development summary describes Zappos testing whether consumers would purchase shoes online. The founder offered shoes through a website, bought the shoes after receiving orders, and shipped them to customers without first building warehouse inventory or a full fulfillment system.
The useful distinction is between testing purchase behavior and building the infrastructure to fulfill it at scale. Apply that distinction when selecting manual work: record what the purchase test reveals, and reserve conclusions about larger-scale delivery for further evidence.
How long should an MVP take?
The appropriate duration depends on what is needed to learn. Ries emphasizes that MVP scope requires judgment and reports that IMVU’s original MVP took six months. That historical example supplies no standard timetable.
Estimate preparation and observation separately. Include the time needed to recruit participants, deliver the promised experience, and observe the target behavior. Set the budget against the decision the test will inform, and remove work that contributes neither to that observation nor to dependable delivery.
What to do after the MVP test
Review the evidence against the original assumption and criterion. The build–measure–learn loop uses customer response to guide whether to continue or change direction.
Record the supported finding, its conditions, the remaining uncertainty, and the next investment. Continue with the next unresolved assumption when the evidence supports proceeding. Revise the offer or test where results reveal a specific obstacle. Stop further investment when the assumption required for proceeding lacks support after an adequate test. Keep each conclusion limited to the customer group, behavior, and period actually observed.