An MVP is an experiment with a product-shaped interface
A minimum viable product is the smallest reliable experience that tests a business-critical assumption with real users. Minimum describes scope, not quality. Viable means a customer can complete the promised job safely enough to judge the outcome. Product means the experience can be repeated without the founder explaining every screen.
The strongest MVP plans start with a decision. State what you need to learn, which behavior will answer it, and what result changes your next move. If the launch cannot produce a decision, it is a demo rather than an MVP.
Choose the riskiest assumption before the feature list
| Risk | Question | Cheapest useful test |
|---|---|---|
| Demand | Will the target customer make this a priority? | Paid concierge offer or pre-order |
| Usability | Can the customer complete the core workflow? | Clickable prototype with task observation |
| Feasibility | Can the hard technical step work reliably? | Narrow technical spike using real inputs |
| Distribution | Can we reach buyers at a workable cost? | Small channel test with a qualified CTA |
| Economics | Can price exceed delivery and acquisition cost? | Price test plus manual cost model |
Do not ask one MVP to resolve every risk. If feasibility is uncertain, build a technical spike before a polished flow. If demand is uncertain, sell a manual outcome before automating it. Sequence tests so the cheapest disconfirming result arrives first.
Scope one user, one trigger, and one completed job
A useful MVP has a narrow promise. Write a job story that identifies the situation, motivation, and expected outcome. Then define the shortest happy path from trigger to completed job. Every screen and integration must either enable that path, protect it, or measure it.
Separate launch scope from later convenience
| Layer | Include when | Typical examples |
|---|---|---|
| Must work | Without it, the core job fails or becomes unsafe | Authentication if data is private, core workflow, result, error recovery |
| Must measure | Without it, the experiment cannot answer its question | Activation event, cohort source, result event, payment or return event |
| Manual behind the scenes | The user outcome can be delivered reliably by a person | Review, enrichment, onboarding, report assembly |
| Later | It adds convenience but does not change the decision | Advanced settings, team roles, broad integrations, customization |
Manual operations are acceptable when they are invisible, dependable, and documented. They are not acceptable when users believe a result is automatic but delivery depends on an unmonitored founder inbox. Add a service-level promise, owner, and failure alert for every manual step.
Write the one-page MVP brief
Use a four-week build-and-learn cadence
- Week 1 — prototype and observe: test the happy path with five qualified users before hardening it.
- Week 2 — build the path and instrumentation: implement only the must-work and must-measure layers.
- Week 3 — onboard a small cohort: watch every session you can, log failures, and repair blockers before adding features.
- Week 4 — repeat and decide: measure completion, return or payment, support burden, and the original pass threshold.
Track a small event chain: qualified visitor, started core job, reached value, returned or paid. Include the cohort source and failure reason. A large analytics taxonomy cannot rescue an unclear success condition.
Hold a launch gate before inviting the cohort
- A new user can complete the happy path without founder narration.
- The result is accurate enough for the promise and risk level.
- Failure states explain what happened and provide a recovery path.
- The primary activation and result events are visible in production.
- The team can identify and contact each test participant with consent.
- Manual steps have an owner, response window, and alert.
- Pass, pivot, and stop thresholds are written before results arrive.
After the test, prioritize only what changes activation, delivery quality, repeat use, willingness to pay, or the cost of serving the validated workflow. Everything else waits until the evidence earns more scope.
Frequently asked questions
How long should it take to build a startup MVP?
A focused software MVP can often reach a small qualified cohort in two to six weeks. If the plan is longer, isolate the risky workflow and test more of the delivery manually before building the full scope.
How many features should an MVP have?
There is no ideal feature count. Include only what enables one valuable end-to-end job, keeps that job safe and reliable, and measures the assumption the MVP exists to test.
What metrics matter for an MVP?
Choose a primary behavior tied to the riskiest assumption, such as completing the core job, returning within a defined window, paying, or inviting a collaborator. Add quality and cost guardrails so growth does not hide a broken outcome.