A minimum viable product is not simply a large application with most of its screens removed. It is a focused version that lets a real user achieve something useful while helping the team answer a product question.
Keep the outcome, reduce the reach.
Start with the result the first user should be able to achieve. A booking product might begin with one service type and a simple operating process, while still making the booking and its confirmation work from end to end.
Reducing the number of roles, markets or optional workflows can make a first release manageable. Removing the steps that make the core action dependable usually makes the product harder to evaluate instead.
Separate the core from the convenient.
For each proposed feature, ask whether the main task fails without it or becomes less convenient. A task that can be handled manually for a small initial audience may not need a full automation system in the first release.
Record those manual steps and the people responsible for them. A temporary operational choice is useful only when it is visible and the team understands its limits.
Include the conditions around success.
Access, permissions and important error states are part of a working journey. So are the operational requirements that protect the agreed use case. A small release still needs clear handling of the information it collects.
Define acceptance criteria in terms of observable behaviour. Someone should be able to walk through the product and determine whether the agreed scope works, including when input is incomplete or a service is temporarily unavailable.
Know what the release is meant to teach.
Choose a small set of questions to review after launch. Can the intended users complete the task? Where do they need help? Which operational work is taking more effort than expected?
Keep the next release connected to what was observed. A prioritised backlog is more useful than automatically restoring every feature removed from the original wish list.
An MVP has a small scope and a complete core experience. Minimum should describe the boundary, not the care.
Questions for the working session.
- What outcome must the first user reach?
- Which roles or workflows can wait?
- Which manual steps need a named owner?
- What will the first release help the team learn?