Start with a falsifiable experiment
Write “We believe this user can complete this task with this benefit” and decide how it could be wrong. If the uncertainty is comprehension, test an interaction prototype. If the uncertainty is repeat use in real work, a production workflow may be necessary. Neither a polished prototype nor a large launch establishes demand on its own.
Prototype versus MVP: a worked example
Hypothetical appointment service
| Artifact | What it tests | What it cannot establish |
|---|---|---|
| Clickable booking prototype | Can participants understand the flow? | Real persistence, delivery or repeat usage |
| Scoped production booking flow | Can users request and manage real appointments? | Demand for a large marketplace |
| Deferred marketplace | Separate matching and discovery assumptions | Not justified by booking usability alone |
A scope-reduction checklist
Choose one user group and one primary journey.
Keep the administrator action needed to complete that journey.
Defer cosmetic personalization, additional channels and speculative integrations.
Retain permission checks, meaningful errors and operational ownership.
Write an explicit “not this release” list and change-control rule.
Define success and failure before launch
An illustrative experiment might ask whether five invited participants can request an appointment without assistance and explain what happens next. Those numbers are a test-design example, not a benchmark or observed result. Track where participants stop and why, not just whether they click a button.
For a production trial, distinguish attempted tasks, completed tasks and repeated use. Include support effort and manual work in the evaluation. A small sample can reveal usability problems but does not prove broad market demand; record who participated and what remains unknown.
Release and review
Agree launch access, data handling, monitoring and rollback before inviting users. After the review point, compare the evidence with your original continuation criteria. Stop, adjust scope or expand deliberately; do not treat every new request as proof that the next feature belongs in the MVP.
Frequently asked questions
Can an MVP use manual operations behind the scenes?
Yes, when they are disclosed where relevant, safe and feasible for the trial. Include their actual effort when evaluating the result.
What should never be removed just to launch sooner?
Controls required for the selected workflow, such as authorization, truthful confirmations and a recovery owner. Reduce feature breadth instead.