What Should an MVP Include—and What Should Wait?

Begin with the decision the MVP must inform

Write:

> We believe [audience] will use or pay for [outcome] because [reason]. We will know enough to continue when [evidence] occurs within [boundary].

If the team cannot state the decision, it cannot distinguish minimum from merely incomplete.

Include one complete value path

The user should be able to:

1. understand the proposition;
2. begin with appropriate access;
3. provide or find required information;
4. receive the promised result;
5. understand success or failure;
6. return, continue, or get support where the product requires it.

A complete slice crosses interface, data, logic, operations, and measurement. Five polished screens disconnected from the result are not an MVP.

Include the states reality creates

At minimum, consider:

• first use and empty data;
• loading and delayed work;
• validation;
• permissions;
• no results;
• external-service failure;
• retry and recovery;
• cancellation or reversal where relevant;
• support and feedback.

The number of states should follow consequence. Payments and sensitive data require more care than a disposable preference test.

Include operations

Document what happens behind the interface:

• who reviews or fulfils work;
• service times and limits;
• support owner;
• data correction;
• incident response;
• onboarding and offboarding;
• backups and recovery;
• manual steps used for early learning.

Manual work is acceptable when it is intentional, measurable, and does not misrepresent the promise.

Include measurement

Track evidence connected to the hypothesis:

• activation of the core workflow;
• successful completion;
• time or effort to value;
• repeat use where relevant;
• payment or commitment;
• failure and abandonment reasons;
• interviews and observed behaviour;
• operational cost to deliver the result.

Define continue, change, and stop conditions before ambiguous data encourages whichever story the team prefers.

Include quality proportional to consequence

Real users still need understandable copy, accessibility, secure access, correct permissions, data integrity, monitoring, and a recovery path.

Defer speculative architecture and polish. Do not defer controls whose failure could harm people, data, money, or trust.

What should usually wait

• multiple audiences and use cases;
• extensive customization;
• advanced administration;
• automation of low-volume internal work;
• social or collaboration features unrelated to core value;
• several pricing tiers;
• native apps for every platform;
• internationalization before a real market need;
• predictive scaling;
• integrations available through a safe manual bridge;
• visual flourishes that do not improve comprehension.

A feature test

For each proposed feature, ask:

1. Which assumption does it test?
2. Which user cannot complete the core path without it?
3. Can the team perform it manually at first?
4. What happens if it waits one release?
5. Does omitting it create harm or merely inconvenience?
6. How will its result be measured?

If the answers are weak, move it out of launch scope.

Common questions