How to scope a mobile app MVP around one complete task

A minimum viable product should let someone complete a useful task. Removing random screens from a large app does not necessarily create a smaller product that works. Choose the task first, then include the states needed to finish it reliably.

Describe the task in one sentence

For a booking app: "A customer can find a suitable service and request a time." For an internal field app: "A staff member can record a visit and send its result to the team." The sentence should identify a user, an action and an outcome.

List what has to be true before the task begins. Does the person need an account? Is availability supplied by a real scheduling system? Does the staff member have a connection while working? These questions define scope more directly than a list of fashionable features.

Include the states around the main screen

Plan what appears when there are no records, data is loading, an input is invalid or a request fails. Decide how a user corrects an error and whether their work is preserved. A first release needs those answers even if it has only a few screens.

Use a clickable prototype to review the sequence with representative users. Ask them to complete the task without a narrated explanation. Record where the design assumes knowledge they do not have.

Choose the data responsibilities

An app can store information locally, depend on a server or combine the two. Define the actual requirements for accounts, synchronisation, device changes, backups and recovery. Avoid promising these behaviours because an app has a login screen or a cloud service in its stack.

Our Paycebo case study describes a product with local records and manual savings tracking. Its boundaries matter: it does not connect to banks or transfer money. A useful first release makes the supported behaviour clear.

Set acceptance checks before expanding

• A new user can understand the main task and begin it.
• Required information is requested at the appropriate step.
• Success and failure states tell the user what happened.
• The agreed data behaviour is tested across the intended devices.
• The operator knows how to handle issues after release.

Add platform-specific release and store requirements to the project plan after choosing the intended platforms. Those requirements should be verified against the current platform documentation during implementation.

Keep the next phase separate

Write optional ideas in a backlog with the problem each would solve. Notifications, reporting and extra roles should earn their place through a user need, not through comparison with a much larger app.

Bring the main task and an example of the current workflow to our mobile app service. If a browser-based tool could handle the same task, compare it with an app in our first-release guide before choosing the delivery format.