MVP Scope: How to Choose the First Workflow Worth Building

Choose one complete workflow that tests an important assumption

A useful minimum viable product gives a specific user a complete way to solve a specific problem, while helping the team learn something that matters. Scope the first release around that workflow. Cutting random screens from a large wish list usually produces an incomplete product rather than a smaller useful one.

For example, “a marketplace with profiles, chat, payments, analytics and AI” describes a collection of capabilities. “A local business can submit a service request and receive a confirmed appointment from an operator” describes a workflow. The second statement makes it easier to identify the user, the outcome and what must be true for the product to be useful.

An MVP is not permission to ignore data integrity, access controls or recovery. It is permission to choose a smaller business boundary and deliberately postpone capabilities outside it.

Start with the person and the evidence

Write down who experiences the problem, when it happens and how they handle it today. Use an actual example where possible. A founder's belief is a valid starting hypothesis, but it is different from observing someone struggle with the process.

Ask what the user would stop doing if the product worked. Would they stop copying an order between tools, chasing a status by telephone or assembling a report manually? This makes the proposed value concrete without inventing a revenue or time-saving claim.

Before building, investigate whether the problem is caused by missing software, unclear responsibility or an awkward existing process. Software can make a confused process run faster while leaving the confusion intact.

Draw the workflow from trigger to outcome

List the smallest sequence that produces a useful result. A booking example might be request, operator review, available slot, customer confirmation and a clear booking record. Each step needs enough information for the next person to act.

Include the operational user, not only the customer-facing screen. If a customer can submit a request but no one can find or process it, the workflow is unfinished. Conversely, the operator may initially use a simple queue rather than a sophisticated dashboard.

Then add the exceptions that would make the first release unusable: invalid information, no available slot, a duplicate submission and cancellation. Not every edge case belongs in version one, but the common failure paths need an honest response.

Separate first release, later work and assumptions

Scope category	Example	What to record
First release	Customer request and operator confirmation	Behaviour and acceptance criteria
Later release	Automated provider matching	Why it can wait and what would justify it
Assumption to test	Customers will accept a manual review step	How to observe acceptance or friction
External dependency	Access to the provider's calendar API	Owner, availability and fallback
Explicit exclusion	Payments are handled outside the product	What the interface tells users

An exclusion is most useful when it explains how the workflow still completes. “No automated matching” can work if an operator can assign a provider. “No confirmation” may leave the customer unable to tell whether anything happened.

Avoid promising a later feature as if it already exists. A prototype can illustrate a future experience, but a live user should see the capabilities and limitations of the current release.

Use acceptance criteria that can be observed

“The booking system works” is difficult to assess. More useful criteria state the actor, action and result. For instance: a customer who submits a valid request receives a reference; an operator can see it; confirming the same request twice does not create two bookings; a cancelled slot becomes available again.

Include permission boundaries. A customer should not be able to open someone else's booking by changing a URL. A read-only operator should not be able to modify the schedule. These checks are part of the workflow, even if they do not appear in a sales demonstration.

Also define the evidence needed for acceptance: a walkthrough with representative records, relevant automated checks, a deployment procedure and an operational handover. The required detail depends on what the release actually does.

A prototype and an MVP answer different questions

A prototype can test whether people understand a proposed interaction. A proof of concept can test whether a difficult integration or technical approach is feasible. An MVP tests a useful product workflow with its intended users. Teams sometimes need these in sequence; sometimes a small experiment avoids a build entirely.

The GOV.UK Service Manual describes alpha work as an opportunity to explore risky assumptions and constraints before committing to a service approach. That principle is useful beyond public services, even though your delivery process need not copy theirs. Source: How the alpha phase works.

Choose the experiment according to the uncertainty. A polished interface does not prove an integration is available. A successful API request does not prove customers want the proposed workflow.

Decide what learning will change your next decision

Before release, identify the observations that would justify continuing, changing direction or stopping. You might examine whether users complete the workflow, where they need help, what operators must correct and which requests fall outside the current scope.

Separate these observations from vanity totals. A visit is not a completed request. A completed request is not necessarily a qualified customer. Explain what each event means and combine numbers with direct feedback from the people doing the work.

Use a review period that fits the workflow. A daily shop transaction can produce feedback sooner than a monthly business approval. Do not declare success or failure from an arbitrary tiny sample just because a dashboard is available.

When existing software is enough

Try a configured tool or a manual service first when it can test the main assumption. If a form and an operator can establish demand, building a custom matching engine may be premature. Custom development becomes more compelling when the workflow or integration requirements are distinctive and supported by evidence.

AivoraLabs' delivery method separates requirements, architecture, design, implementation, QA, release and handover. A demonstration milestone is different from a promise that every production scope is finished within a fixed number of days. Your agreement should name the actual deliverables and acceptance gates.

A one-page discovery brief

Write a paragraph for each of these: the user and problem; the complete first workflow; evidence already collected; the riskiest assumption; essential exceptions; systems and data involved; first-release exclusions; and the decision you want the release to inform.

Bring that brief to an MVP software development discussion. If the uncertainty is primarily technical, proof-of-concept development may be the appropriate first step. Discuss the first workflow worth building.