Defining the Scope of an MVP

An MVP should not be a smaller version of every feature on a product roadmap. Its first release should let a defined audience complete an important task and reduce a critical uncertainty about the product. Start by writing down who has the problem and what you need to learn.

“Competitors have it” and “we might need it later” are weak reasons to include a feature in the first release. Explain how each item supports the user outcome or the assumption being tested. The goal is a coherent first experience with a clear purpose.

Classify uncertainty before building

GOV.UK's discovery guidance focuses on understanding the problem and its context before development.[1] In your product, distinguish questions about demand, usability, feasibility and operations. These are useful decision principles, rather than a requirement to adopt a public service delivery process.

If the question is whether people understand a journey, a prototype may provide useful evidence. If the question concerns real usage, data quality or operational load, a working release may be necessary. GOV.UK's alpha guidance also uses prototypes to explore risky assumptions.[2] A positive response to a prototype does not, by itself, demonstrate production demand.

Map one user outcome from beginning to end

In a hypothetical booking product, the main task is to find an available appointment and receive a confirmed reservation. A calendar screen alone cannot complete that task. Availability checks, confirmation and relevant failure states need consideration too.

A loyalty scheme or advanced reporting may not be necessary to test the initial assumption. Record why features are excluded so the same discussion does not reopen every time someone reviews the roadmap.

Keep necessary safeguards in scope

A small release does not remove security, privacy, accessibility or legal obligations. Establish release requirements with the appropriate specialists. An internal demonstration and a product open to real customers carry different risks.

Some operations may initially be manual, but assess the consequences for users, data handling and team capacity. Give each manual step an owner and clear limits. Avoid suggesting the system is doing something automatically when the service actually depends on a person.

Define the learning decision before release

Agree who will participate, which task will be examined and what evidence would justify continuing, changing direction or stopping. Use evidence appropriate to the uncertainty instead of a generic success percentage. Adding features before understanding why people struggle can expand scope without resolving the original question.

Frequently asked questions

Is the MVP simply the fastest release we can build

Speed matters, but the release needs a meaningful task and a learning objective. An incomplete journey built quickly can produce misleading conclusions.

Are a prototype and an MVP the same thing

No. A prototype may simulate selected interactions. A working MVP can provide different evidence about real use and operations.

How should we begin scoping

Write down the target user, one main task and the critical assumption. Explore VOYA MVP product design services to discuss the boundaries of the first release.

Sources

1. GOV UK Discovery phase
2. GOV UK Alpha phase