An MVP Should Complete One Workflow
A first release can contain a little of every planned feature and still do nothing end to end. There is a form without confirmation, a dashboard without an action, and an export that requires a developer to finish the job. The scope is small, but the user has not gained a complete capability.
I find it more useful to define an MVP as a narrow workflow that reaches a meaningful outcome. Reduce the range of supported situations before removing the steps that make the supported situation work.
Choose a beginning and an ending
Consider an illustrative internal request service. The workflow begins when an employee needs access to a resource. It ends when access is granted or declined with an understandable reason. Submitting the form is an intermediate event, not the user's outcome.
A narrow first version might support one resource type and one approval group. It should still provide validation, routing, status, and a final response. That teaches the team about a real process rather than only about form completion.
Cut scope along the edges
Limit users, integrations, request types, supported formats, or operating hours where those limits are appropriate and clearly communicated. A well-defined boundary gives the team a manageable promise.
Do not quietly cut the parts that protect that promise. Access controls, understandable errors, and a route for unresolved requests remain necessary even when the first version serves a small group. “Minimum” should describe supported scope, not a lower standard of honesty.
Keep manual work visible
A manual step can be a sensible way to learn before automating. For the access example, an operator might perform the final provisioning while the system handles intake and status. That can still be a complete service if users understand the expected timing and someone owns the handoff.
Record the time and exceptions involved. Do not present the manual step as automated or exclude it from the cost of delivering the outcome. Otherwise the team can mistake a labor-intensive pilot for a scalable product.
Define the lesson the release should teach
A useful hypothesis might be that clear ownership and status reduce the need for employees to chase requests. The release then needs evidence about repeated inquiries, time to resolution, and unresolved cases—not just registrations or form submissions.
Set a review point and describe what would justify expansion, revision, or stopping. The first release should reduce uncertainty about the next investment. Shipping something small without a learning question can simply create another small thing to maintain.
Test the unsupported path too
Users will arrive with requests outside the chosen boundary. Explain what is supported and provide a useful alternative for the rest. A narrow product that makes every unsupported request look like a technical failure creates avoidable confusion.
Check empty states, duplicate submissions, missing information, and delayed fulfillment. The first release need not handle every case automatically, but it should not lose the request or leave the user unsure whether anything happened.
Expand from observed bottlenecks
After the pilot, examine where the workflow stalled. Perhaps another integration would help; perhaps the approval policy is the bottleneck. Add scope in response to that evidence rather than restoring every feature cut from the original plan.
The smallest useful product is often less broad and more complete than the smallest impressive demo. That distinction creates better learning because users can actually finish something. Pair it with a specific problem definition and metrics tied to completion.