How to Build and Test an MVP: An Experiment Plan and Decision Log
Published:
Last Updated:
Category: Marketing Glossary, Marketing Strategy
Authors: Shusaku Yosa
Before building an MVP experiment, write down whose assumption you are testing, what you will provide, what you will observe, and what decision the result should inform. Align the population, observation period, costs, and next action. This reduces the risk of declaring success because registrations arrived or stopping simply because an early response was small.
Choose the question for one experiment
This guide uses a fictional weekly-report service. The question is whether people preparing reports for small teams will try a clearly described offer and choose the stated paid option afterward. Visits from ineligible people and free registrations are not substitutes for evidence about payment.
Apply the learning perspective in Eric Ries’s MVP explanation to a specific decision. Finishing a product is not the experimental outcome. Identify whether the evidence will support continuing, changing the offer, or stopping. If technical feasibility is the main uncertainty, a technical test may need to precede a customer-response experiment.
Match the offering to the question
A landing page observes response to a description and conditions. Manual delivery can reveal how people use an actual result. A limited-feature trial can show operation over a defined period. Each method leaves other questions unanswered, so choose it for the evidence it can provide.
In this fictional experiment, a page explains eligibility and price. Applicants discuss their situation before a two-week trial, with manual report preparation disclosed clearly. They can then choose paid use. Explain the trial period and payment conditions so participants do not infer automatic renewal or functionality that has not been provided.
Write the population, window, and decision rules in advance
The plan below is an illustrative worksheet, not a real business result. Its numerical decision rule is a provisional choice for this experiment, not an industry benchmark or statistical pass mark. The owner should agree on the rule, budget, and safeguards before recruitment begins.
Item | Fictional experiment plan |
|---|---|
Population | New business users who prepare a weekly report for a small team |
Assumption | After trying manual assistance, some choose the explained monthly paid offer |
Offering | Two-week trial; manual work, scope, and pricing explained beforehand |
Observation | Recruit for four weeks, then follow the last participant through their trial |
Unit and exclusions | One person once; exclude duplicates, tests, existing customers, and ineligible cases |
Provisional decision | At least two paid users before another test, while inspecting reasons and workload |
Budget and owner | An experiment owner records recruitment and delivery within a 30-hour limit |
Stopping conditions | Stop for misdirected information, unexplained billing, or inability to provide support |
Describe how eligibility is established. Unknown visitors should not automatically be classified as qualified. If actual records cannot connect people across stages, report separate observations instead of presenting an apparently complete funnel.
Separate registrations, use, and payment
The following fictional cohort contains 200 eligible visitors whose observation has finished. Every later stage is a subset of the preceding stage. It excludes trial users who skipped the interview and purchases from other routes. Connect real stages only where that relationship can be verified.
Observed stage | People | Share of the original 200 | Share of the preceding stage |
|---|---|---|---|
Preregistration | 20 | 10% | 20/200 = 10% |
Interview | 10 | 5% | 10/20 = 50% |
Completed trial | 5 | 2.5% | 5/10 = 50% |
Paid use | 2 | 1% | 2/5 = 40% |
Preregistration is 20/200 = 10%, while paid use is 2/200 = 1%. Calling both “demand” hides the difference. The 40% among completed trials also differs from the 1% among all eligible visitors. Two paid users do not establish reliable market-wide demand.
Define trial completion beyond login or a screen view. Here it could mean using one delivered report in a meeting and returning corrections. Keep stated satisfaction, observed use, and agreement to pay separate. Together they make the remaining uncertainty easier to identify.
Investigate alternative explanations
Many registrations followed by few trials do not prove the service lacks value. Scheduling, eligibility requirements, communication, or an unclear start process may be barriers. Use the counts to locate a point of friction, then investigate possible reasons through observation and participant accounts.
Observation | Possible alternative explanation | Next check |
|---|---|---|
Registration without an interview | Scheduling or contact method does not fit | Message delivery and reasons for declining |
Trial without workplace use | Format or delivery timing is unsuitable | Actual meeting materials and requested corrections |
Free use without a paid choice | Value, price, or purchasing approval creates a barrier | Payment conditions and the existing alternative cost |
Recruitment affects the scope of the result. A test with the founder’s acquaintances is evidence about that group, not automatically ordinary customers. Even with two paid users, unexpectedly high service effort leaves delivery economics unresolved. Examine the workload as well as the demand signal.
Keep a decision log and define the next question
The Lean Startup principles connect what is built, measured, and learned. A practical conclusion might be: “There is some evidence of value in use, while delivery effort and repeat use remain uncertain.” That is more useful than treating two payments as approval for full development.
Record the result, contrary evidence, alternative explanations, unresolved questions, next change, owner, and review date. Do not rewrite a decision rule after seeing the outcome without recording why and when it changed. The same discipline helps both a decision to continue and a decision to stop.
For the next step, use MVP concepts and test formats; a worksheet for defining the test metric; priorities when reviewing a legacy system.
