1. Describe what the person should accomplish

Write a sentence with a user, a situation and a result. Here is a fictional example: a home cook wants to find a saved recipe and tick off its ingredients while shopping. That is a more useful starting point than a list of profile, feed, search and assistant screens.

Define the evidence you need. The person should save a short recipe, find it after closing the app and use its ingredient list without help. You can observe those actions. They do not yet prove that the person will return every week or pay for the product.

2. Put each feature in one of three groups

Ask whether a feature is necessary for that evidence. If it is, keep it and describe the scenario it enables. Otherwise, postpone it or remove it from this project. A postponed feature should have a question that would justify reconsidering it.

In this example, the shopping list depends on a saved recipe. A social network for cooks introduces a different promise and different user relationships. Removing it from the MVP makes the first test easier to interpret.

  • Keep: simple entry, local saving, a recipe list and ingredients to tick off.
  • Postpone: cross-device sync and automatic imports, pending evidence that testers need them.
  • Remove from the MVP: a public feed, creator subscriptions and community rankings.

3. Include the states that complete the journey

A populated recipe screen is not a finished flow. What appears before the first recipe? What happens when the title is empty, saving fails or someone closes the app? Decide those behaviours before calling the feature complete.

You do not need to plan every future version. You do need to make the selected journey dependable. At this stage, an error message that preserves someone’s input may matter more than another statistics screen.

  • First use with no saved data.
  • Invalid input and a way to correct it.
  • Saved result available after restarting.
  • Failure explained without a misleading success message.

4. Make dependencies visible

Record what each feature needs: storage, an account, connectivity, a permission or an external service. Manual entry and local storage might let you test this recipe use case before building an account system.

That is a decision for this example, not a universal architecture rule. If the central value depends on sharing between people or devices, removing the server may remove the purpose of the product. Reduce complexity around the evidence you need without removing that evidence.

5. Turn the scope into a task for AI

Provide context, boundaries and an expected result. For example: add local recipe saving with a required title. The recipe must remain available after restarting. If saving fails, preserve the input and explain how to retry. Do not add accounts or synchronisation.

Ask for the changed files and relevant checks, then review and run the scenario. Split subsequent work into coherent steps: save a recipe, find it again, then manage its ingredients. You should be able to assess one step before accepting the next.

6. Define the next decision

Run a short session with a few people who match your primary user. Observe whether they complete the task, where they hesitate and what they do afterwards. Keep current difficulties separate from suggestions for new features.

If they cannot find a recipe, improve that flow before adding automatic import. If they succeed but keep returning to their previous tool, investigate what is missing in the real situation. The MVP helps you choose the next step from observed use.