MVP: which features belong in V1?

Most MVPs fail by excess: too many features, too many edge cases, too many months before launch. The right question is not what can we build, but which single behavior proves the product is worth something.

Define the behavior that proves value

Identify the action a user must complete for the product to have been useful: book, order, generate, predict. The V1 is the shortest path to that action. Everything else is judged against it.

Separate the essential workflow from convenience

• Essential: without this step, the core action fails.
• Convenience: the action succeeds without it, just less pleasantly.
• Convenience moves to V2, even when it is easy to build.
• An easy but unnecessary feature is still a maintenance burden.

Keep administration and support visible

Fixing a record, deactivating an account, understanding why a delivery failed: these actions are not optional, even in V1. An MVP without operational tools turns every incident into a database intervention.

Postpone secondary automation

Many automations can start manual: an email sent by hand, a weekly reconciliation. Automate when volume justifies it, not before. Deliberate manual work is a perfectly valid V1 choice.

Set a V1 exit criterion

Decide before launch what will trigger the next phase: a usage threshold, a recurring request, a paying segment. Without an explicit criterion, the V1 stretches forever and the V2 never starts.