The Definition: Learning vs. Feature Completeness
The concept of the Minimum Viable Product (MVP) is one of the most widely misunderstood terms in modern software engineering. It is frequently misconstrued as a buggy Version 1.0, a stripped-down feature release, or a cut-rate prototype designed on a reduced budget. In Eric Ries' framework, however, an MVP has exactly one purpose: to begin the process of validated learning with the minimum amount of effort and development time.
An MVP is not necessarily a smaller piece of software; often, it is not software at all. By determining what fundamental behavior must be witnessed before committing capital, entrepreneurs can pick the exact archetype required.
Three Classic MVP Archetypes
1. The Wizard of Oz MVP
In a Wizard of Oz test, the front end appears to be a seamless, automated digital solution, but all fulfillment operations are executed by humans behind the curtain. An early pioneer was Zappos founder Nick Swinmurn, who photographed shoes displayed in local retail shops and posted them on a simple website. When a visitor ordered a pair, he walked to the brick-and-mortar storefront, purchased the shoes at retail price, packaged them, and shipped them via the post office.
- Core Question: Are customers genuinely prepared to purchase footwear online without trying them on first?
- Avoided Waste: Millions in warehouse leases, inventory procurement, and custom supply-chain software.
- Trade-off: High human labor cost per transaction, but negligible upfront fixed expenditure.
2. The Concierge MVP
While the Wizard of Oz test conceals human involvement behind a simulated digital interface, the Concierge MVP intentionally makes that involvement transparent. The founder acts as a personal consultant, guiding the user through the process manually.
Food on the Table, an early case study cited in The Lean Startup, began with its founder meeting a single subscriber weekly in local grocery aisles, manually cross-referencing meal plans with supermarket discounts before any automated recommendation algorithm was developed.
- Strength: Unmatched qualitative feedback and immediate understanding of edge cases.
- Weakness: Zero scalability; requires intentional graduation to automation only after value patterns recur reliably.
3. The Smoke Test / Explainer Video MVP
Before writing the synchronization engine for Dropbox, Drew Houston produced a simple screencast demo showing mock files syncing across folders. The video addressed tech enthusiasts in their native language and directed them to an email waitlist. In a single night, the waitlist swelled from 5,000 to over 75,000 prospective users, verifying market appetite before complex low-level kernel drivers had been stabilized.
| Archetype | Primary Objective | Engineering Effort | Best Suited Context |
|---|---|---|---|
| Smoke Test | Measure demand interest & value resonance | Extremely Low (1–3 days) | New-to-market consumer services, hardware ideas |
| Wizard of Oz | Observe user workflow & transaction friction | Low to Moderate (1–2 weeks) | Marketplaces, recommendation tools, logistics |
| Concierge | Deeply map complex customer domain problems | Negligible (manual labor) | High-ticket B2B software, personal optimization |
The MVP Quality Dilemma
Founders frequently ask: "Will an unpolished MVP compromise our company's reputation?" The empirical evidence compiled across hundreds of Lean startups reveals a clear pattern: customers suffering from an acute, unsolved pain point will eagerly tolerate imperfect UX, visual glitches, and manual steps if the core utility relieves their frustration. If prospective customers dismiss an MVP purely based on visual aesthetics, it frequently signals that the underlying problem is not severe enough to justify a standalone commercial business.
The Rule of Pruning
When formulating an MVP, draft every feature the team believes is essential. Then, systematically remove half of them. Repeat this exercise once more. Whatever survives constitutes the true minimum required to test your core value hypothesis.