MVP Development: What to Build First
An MVP should preserve one complete behavior that can test a meaningful product assumption with credible users and evidence.
An MVP should preserve one complete behavior that can test a meaningful product assumption with credible users and evidence.
This guide is written for business decision-makers. It provides practical planning information, not legal, financial, security, medical, or other regulated professional advice.
1. Name the decision the MVP must inform
Define the target user, problem, expected behavior, and learning goal. Ask what evidence would support continuing, changing, or stopping the product. A list of desired features is not a product hypothesis. Prioritize the assumption with the greatest impact on the next investment decision and choose a release audience capable of testing it.
2. Keep one end-to-end core journey
Preserve everything required for a user to complete the meaningful behavior, including essential trust, data, error, support, and confirmation states. Defer secondary roles, convenience features, broad reporting, hypothetical scale, and edge capabilities that do not affect the test. A narrow complete journey produces better evidence than many disconnected screens.
3. Set the right release quality
A clickable prototype, concierge test, technical proof, private beta, and public production product answer different questions. Decide which security, privacy, accessibility, reliability, support, measurement, and deployment obligations apply. Do not expose users to unsafe shortcuts merely because the release is temporary. Document what can be discarded and what is intended to become a foundation.
Decision checklist
- Target user, problem, behavior, assumption, and next decision
- One complete journey and explicit deferred capabilities
- Prototype, pilot, private beta, or production release standard
- Evidence, support, privacy, security, measurement, and product owner
A practical decision rule
The MVP is ready when it can produce trustworthy evidence about the priority assumption—not when it resembles the full roadmap.
Use the rule in context
Document the current evidence, remaining uncertainty, responsible reviewers, and the smallest next step that can be validated. A written project scope should make assumptions, exclusions, dependencies, acceptance criteria, ownership, and ongoing operating obligations visible.
Frequently asked questions
How many features should an MVP include?
There is no universal count. Include the smallest set needed for one credible end-to-end behavior and its safe operation.
Can manual work be part of an MVP?
Yes, when users receive a valid experience and the team clearly understands which steps are manual and what that means for evidence and scale.