How to scope an MVP so one real user can test it

Most first releases fail in the same way. They try to serve three kinds of users, with ten features, before anyone has used the product once. The team ships late, and the feedback it gets is about everything and nothing.

We scope a first release around one person and one decision. This is how.

Start with one user

Name the user. Not a segment, a person: the shopper in an aisle with a product in one hand, the business development manager who needs to know who to call this week, or the parent planning a complex trip for older relatives.

Write down what this person must decide, and when. The time matters. A decision made in a shop aisle allows 90 seconds. A decision made at a desk allows an afternoon.

Pick the decision, not the feature list

A feature list grows without limit. A decision has a clear end: the person acts, or does not.

Ask one question: what is the smallest thing that lets this person make this decision better than they do today? That answer is the first release. Everything else waits.

For a label-checking tool, the decision might be “does this product meet my requirements?” The first release could combine a simple scanner with manual search. Voice input, multi-pass recognition and onboarding can come later, after real scans show what is slow and what is missed.

Write the problem boundary

A useful scope says what the release will not solve. The label checker may identify listed ingredients but not certify manufacturing conditions. A planning tool may prepare a brief but not take bookings. A data product may surface a signal but not replace the authoritative record.

These limits are not apologies. They protect the promise. When the team knows the boundary, it can design clear messages for uncertain results instead of quietly expanding into work it cannot support.

Write the boundary in language a user can understand and place it near the result. If it only exists in the project plan, it will disappear from the interface.

Write the test before the build

Before we build, we write down how we will know the release works:

• Who will use it, and where.
• What they will try to do.
• What result counts as success, in numbers if possible.
• What we will measure to see it.

If a feature does not help pass this test, it is not in the first release.

The test should describe behaviour, not opinion. “Users like the dashboard” is difficult to act on. “Five target users can find the next action without assistance” gives the team something observable. Choose a small number of measures tied to the decision: completion, time, error rate, return use or whether the output is shared.

Decide in advance what would make the team stop or change direction. A test that can only confirm the idea is a demonstration, not an experiment. Failure criteria prevent weeks of explaining away weak evidence.

Keep the parts that make the product honest

Cutting scope is not cutting corners. Some things stay in even when they take time:

• Clear limits. The product says what it does not do.
• A way to give feedback. Even a simple form, stored where the team can read it.
• Basic measurement. Enough to see where people stop.

These are the parts that turn the first release into learning.

Accessibility, security and performance also belong in the definition of useful. They should be proportionate to the risk, but they are not optional polish. A small release still needs keyboard access, readable contrast, safe handling of input and acceptable speed on the devices its first users actually own.

The distinction is between foundational quality and optional breadth. A second persona is breadth. Ten export formats are breadth. Clear errors and protection against losing work are foundational.

Use a scope ladder

When the feature list still feels large, arrange it in three levels:

1. Decision minimum. The smallest path that produces a useful answer or output.
2. Trust minimum. Sources, limits, error states and feedback required for someone to rely on it.
3. Learning minimum. Events and prompts required to understand what happened after launch.

Build all three levels, but keep each one narrow. This is more reliable than labelling dozens of stories “must have”, because it explains why each item survives the cut.

Everything else becomes a candidate for the next release. Do not promise it automatically. Rank it only after the first users reveal which constraint matters most.

Recruit the first users early

The first user should not appear after deployment. Involve a handful of target users while the decision and boundary are still being written. Ask them to show how they solve the problem today, including spreadsheets, messages and workarounds. Their current method reveals the standard the first release must beat.

Avoid turning these conversations into feature voting. People are better at describing friction than designing the solution. Listen for repeated steps, missing information, moments of uncertainty and consequences of a wrong decision.

When the release is ready, test it in the real context. A mobile workflow that succeeds at a desk may fail in bright light, on a weak connection or under time pressure. Context is part of the requirement.

What to expect

A release scoped this way feels small. That is the point. It can be tested by one real user in one real situation, and the result tells you what to build next.

Small does not mean temporary or disposable. The first release should establish a sound path through the product, even if that path is narrow. It can grow by adding new decisions and users around a stable core instead of replacing a rushed prototype.

Teams that skip this step often spend months on features that nobody asked for. Teams that take it ship something small, learn fast, and then grow the product in the direction real use points to.