An MVP should answer a difficult question before you spend heavily on a product. This guide shows you how to identify the assumption most likely to break your business, design a credible test, and turn the result into a practical build, change, or stop decision.
How Do You Build an MVP Around a Risk?
Start by listing what must be true for your startup to work, then prioritize assumptions that combine high consequences with weak evidence. Choose the smallest experiment that can challenge the leading assumption using relevant customers and observable behavior. Define success, failure, and an inconclusive result before running it; your MVP is the learning vehicle, not a miniature version of the final product.
Step 1: Describe the business as testable assumptions
Write a single sentence describing the customer, problem, proposed outcome, and business model. For example: “Independent repair shops will pay a monthly subscription to reduce missed appointments through automated reminders.” Avoid packing several customer types or unrelated problems into the sentence.
Next, unpack the claims hidden inside it. Shop owners must experience missed appointments often enough to care. Someone must control the budget. Existing scheduling software must leave a meaningful gap. Customers must consent to receiving reminders through a workable channel. Revenue must eventually support messaging, support, and acquisition costs.
Group these assumptions into four buckets:
- Desirability: Does the intended customer care enough to change behavior?
- Feasibility: Can you reliably deliver the promised outcome?
- Viability: Can you capture enough value to sustain the business?
- Access: Can you reach customers, obtain necessary permissions, and fit their workflow?
Do not treat interviews as proof of all four. A customer can dislike missed appointments yet refuse to adopt another tool. Someone can agree to a trial without having purchasing authority. Break broad claims into statements that a specific observation could contradict.
A useful assumption reads: “Owners who currently send reminders manually will connect a booking calendar and approve a paid pilot.” That is more informative than “Small businesses need automation.”
Step 2: Rank risk instead of ranking attractive features
For each assumption, record the consequence of being wrong and the quality of your evidence. Use simple labels such as high, medium, and low rather than precise-looking scores that suggest certainty you do not have.
| Assumption | Consequence if false | Evidence today | Candidate test |
|---|---|---|---|
| Owners will switch workflows | High | Friendly interview comments | Observe onboarding with real booking data |
| Owners will pay | High | No buying behavior | Offer a clearly scoped paid pilot |
| Reminders reduce missed visits | High | General belief | Compare a pilot with an appropriate baseline |
| Owners want a dashboard | Low | One feature request | Defer until core behavior is understood |
The riskiest assumption is not necessarily the hardest engineering task. It is the uncertain claim whose failure would force a major change or invalidate the idea. Building a dashboard first may be comfortable because you know how to do it; it may teach you very little about willingness to pay.
Consider dependencies too. If there is no lawful, practical way to access required data, validating demand will not remove that barrier. Investigate such gating constraints early, using qualified advice when legal or regulated activities are involved.
Keep a short evidence ledger. Record the date, customer segment, observation, and limitations of each finding. This prevents a confident anecdote from becoming an unchallenged team “fact.”
Step 3: Match the experiment to the question
Different experiments answer different questions. An interview can uncover a workflow and its costs; it cannot establish that a product reliably improves an outcome. A landing page can reveal interest in a promise; it does not prove retention or sustainable acquisition.
Choose the lightest method that exposes the uncertainty you actually face:
- Problem uncertainty: Ask customers to walk through a recent incident, including what they did and what it cost them.
- Workflow uncertainty: Use a clickable prototype or observed task to see whether people understand the proposed process.
- Value uncertainty: Deliver the outcome manually through a concierge service before automating it.
- Payment uncertainty: Make a clear offer to a real buyer with price, scope, timing, and cancellation terms.
- Technical uncertainty: Run a narrow technical proof with realistic inputs and explicit reliability criteria.
Paul Graham's “Do Things That Don't Scale” describes recruiting users manually and doing unusually hands-on work early. That supports a useful distinction: manual delivery can be a legitimate learning method even when it is not the intended operating model.
Be transparent about what exists. Do not present a mockup as working software, promise delivery you cannot support, or collect sensitive information simply because a prototype can accept it. For regulated services, a manual experiment does not remove compliance obligations.
Step 4: Set the decision rules before the test
Write a one-page experiment brief before recruitment begins. Include the hypothesis, target participant, offer, observation period, primary measure, and decision owner. Add a specific condition that would make the result inconclusive.
For the repair-shop example, an illustrative hypothesis might be: “At least three of six qualified owners offered a clearly priced pilot will approve payment and complete setup within two weeks.” Those numbers are an example planning threshold, not a benchmark or a statistically reliable market estimate.
The threshold should reflect the decision at stake. A tiny exploratory test can justify another experiment; it should not automatically justify hiring a sales team. Decide what counts as completion and whether a verbal agreement, signed agreement, or actual payment is the relevant evidence.
Track supporting observations without moving the primary goalposts. If nobody pays but everyone praises the interface, praise does not replace the payment criterion. If setup fails because your integration is broken, you may have learned about feasibility rather than demand.
Also set a spending and time limit. An experiment without a stopping rule can quietly become an indefinite product project. Name the next decision date and who can authorize an extension.
Step 5: Run a narrow MVP and record behavior
Recruit people who match the segment, not just people who like you. Document how each participant was recruited, their current workaround, and whether they can authorize the behavior being tested. Friendly introductions are useful, but they may produce an unusually supportive sample.
For a concierge reminder MVP, the founder might onboard shops manually, help configure approved messages, and use an existing service to send them. The customer-facing promise stays narrow: reminders for a defined appointment workflow, not a complete practice-management system.
Record the operational work needed to deliver value. A successful manual pilot can hide hours of founder effort, unreliable data cleanup, or customer-specific exceptions. Those observations become inputs to the next feasibility or viability test.
Compare outcomes carefully. A reduction in missed appointments during a short pilot might reflect seasonal demand, different customers, or an owner paying extra attention. Treat the result as directional unless the design supports a stronger causal conclusion.
Sequoia's business-plan guide separates the problem, solution, market, competition, and business model. Use that separation when reviewing evidence: a working solution does not automatically validate the market or the economics.
Step 6: Decide what the evidence changes
End with a written decision, not an impressive demo. Compare the observed behavior with the original criterion and explain what remains unknown.
- Continue: The assumption has enough support for the next bounded investment.
- Revise: The problem appears real, but the segment, offer, workflow, or price needs adjustment.
- Stop: A critical assumption failed and there is no credible alternative worth testing.
- Repeat differently: Recruitment, delivery problems, or ambiguous measurement prevented a useful conclusion.
Suppose four owners complete setup but only one pays. That is not simply “good engagement.” It suggests setup may be feasible while the current paid offer is weak. Investigate budget authority, alternatives, urgency, and the value received before adding features.
Share contradictory evidence with the whole team. A useful experiment reduces uncertainty even when it makes the original idea less attractive.
Questions About MVP Learning
Does an MVP have to contain working code?
No. A service delivered manually, a prototype, or a narrow technical demonstration can be appropriate. The important question is whether the method can test the chosen assumption honestly. A prototype cannot establish production reliability just because users understand it.
How many customer interviews are enough?
There is no universal count. Interview until you can describe a coherent segment and its recurring behavior, then test the commitment your decision requires. Similar comments from a small convenience sample are useful discovery, not proof of market demand.
What if two assumptions look equally risky?
Prefer the one that blocks other learning or can invalidate the plan sooner at reasonable cost. If neither dominates, design separate, bounded tests. Avoid combining so many questions that a disappointing result has no interpretable cause.
Should I charge for an early MVP?
Charge when payment is central to the question and you can explain exactly what the buyer receives. A free pilot can reveal usability or delivery problems, but it leaves willingness to pay unresolved. Make limitations and refund terms clear.
Test the Assumption That Matters Most
The best early MVP is the smallest honest test of a consequential uncertainty. Keep the scope narrow, the evidence observable, and the next investment proportional to what you learned.
Next steps: Explore MVP building, compare MVP types, and use the guide to scope and ship an MVP.
Sources
- Paul Graham — Do Things That Don't Scale
- Sequoia Capital — Writing a Business Plan
This guide is general education, not legal or financial advice.