A minimum viable product should let a defined user complete a meaningful task. It is not simply a full product with most features removed, nor a list of screens labelled essential. The planning challenge is to choose one complete journey, include the supporting states that make it dependable and postpone work that does not answer the first release's question. A narrow release can still require careful design and engineering.

Choose the user and the job

Describe who uses the product, what triggers use and what outcome they need. A hypothetical equipment inspection app might help field staff record an issue and send it to a supervisor. That is more specific than an app for maintenance. Identify the user's working context, including device, connectivity and interruptions, before drafting the feature list.

Write the current alternative and why it is inadequate. Staff may use photos and messages that leave the issue's location unclear. The app's first question could be whether a structured report makes the handoff understandable. Keep this as a hypothesis until tested. Do not claim operational savings or user demand merely because the proposed journey sounds plausible.

Map a complete journey

Draw the steps from entry to outcome: identify equipment, describe the issue, attach permitted information, review and submit. Include what the supervisor receives and how staff know what happened. A release that collects reports but offers no understandable confirmation may not complete the user's job. The end of a form is not necessarily the end of the service journey.

For the inspection example, clarify whether submission creates a draft, queues a report or confirms delivery. Include correction and cancellation where appropriate. Decide what happens if the user is interrupted. These states may not be prominent in a pitch, but they determine whether people can trust the product during ordinary work.

Prioritise by necessity and risk

Label each proposed feature as necessary for the journey, necessary for safety or reliability, useful for learning, or deferrable. Account access, permissions and error recovery may be essential even when they are not visible differentiators. A reporting dashboard with many charts may wait if the immediate question is whether the report handoff works.

Avoid using minimum as a reason to omit basic privacy and security responsibilities. Define what data is collected, who can see it and what happens when someone leaves the organisation. Use the smallest appropriate data set and access model. If a required integration is uncertain, investigate it early rather than designing the entire release around an unverified assumption.

Test the journey before production

Create an interactive prototype that covers normal and difficult states. Ask representative users to complete a task without extensive coaching. Observe where terms, navigation or feedback are unclear. A prototype can test understanding, but it does not establish the reliability of saving, synchronisation or delivery. Technical risks may need a separate proof of concept.

For field use, test content visibility and interaction size in an appropriate working context. Check keyboard and assistive-technology needs for relevant users. Do not assume a clean desktop demonstration reflects use on a phone during an inspection. Record the tested context and the limits of what the sessions show.

Define release acceptance and ownership

Write concrete acceptance criteria for the complete journey, including permissions, failed submissions and duplicate actions. Agree the target devices and operating conditions. Assign release approval, monitoring and support owners. State what the client receives and what continuing services or licenses are required. A release plan should make dependencies visible before users rely on the product.

Choose a small set of learning questions for the live release, subject to appropriate privacy requirements. Can users complete the task? Are reports useful to supervisors? Which exception causes the most support work? Avoid collecting everything without a decision purpose. Separate reported user problems from speculative feature requests when planning the next iteration.

MVP scope checklist

  • Name one user, working context and meaningful outcome.
  • Document the current alternative and the hypothesis.
  • Map the journey through a confirmed result or handoff.
  • Include reliability, permissions and recovery requirements.
  • Defer features that do not support the first question.
  • Test understanding and investigate technical risks separately.
  • Agree acceptance, ownership and a focused learning review.

Bring the journey and exclusions to the development conversation. A well-scoped first release should feel complete for the task it supports while remaining honest about what it does not do. That clarity is more useful than a broad feature count and gives the next iteration a stronger basis in observed needs.