MVP planning guide
How to scope a minimum viable software product
A minimum viable product is the smallest product that delivers a useful outcome and teaches you something important. It is not every planned feature implemented poorly, and it is not a prototype that cannot test real behaviour.
The short answer
Choose one specific customer and one valuable end-to-end job. Keep only the capabilities required to reach that outcome, handle the riskiest parts manually when appropriate, and define the evidence the first release must produce. Everything else belongs after the test.
A practical process
Move from an assumption to a decision.
- 01
Choose the riskiest assumption
The first release should reduce the uncertainty most likely to invalidate the business: customer urgency, behaviour change, technical feasibility, payment, or acquisition.
Do this: Write the single assumption that would make the rest of the build irrelevant if it proves false. - 02
Define one user and one outcome
Multiple roles and use cases multiply permissions, navigation, data states, and support before the core value is understood.
Do this: Name the first user, the trigger that brings them in, and the result they must leave with. - 03
Draw the shortest complete workflow
A thin slice should work from beginning to end. Completing one job is more informative than building fragments of five future modules.
Do this: Reduce the flow to input, essential transformation, useful output, and feedback or next action. - 04
Separate software from operations
Automation can wait when a founder can safely perform a low-volume step manually. This reveals real exceptions before expensive systems are built.
Do this: Mark which early steps can be concierge, imported, reviewed, or fulfilled manually. - 05
Set a learning threshold
An MVP needs a decision attached to it. Decide in advance what behaviour would support continuing, narrowing, changing, or stopping.
Do this: Choose a small cohort, observation period, meaningful action, and the decision each outcome will trigger.
Evidence checklist
What stronger evidence looks like.
- The first customer and use case are unambiguous.
- The workflow produces a complete, useful outcome.
- Every included feature is required for that first outcome or its measurement.
- Manual steps are visible and safe rather than disguised as automation.
- The release tests the riskiest business or product assumption.
- Success, revision, and stop conditions are written before launch.
Common mistakes
Avoid evidence that feels useful but changes no decision.
Calling a feature list an MVP
A backlog describes output. An MVP describes the customer outcome and learning goal.
Building for future scale
Premature roles, integrations, automation, and infrastructure consume time before the core workflow earns demand.
Shipping too little value
Minimal does not mean unusable. The customer must still receive a meaningful result worth evaluating.
Decision rule
Know what would make you continue—or reconsider.
The scope is small enough when one builder can deliver one complete customer outcome and measure the riskiest assumption. If removing a feature does not prevent that outcome or learning, remove it from the first release.