Define a first release that completes a real task

A smaller first release should still let someone accomplish something useful. Removing half the steps from a workflow may reduce development scope while leaving users dependent on confusing workarounds.

Start with a narrow outcome. Then decide which audience, conditions, and exceptions the first release will support.

Write one sentence about completion

Use the user's task rather than a list of screens. For an illustrative service business: “An existing customer can request an appointment and receive a clear answer about whether it is confirmed.”

That sentence raises useful questions. Does submitting a form confirm availability, or does a coordinator need to review it? Can the customer see a pending state? What happens when the requested slot is unavailable?

Answer these before selecting features. A calendar view might be optional. A truthful explanation of the request's state is part of the outcome.

Separate learning from operating

The Government Digital Service's alpha guidance describes using prototypes to test ideas and risky assumptions. It makes clear that alpha prototypes need not be production-quality code and are not public live services.

That distinction helps when a project uses the term MVP, or minimum viable product. Agree whether the work is a research prototype, a limited live service, or a broader release. The label alone does not define the level of reliability, support, or access control required.

A clickable prototype can help test whether people understand the appointment flow. It does not establish that the business can operate real bookings with it.

Cut breadth before breaking the journey

Consider narrowing the first release to existing customers, one service type, or one location, if that still serves a useful purpose. Document the boundary so staff can explain who is eligible.

For the appointment example, a first release might support a request and staff confirmation while deferring automatic scheduling. That is workable only if the manual step has an owner, capacity, and a visible status.

Classify proposed work:

• Required for the chosen outcome: the user cannot complete the task without it.
• Required for operation: access, support, recovery, and other safeguards appropriate to the service.
• Deferred capability: a useful extension outside the first release's agreed boundary.

Do not automatically move an uncomfortable operational requirement into the deferred column to meet a date.

Make exceptions part of the scope

Choose the failure and correction cases that the supported workflow must handle. Examples include an invalid request, an unavailable slot, a withdrawn request, or a message that could not be delivered.

For each, describe what the user sees and what staff can do. Write the result as an acceptance criterion, then test it with representative records.

Record exclusions just as clearly. If rescheduling remains a staff-assisted process, explain that path to the customer and include it in staff training.

Decide what the release should teach you

Choose a small set of questions: can customers complete the request, can staff process it within the agreed operating model, and where do people need help?

Gather evidence through actual use and support feedback. Avoid declaring success solely because the feature list shipped.

Use a phased rollout when you need to observe the live workflow with a limited group before expanding. The next release should respond to what that experience reveals, rather than automatically restoring every feature removed from the first plan.