How to Define an MVP Scope
An MVP scope defines the smallest complete product experience that can test an important business hypothesis with real customers. Start with the decision you need to make, then include what a customer needs to reach one useful outcome. A short feature list is not enough if the journey breaks before value appears.
An MVP can use manual work behind the scenes when that is appropriate and clearly represented. Manual delivery helps test demand, but it does not prove that the eventual automated service will be reliable or economical.
Write the hypothesis and customer boundary
Use a specific statement: “Independent fitness instructors will use a shared attendance list to reduce time spent reconciling class bookings.” Identify the user, buyer, trigger, existing alternative and intended benefit.
Choose one segment for the first test. Beginners and experienced administrators may need different setup paths. Serving both immediately can make the scope large while leaving the central hypothesis unclear.
Define what evidence would justify continuing, revising or stopping. This might combine observed task success, repeated use and an actual buying decision. Avoid treating hypothetical willingness to pay as equivalent to payment.
Map the complete journey
List the steps from first access to the useful result, including recovery. For an attendance tool, that could be creating a class, importing names, recording attendance, correcting a mistake and viewing the final list.
Mark the point where value appears. Then identify which capabilities are necessary to reach it and which only improve convenience. Include basic permissions, understandable errors and support where their absence would make the experiment unsafe or uninterpretable.
| Scope category | Example for an attendance-list MVP | Reason |
|---|---|---|
| Required for the outcome | Create a class and record attendance | Enables the core task |
| Required for trustworthy use | Correct an entry and restrict access | Prevents predictable harm and confusion |
| Acceptable manual operation | Staff-assisted initial import | Tests use before building an importer |
| Explicitly excluded | Payroll, loyalty rewards, advanced reporting | Does not resolve the first hypothesis |
Hypothetical scope negotiation
A fictional team receives requests for payment collection, branded emails and multi-location reporting before its attendance pilot. It asks each requester which problem the feature would solve and whether the pilot customer can complete the core journey without it.
Payment collection is important to the broader business, but instructors already have a workable payment method. Multi-location reporting serves a different segment. Branded emails are convenient. All three remain outside the first release.
During a prototype test, however, instructors cannot correct a name entered in error. That is a core workflow failure, so editing enters scope. The distinction is based on the outcome and consequence, rather than on whether the feature looks small.
Put operational limits beside product limits
Record the participant count you can support, data types accepted, supported devices and response expectations. Estimate manual delivery time and note it in the experiment results. Otherwise, founder effort can make an unscalable workflow appear ready for expansion.
Give the scope an owner. Any addition should state its evidence, the risk it addresses and what it displaces. Set a review date so exclusions are reconsidered after learning, rather than treated as permanent refusals.
The right level of assurance depends on the product. A high-consequence application may need specialised validation before real use, even if its feature scope is narrow. “Minimum” does not remove responsibilities created by the service you offer.
Choose the next test
If the main uncertainty is comprehension, use a prototype. If it is technical feasibility, run a focused technical investigation. If it is repeat use in real conditions, plan a beta test. Do not build production software merely because an MVP is the expected next milestone.
Capture the scope, exclusions, evidence and decision in the product development process. The scope is working when everyone can explain both the customer outcome and what the first version is intended to teach.
Write acceptance criteria for the outcome
Describe what a customer must be able to do under the supported conditions. Good acceptance criteria make behavior observable: an instructor can create a class, record attendance, correct an entry and retrieve the final list. “The interface is intuitive” is too vague to verify.
Include important negative cases. Someone without the right role cannot change the list. A failed save does not silently appear successful. A duplicate submission does not create an unexplained duplicate record. Select the cases that matter to the product’s consequences rather than treating a narrow scope as permission to ignore recovery.
Keep experiment success separate from software acceptance. A product can work exactly as specified while customers choose not to use it. Technical checks establish whether the intended test can run; customer evidence establishes whether the hypothesis deserves more investment.
Choose a credible MVP delivery method
| Method | Suitable learning question | Important limit |
|---|---|---|
| Clickable prototype | Can users understand a proposed flow? | Does not demonstrate working data or operations |
| Clearly described manual service | Will customers use or pay for the outcome? | Does not demonstrate automation economics |
| Limited functioning product | Can a complete journey work repeatedly? | May not cover future segments or load |
| Existing tools combined for a pilot | Does the workflow fit real work? | Integration limits can affect the experience |
For the fictional attendance tool, a spreadsheet-assisted pilot could establish whether instructors value a shared list. It cannot establish that a future mobile application will synchronise reliably. A prototype could test correction labels but cannot demonstrate that records remain correct during concurrent edits. Choose the method that answers the current question.
Estimate effort without turning guesses into commitments
Break the journey into capabilities and identify dependencies. Ask engineering, design and operations to review the difficult parts. Use ranges where uncertainty is material and run a focused investigation when a dependency could change the whole plan.
Include work that is easy to omit: recruitment, support instructions, permission handling, instrumentation, review and manual operations. If a founder prepares every customer’s data before the product works, record that effort. A scope that appears small only because invisible labor is excluded will create misleading economics.
Use the RICE calculator later to compare suitable optional improvements. It should not determine whether an essential safety or correctness requirement belongs in the MVP. For the initial release, the complete testable outcome is the organizing principle.
Handle a scope-change request
Ask the requester to identify the customer task, evidence and consequence of leaving the request out. Then decide whether it is essential to the current hypothesis, a new hypothesis, a defect or a convenience. Record what it displaces if admitted.
In the hypothetical attendance pilot, offline use may become essential if instructors regularly work in venues with unreliable connectivity. That evidence changes the supported conditions and could justify a technical investigation or a narrower pilot. By contrast, a request for custom colors does not become essential merely because it is quick to implement.
Review exclusions with participants before the test so you do not recruit people whose core needs are knowingly unsupported. State limits honestly without describing every omission as a feature coming soon.
Leave the MVP with a decision
Use the startup experiment plan to record the hypothesis, method, measures, cost, result and next action. Decide whether to extend the same test, improve a blocked journey, investigate another segment or stop. If the result is unclear because measurement failed, repair the test rather than adding features and claiming progress.
The first version is not a miniature roadmap for the entire company. It is a bounded investment in a useful outcome and credible learning. Expand only after the evidence identifies which next capability would materially improve that outcome or test the next important assumption.