A minimum viable product is the smallest coherent experience that can test an important product assumption with real users. Minimum means limited scope, not careless quality. Viable means the target user can complete the intended job safely enough to produce interpretable evidence about value, usability, feasibility, or business fit.
Who this is for: Product teams trying to test a new capability quickly while protecting customers and preserving meaningful learning.
- Choose the risky assumption and target population before deciding which features belong in the first scope.
- Preserve the complete learning loop and nonnegotiable trust conditions while narrowing breadth and automation.
- Define evidence and a follow-up decision in advance so an MVP does not become an underbuilt permanent product.
Name the learning goal
Start with the decision the first release should inform. Does the target user experience the problem, attempt the proposed behavior, receive enough value to return, or accept the business exchange? Select one or two assumptions whose failure would change the investment decision. A scope built without this question usually accumulates unrelated stakeholder requests.
Describe the target segment and use situation narrowly. An MVP for independent tax preparers during intake can differ from one for finance departments closing monthly books. Narrowing the audience increases interpretability and lets the team build one coherent path. It should not be used to exclude inconvenient accessibility or safety requirements.
Map the smallest complete journey
Trace trigger, entry, setup, core action, result, recovery, and next use. Remove optional branches while preserving the moment when the user experiences the proposed value. A reporting MVP that imports data but cannot produce a trustworthy result tests patience, not demand for reporting. Include support and communication needed to complete the loop.
Reduce scale, automation, customization, channels, integrations, or supported segments before reducing integrity. A manual concierge step can test value when customers understand the service and staff can operate it reliably. Hidden manual work, misleading claims, or handling sensitive data without controls damages trust and contaminates learning.
Set the viability floor
List nonnegotiable conditions for accuracy, security, privacy, accessibility, legal review, reliability, and customer recovery. The floor depends on consequence. A private prototype used in moderated research has different exposure from a workflow that moves money. Label the release accurately and restrict access when controls are intentionally limited.
Decide what may be rough but understandable. Visual polish, broad configuration, and automated administration may wait. Core instructions, error handling, data preservation, and the value-bearing action usually cannot. Review the scope with engineering, design, operations, support, and specialist owners before inviting users.
Plan evidence and transition
Define recruitment, behavioral measures, interviews, support capture, guardrails, duration, and thresholds before launch. Measure whether users reach and repeat the value event, not just whether they sign up. Small MVP samples support learning about mechanisms and severe problems but rarely precise market estimates.
Specify the decision after the test: stop, revise, expand, or investigate. Assign a date and owner. Also plan how temporary manual steps, data, and customer promises will be handled. An MVP should not linger indefinitely because the team never established what evidence would justify investment or retirement.
Scope an inventory alert MVP
Independent retailers report stockouts, and the team is considering automated demand forecasting across every sales channel.
- Choose the assumption that store managers will act on a daily low-stock list for their highest-volume items.
- Limit the pilot to one point-of-sale integration, twenty items, one store, and a reviewed daily email.
- Preserve accurate stock data, clear update timing, correction, unsubscribe, accessible content, and support.
- Track list review, replenishment actions, false alerts, stockouts, and manager explanations for ignored items.
- Decide after four weeks whether to improve the signal, add channels, automate delivery, or stop.
MVP scope boundary
Use this worksheet to separate essential learning from breadth that can wait.
- Learning decision: target user, risky assumption, value event, evidence needed, and consequence of being wrong.
- Complete journey: trigger, access, setup, core action, result, recovery, support, and repeat behavior.
- Viability floor: accuracy, accessibility, security, privacy, reliability, compliance, and truthful communication.
- Narrowing choices: segment, volume, channel, integration, automation, configuration, geography, and duration.
- Exit plan: measures, guardrails, sample limits, threshold, decision date, owner, and temporary-work cleanup.
Common mistakes
- Calling a broken fragment an MVP even though users cannot reach the intended value event.
- Removing security, accessibility, or recovery behavior while retaining cosmetic or executive-requested extras.
- Launching broadly without a learning question, evidence threshold, or plan for the temporary implementation.
Try one
A team proposes an MVP that imports customer files but offers no correction path when fields are wrong. Evaluate the scope.
A strong answer rejects the scope if accurate imported data is necessary for the value test or mistakes can harm customers. It proposes narrowing file types, volume, or participants while adding validation, preview, correction, and recovery. The team should define the risky assumption and evidence, rather than learning only that people avoid an unsafe incomplete workflow.
Sources
- Atlassian minimum viable product guideOfficial guidance on defining and learning from a minimum viable product.
- Atlassian product discovery guideOfficial guidance on examining customer problems and testing product ideas.