What to decide before you build an MVP

1. Name the problem and the user

A minimum viable product starts with a specific task someone needs to complete. Write down who that person is, what they do today and where the current process breaks down. “A platform for businesses” is too broad to guide a useful first release. “A way for a small purchasing team to request and approve supplies” gives the team a workflow to examine.

Describe what a successful session would look like. What does the user arrive with? What should they leave with? Keep the answer observable: an approved request, a saved appointment or a usable report. A feature list can follow once that outcome is clear.

2. Choose one complete workflow

Map the smallest useful journey from beginning to end. For a purchasing example, that could mean creating a request, reviewing it and recording the decision. Notifications, advanced reporting and supplier integrations might belong in later releases. The first journey still needs understandable states, clear ownership and a way to recover from mistakes.

Separate what must happen inside the product from what a person can handle during a limited pilot. A manual review can help you learn, provided participants understand the arrangement and someone owns the work. Record these temporary steps so they do not become invisible dependencies.

3. Write the boundaries of the first release

Use three lists: essential for the chosen workflow, useful later, and explicitly outside this release. For each essential feature, describe a simple acceptance condition. For example: a requester can see whether their request is waiting, approved or declined, and the reviewer can leave an explanation.

Agree what happens when scope changes. A new idea should have a reason, an owner and an effect on the plan. This helps the team make a decision rather than quietly adding work. Keep budget and timeline discussions tied to these boundaries, with space for unresolved questions.

4. Define records, roles and sensitive information

List the records the workflow needs and how they relate. A request might belong to a team, contain several items and have a recorded decision. Define who can create, view, edit or approve each record. These decisions influence both the interface and the implementation.

Ask what information is genuinely necessary. If the first release can work without sensitive personal data, do not add it just because a future version might need it. Identify where data comes from, who is responsible for it and what happens when an account or record is removed. Bring unresolved policy questions into the planning conversation.

5. Test the uncertain parts before committing

A prototype can help you test whether people understand the journey before the team builds every detail. The GOV.UK Service Manual guidance on the alpha phase describes using prototypes to explore approaches and test risky assumptions. A prototype is a learning tool; it should not be presented as a production service.

Give participants a realistic task and observe where they hesitate, ask for help or reach the wrong conclusion. Avoid only asking whether they like the design. Capture what the team learned and what should change. Use those findings to decide whether to build, revise the idea or investigate further.

6. Prepare a useful project brief

Bring the following to a planning discussion:

• The primary user and problem, with an example of the current process.
• One complete workflow and the outcome it should produce.
• Essential scope, deferred features and explicit exclusions.
• Required records, user roles and known integrations.
• Budget range, timing constraints and unanswered questions.
• How the team will review feedback from the first users.

The aim is a shared starting point. A clear brief makes it easier to discuss trade-offs, estimate the work and decide what the first release should teach you.