MVP scope decision guide
Which features should go into an MVP?
Include the features needed for one intended user to complete one valuable journey, plus the controls needed to operate it responsibly. Put optional variations and untested ideas into a later list, with evidence that would justify adding them.
Describe a finished task before listing features
Feature prioritisation is the decision about what belongs in the first release, what can be handled deliberately outside the software and what should wait. Start by naming the user, their problem and the result they need. “A dashboard” is a feature; “a customer can see whether a request needs their attention” is an outcome.
Walk through entry, action, confirmation and correction. Include what happens when the task fails. A collection of attractive screens is not a viable journey if the final decision still disappears into an unowned inbox.
Separate the user outcome from the business learning goal. You might need to learn whether customers complete a request without staff assistance, not whether they click a new button. The MVP service page explains the first-release approach; this guide is about selecting the actual work within that boundary.
Use a keep, assist, defer or investigate test
| Question | Decision | Evidence to record |
|---|---|---|
| Does the core journey fail without it? | Keep the smallest usable version. | The step and user outcome it enables. |
| Is it required to protect users or operate the release? | Keep the necessary control. | The risk and acceptance test. |
| Can a person handle it honestly and reliably? | Consider assisted operation. | Owner, capacity, fallback and user expectation. |
| Is its value mainly a future possibility? | Defer it. | The observation that would reopen the decision. |
| Is the dependency or user need unclear? | Investigate before committing. | A question and a bounded test. |
This is a practical planning aid, not a validated scoring model. Use judgement when consequences differ. A low-frequency recovery control can matter more than a frequently requested cosmetic feature.
Do not vote away the release safeguards
Keep necessary permissions, clear errors, data recovery and a route to support inside the first-release discussion. Reduce their scope to the actual product rather than treating all controls as an expensive enterprise layer.
For example, a product with one customer role may not need a configurable permission designer. It still needs to prevent that customer from seeing someone else’s records. A service with manual review may not need automatic scheduling, but it needs a visible pending state and someone responsible for resolving it.
Write acceptance examples alongside each essential feature. Describe the intended success, one important failure and an unauthorised action that must be denied. The release checklist covers the evidence needed after the scope is selected.
Use manual work only when it preserves the learning
A small team can deliberately review requests, prepare an import or onboard customers manually. That can help test the useful outcome before automating every back-office activity. Make the user promise accurate and measure staff involvement.
Manual work is a poor shortcut when the proposition itself depends on immediate self-service, high-volume processing or dependable operation without staff. In those cases, an assisted demonstration could falsely suggest that the product assumption has been proved.
The GOV.UK alpha guidance describes using prototypes to test risky assumptions. Apply that principle where the need is still uncertain; it is not a requirement to copy government delivery phases. Use the prototype comparison if learning can happen before a live product is needed.
Prioritise a customer-request product
Hypothetical example: customers email service requests and then phone for updates. The first product is intended to let an invited customer submit the required details and see the reviewed status.
- Keep: customer access, required request information, a staff review queue and a visible status history.
- Keep as controls: organisation-level access, understandable validation, recovery of saved requests and support ownership.
- Assist: staff allocate the appointment outside the software, with the agreed status recorded in the product.
- Defer: loyalty rewards, several languages and predictive scheduling unless the initial audience requires them.
- Investigate: whether the existing scheduling system offers a usable interface before promising automatic updates.
The release remains narrow while producing a real result. It also exposes whether the missing value is request capture, status visibility or the scheduling process itself. Do not assume this hypothetical list fits another business unchanged.
Give every deferred feature a reason to return
Keep a decision record containing the request, the user problem, the chosen treatment and the evidence needed to reconsider it. Revisit priorities using completed journeys, support requests and observed failures, not only stakeholder enthusiasm.
Estimate the resulting scope with the team using the budget guide and dependency-led timeline guide. A feature that looks small may depend on unavailable data or a supplier approval.
AI coding tools do not change this prioritisation test. Faster implementation of an unnecessary feature still creates testing and maintenance work. Start with the core outcome and expand when usage evidence supports the next investment.
Sources and review date
Primary sources reviewed on 7 September 2026 and linked beside the claims they support. Decision tests are planning recommendations, not measured research. Examples are hypothetical, not client case studies. Confirm scope, price, timing and specialist-review needs with the responsible team.
Questions
Frequently asked questions
Should every stakeholder get a feature in the MVP?
No. Agree a shared first user outcome and evaluate each request against it. Record deferred needs and the evidence that would justify adding them.
Can an MVP contain manual work?
Yes, when it is explicit, supportable and does not invalidate the learning goal. Define the owner and user expectations.
How do we prioritise security and recovery?
Treat necessary controls as part of the viable release, not optional popularity-ranked features. Scope them to the actual users, data and consequences.
Plan the next useful step
Bring the workflow and the result you need.
Discuss the users, existing systems and first-release boundary before committing to a build.