Minimum Viable Product: What to Build and What Can Wait

What is a minimum viable product?

A minimum viable product (MVP) is a limited offering used to learn whether a real customer can obtain value from a proposed solution. It focuses on a small set of users and an important assumption, with enough working delivery to make the test meaningful.

Y Combinator recommends keeping initial scope small, putting it in users' hands, and learning from the result.

Test	What it can help answer	Main limitation
Interview	Does this problem matter?	Does not demonstrate solution usage
Landing-page offer	Will qualified people take a next step?	Interest does not prove delivery
Prototype	Can people understand or navigate an approach?	May not support real work
MVP	Can a limited offering deliver a useful outcome?	Early usage does not establish durable demand

Why it matters

An MVP helps you decide where further investment is justified. Without a clear question, a team can build many features while learning little about demand, payment, or delivery.

Keep the longer-term vision separate from this test. A feature belongs in the first release when it is needed for the chosen outcome or to operate responsibly. A smaller product still needs appropriate reliability, permissions, data handling, and support for its intended use.

Worked example: a scheduling MVP

This scenario is invented for teaching. You want to test whether small grooming shops will repeatedly use a shared appointment-reassignment workflow.

The current alternative is a calendar plus staff messages. Your first offering lets a shop enter appointments, see staff availability, reassign a booking, and confirm the result. The founder handles initial setup and records the time spent.

Candidate feature	Decision	Reason
Reassign an appointment accurately	Include	Core customer outcome
Staff access permissions	Include	Needed for the intended shared workflow
Export or recover booking records	Include a suitable method	Protects continuity of real work
Multi-country billing	Defer	Outside the first segment
Advanced analytics dashboard	Defer	Does not answer the initial question
Cosmetic theme marketplace	Defer	Unrelated to the chosen outcome

Suppose five shops try it for three weeks, three repeat the workflow in week three, and two purchase the next paid period. Report each result separately. Also record errors and founder intervention. A workflow that succeeds only through constant hidden manual repair needs a different delivery plan.

Copyable one-page MVP brief

Complete this original brief before choosing the feature list.

Field	Fill in
Target customer and buyer	[Enter]
Problem and current alternative	[Enter]
Most consequential assumption	[Enter one]
Customer outcome to test	[Enter]
Minimum workflow from start to finish	[Enter]
Necessary operating and data protections	[Enter]
Manual work and its owner	[Enter; disclose to participants]
What is explicitly out of scope	[Enter]
Test population and recruitment method	[Enter]
Success and stop criteria	[Enter before starting]
Cost limit, start date, review date	[Enter]
Evidence to collect	[Enter; usage, outcomes, payment, effort]
Decision if evidence is weak, mixed, or strong	[Enter]

Set experiment-specific decision rules before starting; they are not universal benchmarks.

Copyable scope worksheet

Use one row per proposed feature or task:

Item	Assumption or outcome it supports	Required for this test?	Effort/owner	Decision and reason
[Enter]	[Enter]	[Yes/no; explain]	[Enter]	[Include, manual, defer, remove]

Consider a manual process when it can deliver the promised outcome transparently and within your capacity. Track its cost. Manual fulfillment can test demand but does not prove that an automated version works or has the same economics.

Run the experiment

1. Confirm participants match the intended segment.
2. Explain the limited scope, support process, and any manual assistance.
3. Observe whether they complete the outcome with realistic inputs.
4. Record repeat usage, errors, payment, and delivery effort.
5. Review at the planned date and choose the next action.

For consequential workflows, establish what can be tested responsibly. A simulation may be appropriate while live-use requirements are unresolved.

Interpret the result

Pattern	Question to investigate
Participants do not start	Was the audience qualified and the offer clear?
They start but cannot finish	Where does the workflow fail?
They finish but do not return	Does the need recur, and was value sufficient?
They return but will not pay	Who buys, and does the package fit?
They pay but delivery is costly	What must change in scope, process, or pricing?

Record the next change and the question it addresses.

What investors are looking for

Show what the MVP tested, what customers actually did, and which assumption changed. Explain how much manual effort supported the result and what the next investment would prove.

A demo can illustrate a vision. Live usage, paid commitments, repeat outcomes, and delivery economics add different kinds of evidence. Keep those claims separate.

Common mistakes

• Building a smaller version of every planned feature.
• Launching without a clear learning question.
• Calling a waitlist proof that the product delivers value.
• Hiding founder work from the operating model.
• Deferring protections needed for the chosen use.
• Moving the success criteria after seeing the results.

Founder checklist

Name one customer, one outcome, and one important assumption. Complete the brief, prioritize the necessary scope, and set a review date. Capture both customer value and delivery effort.

Your next action: remove one planned item that does not support the test, then resolve one missing requirement that does.

Sources and further reading

• Y Combinator: How to Plan an MVP
• SparkLaunch: Product-Market Fit

References checked November 10, 2026. The brief, worksheet, and scenario are original illustrative teaching material.