An MVP should deliver a complete useful journey for a defined user, even if the product serves only a narrow use case. A collection of unfinished features is not made viable by being small.
Define the customer and the job
Choose the person, situation and outcome the first version will serve. Avoid designing simultaneously for every future audience. A focused use case makes trade-offs clearer and gives early feedback a context.
For an illustrative scheduling app, the first complete journey might be creating an appointment, sharing it and receiving a confirmation. Advanced analytics can wait if they are not needed to make that journey useful.
Distinguish essentials from polish
Reliability, understandable errors and a way to recover from failure may be essential even when they are not headline features. A missing decorative animation is different from losing a user’s work.
List the assumptions the first version should test. Every major feature should either enable the core journey or help evaluate a meaningful assumption. If it does neither, question whether it belongs in the first release.
Make scope reviewable
Write acceptance criteria in terms of observable behavior. Include device and account states that materially affect the experience. Break delivery into increments that can be demonstrated rather than waiting for a final reveal.
Document exclusions so stakeholders do not mistake a deliberate boundary for a forgotten requirement.
Plan what happens after launch
Choose a few meaningful signals of value and establish a feedback path. Instrument them before release where appropriate. Decide who handles support and which failures require an urgent response.
The purpose of the MVP is to learn from a product people can actually use. Narrowing the audience or workflow is usually more productive than stripping away the parts that make the chosen journey coherent and trustworthy.