An MVP should test a specific uncertainty with a defined group of users. Its scope is not the easiest collection of screens to build. Include what users need to complete one valuable journey, the safeguards needed to operate it responsibly, and the evidence required to decide what happens next.
Write the decision before the backlog
For a proposed booking service, the first question might be whether customers can request a suitable appointment and understand its confirmation. Loyalty points cannot answer that question. Manual review may be acceptable during a limited pilot if a named operator can handle the workload and users are not promised instant confirmation. This is a design example, not a reported customer engagement.
Identify the user, trigger, successful outcome and likely failure. A journey that stops after account creation cannot validate whether the actual service works. Equally, adding a mobile app is unnecessary if a web journey can test the same assumption.
Use a scope decision table
| Question | Decision |
|---|---|
| Does the core journey fail without it? | Include it and define acceptance. |
| Does it protect people, data or money? | Include the minimum safe implementation and tests. |
| Does it provide evidence for the next decision? | Add bounded measurement, not an entire reporting platform. |
| Can an operator perform it safely during the pilot? | Document capacity, responsibility and limitations before deferring automation. |
“Minimum” does not mean omitting authorisation or payment integrity. Deferring recommendations is different from allowing one customer to read another customer’s records.
Make acceptance observable
Replace “build booking” with a scenario: a user selects an available slot, submits once, receives a request reference and sees a truthful status. Repeated submission must not create a second request. Returning later must show the recorded outcome. The design, implementation and tests can now refer to the same contract.
Keep a deferred list with the reason for each exclusion and the evidence that would justify reopening it. Changes during delivery should identify their effect on effort, risk and acceptance rather than silently expanding the first release.
Decide whether to build at all
Before committing, confirm pilot users, an operational owner, safe sample data and a review date. If the audience or problem is still uncertain, discovery or a prototype may be a better next step. Completion of an MVP is not proof of product-market fit.
Use the project brief checklist, separate scope from technology selection, and discuss MVP development when the experiment needs working software.
Sources and editorial status
- GOV.UK: how the alpha phase works.
- Original contribution: scope decision table and booking acceptance scenario.
