A useful MVP completes one real customer workflow

An early product can contain twelve polished screens and still leave the user stranded. The dashboard looks convincing, the settings are tidy, and every navigation item has a destination, but the person cannot finish the job they came to do. This happens when teams reduce scope by removing depth from every feature. A better MVP is narrow across the product and complete through one customer outcome.

Scope by outcome instead of screen count

Feature lists encourage horizontal progress. The team builds a little authentication, a little reporting, a little billing, and a little administration. Each area appears active, but none is ready for a real workflow. The result is easy to demonstrate and hard to use.

Outcome-based scope starts with a sentence a customer could say after succeeding: the store manager received stock and can see the updated quantity, the producer turned a script scene into a scheduled unit of work, or the agency client submitted a request and can follow its status. The sentence includes a person, an action, and a visible result.

That result becomes the boundary. Everything required to reach it belongs in the first slice. Features that make a different outcome possible can wait, even when they would make the product look more complete in a pitch deck. This is close to what Basecamp calls a vertical slice: a small piece that cuts through the necessary layers and works as a coherent whole.

Find the narrowest credible path

Narrow does not mean imaginary. A workflow built around perfect demo data avoids the decisions that make production software useful. At the same time, the first slice does not need to handle every customer, role, edge case, or integration.

A practical scoping session can move through four questions:

1. Who is the first specific user?
2. What event starts their workflow?
3. What state proves they finished it?
4. Which exception would make the result untrustworthy if ignored?

The fourth question matters. A stock receipt flow that cannot correct a mistaken quantity is not complete. A scheduling flow that cannot handle a conflict is not complete. The MVP can support one correction path without supporting every possible exception. That keeps the slice honest and bounded.

The GOV.UK service manual frames discovery around understanding the problem, users, constraints, and opportunities before committing to a solution. That work should reduce uncertainty, not produce a long document. Once the biggest unknown is clear, the first slice should be shaped to test it with working software.

Real data changes the product conversation

Placeholder data hides product questions. Realistic records expose naming problems, missing states, awkward permissions, and assumptions about volume. A table that looks elegant with five uniform examples may become unreadable with a long customer name, a disputed amount, and three simultaneous statuses.

Using real or safely representative data early also changes stakeholder feedback. People stop debating button colors and start noticing that a supplier reference is missing, a handoff has no owner, or a status means different things to finance and operations. Those observations are the raw material of product design.

At Alfcode, the Discover and Prototype phases are intended to put a clickable or working slice in front of stakeholders early, followed by engineering in a real environment and weekly demos. The point is not speed as theatre. It is to move the expensive product decisions forward, while the cost of changing them is still low.

StoryXen is a useful example of why connected scope matters. Script breakdowns, storyboards, schedules, and budgets create value because they describe the same production work. A first version that drew four disconnected screens would show breadth but miss the relationship users depend on. A narrower path from one script element into one schedule decision can reveal more about the product than a shallow version of every module.

Keep the slice small without making it disposable

Teams sometimes hear vertical slice and build a temporary path they expect to throw away. That can be sensible for a one-day experiment, but it is expensive when the experiment immediately becomes the product. The goal is not maximum architecture. It is a clean path that can accept the next piece of scope.

A durable first slice usually needs a few foundations:

• a clear data owner for each important record
• explicit states rather than meaning hidden in free text
• permission checks at the server boundary
• basic observability for failures and slow steps
• a migration path for the data that matters

It usually does not need a general rules engine, a plugin system, full design-system coverage, or infrastructure sized for a hypothetical global launch. Those decisions can wait until evidence makes them relevant.

The distinction is between foundations and forecasts. Foundations protect the workflow already being used. Forecasts prepare for variations the team has not yet earned. Good MVP engineering invests in the first and keeps the second easy to add.

Measure completion before engagement

Early metrics often focus on visits, signups, or time in the product because they are easy to collect. A workflow MVP needs a completion measure. Did the user reach the result the slice was designed to deliver? Where did they stop? How long did the handoff take? Which correction path appeared most often?

Completion data is not enough on its own. Pair it with observation and short conversations. A person may finish through a workaround, misunderstand the result, or complete the task while deciding never to return. The metric tells the team where to look; the user explains what happened.

This produces a stronger roadmap than a broad launch. The next scope comes from a blocked completion, a repeated manual step, or a nearby outcome users already ask for. Each addition extends a working path instead of filling another empty section of the navigation.

The first release should settle a real question

A useful MVP is not the smallest collection of features a team can ship. It is the smallest product that lets a specific person finish meaningful work and gives the team reliable evidence about what should happen next.

Choose one outcome, include the layers and exception path it genuinely needs, and put it in front of real users with representative data. If the release can settle a risky product question while completing a customer workflow, it has done more than look ready. It has started earning the next piece of scope.