Choose an MVP around one complete user outcome

Scope an MVP around one complete outcome

A minimum viable product (MVP) is the smallest credible way to help a specific user reach a useful outcome and learn from real use. It is not a low-quality version of every feature, and “minimum” does not excuse unsafe data handling, inaccessible core flows, unclear terms, or broken recovery.

Start with a before-and-after

Write the current situation and desired result in plain language:

A freelance designer receives project requests in email and loses track of unanswered questions. After using the first version, they can see which requests need a reply and send the next response.

This gives you a user, trigger, outcome, and a way to observe progress. “Add AI,” “build a dashboard,” and “support teams” are implementation or audience labels, not outcomes.

Map the shortest path from trigger to outcome. Include the user’s real starting conditions: where the data comes from, what they must know, how often they do the task, and what they do when the system is wrong. Identify the moments where they can lose data, money, privacy, or trust. Those are part of the core workflow, even when they are not visible features.

Turn scope into a decision table

List each proposed capability and ask whether the target user can reach the promised outcome without it in the first release.

Mark features must have, manual workaround, later, or out of scope. A manual step is acceptable during learning if users know it is manual, it is reliable enough, and you can fulfill the promise. Write down who performs it and how you will detect when it becomes too expensive.

Define a safe first release

For the happy path, specify inputs, output, success state, and a real example. Then cover empty state, invalid input, slow response, failure, retry, duplicate submission, and recovery. If user data can be created, changed, or deleted, define the behavior and permissions for each action. If something consequential can happen, make the user’s intent clear and provide confirmation or undo where appropriate.

Choose one activation event that means the user received value, such as “the user completed a weekly reconciliation and fixed one exception,” not “the user created an account.” Decide what you will observe, how to get feedback, and what you will not track. Use support conversations alongside product events; small counts are diagnostic, not a representative survey.

Use evidence to expand or stop

Release to a small, reachable cohort. Watch people attempt the core task before adding adjacent features. Record where they pause, what work they revert to, whether they return when the job recurs, and what they would miss if the product disappeared. Expand only when repeated use or another concrete commitment supports the next workflow.

Do not optimize for hypothetical scale. Do plan an exit for choices that would make it costly to correct an early mistake. For validation, see customer interviews and idea to first experiment.