How to choose what your first MVP should include
A minimum viable product, or MVP, should help you learn about the people you intend to serve. For a first usable web release, start with an outcome a user needs to reach and a question the release should help you answer. Include the work necessary to complete that journey, handle its important exceptions and observe what happens.
This guide focuses on scoping a first usable web product. Earlier assumptions may be explored through a clickable prototype or a service delivered manually. If the main uncertainty is whether people understand a proposed flow, product UI/UX design and prototyping may be a useful next step.
A prototype can look realistic while still lacking the engineering needed for live use. GOV.UK's design guidance distinguishes prototype code from code suitable for production. GOV.UK guidance on making prototypes.
Define the user and the decision before listing features
Name a specific user, the situation in which the problem occurs and how they handle it today. A broad description such as businesses that need to work faster leaves too many different needs inside the scope.
Then write the question early use should help answer. Connect it to a decision: what would you need to learn before improving the product, changing the approach or investing in a wider release?
Eric Ries's original MVP explanation centers the work on learning about customers and makes appropriate scope a matter of context and judgment. Eric Ries on the minimum viable product.
Use that question when assessing feature requests. A feature deserves attention when its absence prevents the core task, introduces an unacceptable problem or makes the intended learning impossible. Other ideas can remain visible without becoming part of the first build.
Work through an agency approval example
Illustrative product scenario and scope worksheet.
Imagine a product for agency project leads and clients who currently review design deliverables through email. The first trial involves one pilot agency and its invited clients. The intended outcome is a clear review decision associated with the correct deliverable version.
The learning question is: will agency leads and their clients use a shared review flow to reach that decision?
For this example, the initial flow uses a nominated client reviewer for each request. Whether that arrangement matches the pilot agency's process is an assumption to check before building around it.
Map the complete journey
- The agency lead creates a project and invites the nominated reviewer.
- The lead uploads a supported file, identifies its version and requests review.
- The client opens the assigned request and can identify what needs a decision.
- The client leaves feedback, requests changes or approves the deliverable.
- Both parties can see the decision and its associated version. A revised deliverable begins a new review request, preserving the previous decision.
The journey ends when the participants can act on the result. A successful upload alone would leave the approval problem unresolved.
Separate the included work from deferred ideas
| Scope decision | Example content | Reason |
|---|---|---|
| Include | Agency and client access with defined permissions | Participants need to reach the appropriate project without seeing unrelated client work. |
| Include | Project creation, invitation and a named deliverable version | The reviewer needs a clear item to assess. |
| Include | Feedback, approval, visible review status and essential notifications | Participants need to know when a review is ready and what decision has been made. |
| Include | Basic administration of the pilot agency's projects and invitations | Staff need a way to manage the trial's records and access. |
| Include | Recovery for a failed upload or an invitation the client cannot use | Otherwise participants may be unable to finish the task. |
| Defer if unnecessary for this trial | Advanced portfolio reports and configurable role builders | They do not answer the stated question unless the intended users or trial depend on them. |
| Outside this example's first release | Automated subscriptions, native mobile apps, AI features, historical imports and additional integrations | This trial focuses on the core approval journey for one agency. |
| Investigate before committing | Multiple reviewers, supported file types and agency ownership of client access | These assumptions could change the workflow and the work involved. |
Deferring a feature does not mean removing the underlying requirement. A configurable role builder may wait; appropriate client access cannot. Elaborate version-management tools may wait; the decision still needs to identify what was reviewed.
Give assumptions a check and an owner
| Assumption | How to check it | Who needs to resolve it |
|---|---|---|
| A nominated reviewer can make the required decision | Ask the pilot agency how approval actually works and review a recent example | The product owner with agency participants |
| The chosen upload format covers the initial task | Inspect representative deliverables and the client's review needs | The product owner with design and technical input |
| Clients will participate in a separate review flow | Invite suitable clients to try the proposed journey and discuss their constraints | The product owner with participating agency leads |
Record the result and its effect on scope. If an assumption fails, reconsider the journey before adding features to compensate for it.
Include the exceptions that change the outcome
Decide what happens when the reviewer cannot access the request, the upload fails, a request is withdrawn or a new version arrives during review. Clarify who can reopen or replace a request and what happens to the existing decision.
The amount of functionality can stay focused, but these states need an understandable response. Also define the information used in the trial, who may access it and how participants can get help when they cannot continue.
Write checks that someone can verify
Acceptance criteria describe observable behavior. Replace a statement such as approvals should work with checks tied to the journey.
| Intended behavior | Example acceptance check |
|---|---|
| Access follows the project assignment | The invited reviewer can open the assigned request; another client's account cannot access its file or feedback. |
| Decisions remain tied to the reviewed item | An approval shows the relevant deliverable version and reviewer. Uploading a replacement does not transfer that approval to the new version. |
| Failed work is visible | A failed upload does not appear ready for review, and the lead receives a usable retry route. |
| The review result is unambiguous | After a decision, both participants see the same current status. Repeating the submission does not create conflicting decisions. |
These checks address whether the software behaves as intended. The learning question also requires observing whether people choose to use the flow and whether it helps them reach a clear decision.
Plan participation and learning alongside the build
Identify how you will recruit suitable users, what they will attempt and who will observe or collect feedback. For the approval example, include the pilot agency's project leads and invited clients: agreement from the agency does not establish that its clients will participate.
Watch where people need help, return to email or stop before reaching a decision. Ask what caused the behavior. A failed invitation, an unclear interface and an unwanted workflow suggest different next steps.
Record how much assistance participants receive. Completing a heavily guided session may help reveal usability problems, but it gives a different picture from someone independently choosing to use the product again. Successful task completion also does not establish willingness to pay.
Before the trial, describe the observations that would lead you to continue, revise or pause. Review the results against those decisions and the remaining uncertainties. Avoid treating every new feature request as a reason to expand the build.
Use a short scope brief for your own product
Copy these prompts into your planning document. Keep answers specific enough for another person to question or test.
- Intended users and current approach: Who has the problem, when does it occur and how do they handle it today?
- Learning question and next decision: What do you need to learn, and what choice will that information support?
- Complete journey: What starts the task, what happens next and what counts as reaching the outcome?
- Included and deferred work: Which capabilities support that journey, and which ideas can wait with a reason recorded?
- Assumptions and dependencies: What could change the scope, how will it be checked and who owns the answer?
- Access and exceptions: Who may see or change information, and what happens when the expected flow breaks?
- Acceptance checks: How will someone verify the included behavior using representative situations?
- Participation and evaluation: How will suitable users take part, what will you observe and what would lead to the next decision?
Revisit the brief when a request changes the audience, journey or learning question. An added screen may be a small change; a new approval role or customer group can affect much more of the product.
Turn the scope into an estimate and a build discussion
The brief gives you a basis for discussing effort, dependencies and exclusions. The MVP development cost guide explains how those choices affect an estimate and what to separate from the initial build.
If you want help defining and developing the first usable release, explore MVP development services or bring your brief to a project discussion.