MVP definition: a Minimum Viable Product is the smallest version of a product that delivers enough value to validate a specific assumption with real users, generate learning, and inform whether to invest further — not the smallest version that can ship.
The most abused term in product management. MVPs get used to justify building too little ("it's just the MVP"), too much ("everything is required for the MVP"), and the wrong things entirely (shipping a feature instead of testing an assumption). Understanding what an MVP actually is — and what it isn't — is foundational for product managers at every stage.
The Original MVP Definition
Eric Ries defined the MVP in The Lean Startup as: the version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.
Note what this definition optimizes for: validated learning, not shipped features. An MVP is a learning vehicle, not a product milestone.
H3: What MVP Is Not
- Not a beta: A beta is a low-quality version of the final product. An MVP tests whether you should build the final product at all.
- Not a prototype: A prototype is a simulation. An MVP involves real users doing real actions with real stakes.
- Not a slice: "Building the MVP" doesn't mean building one feature. It means building enough to test the riskiest assumption.
- Not a permanent excuse: The MVP is a phase, not an identity. "It's MVP" is not a reason to ship bad UX forever.
Types of MVPs with Examples
H3: The Concierge MVP
Definition: Deliver the service manually before building automation.
Classic example: Food on the Table (acquired by Univision) launched by having a team member personally deliver custom meal plans to one customer, manually, before building any software. They tested whether customers would pay for personalized meal planning before writing a line of code.
When to use: When you're testing whether the job-to-be-done is worth solving before investing in automation.
H3: The Wizard of Oz MVP
Definition: Present a technology-powered interface to users while humans fulfill the service behind the scenes.
Classic example: Zappos founder Nick Swinmurn tested whether people would buy shoes online by photographing shoes at local stores and listing them. When someone ordered, he bought the shoes at retail and shipped them manually. No inventory, no warehouse.
When to use: When you need to test whether users will complete the core action (purchase, signup, upload) before investing in backend infrastructure.
According to Lenny Rachitsky's writing on early-stage product development, Wizard of Oz MVPs are underused in SaaS because teams default to building. The question they should ask first is: can we fake this functionality manually to test demand before committing engineering time?
H3: The Landing Page MVP
Definition: Describe the product and capture signups or pre-orders before building anything.
Example: Dropbox's famous explainer video — a 3-minute demo of a product that didn't exist yet — generated 75,000 signups overnight and validated massive demand before a single line of production code was written.
When to use: When you're testing whether the problem is urgent enough that people will take action (sign up, pay) before you've built a solution.
H3: The Single-Feature MVP
Definition: Build one core feature to production quality and ship it.
Example: Instagram launched with just photo sharing and filters. No video, no DMs, no stories, no explore. The single feature that delivered the core value proposition.
When to use: When you've validated the problem and need to test your solution's core value delivery.
H3: The Piecemeal MVP
Definition: Assemble an MVP from existing tools (no-code, APIs, third-party services) rather than building from scratch.
Example: An internal productivity tool MVP built with Airtable + Zapier + Slack before committing to a custom build.
When to use: When speed-to-test matters more than a clean technical architecture and existing tools can simulate your core value.
How to Choose Your MVP Type
H3: Start With the Riskiest Assumption
Ask: what single assumption, if wrong, would make this entire product not worth building?
- If the assumption is demand (will people want this?): Landing Page MVP or Concierge MVP
- If the assumption is willingness to pay (will people pay for this?): Wizard of Oz with a real payment flow
- If the assumption is usability (can people use this?): Prototype or Single-Feature MVP
- If the assumption is retention (will people come back?): Single-Feature MVP with real users
According to Shreyas Doshi on Lenny's Podcast, the biggest MVP mistake is testing the easiest assumption rather than the riskiest one. Teams build polished landing pages when the real risk is whether users will complete the core action, not whether they'll read a description of it.
Setting MVP Success Criteria
Before you launch an MVP, define:
- What you're testing: The specific assumption
- How you'll measure it: The metric that validates or invalidates the assumption
- What threshold means success: "If X% of users do Y, we proceed"
- When you'll decide: A fixed time horizon (not "when we have enough data")
According to Annie Pearl on Lenny's Podcast discussing product validation, the MVP learning is only as good as the success criteria you set before launching. Teams that define success after seeing the results are practicing confirmation bias, not validated learning.
FAQ
Q: What is the definition of an MVP? A: A Minimum Viable Product is the smallest version of a product that delivers enough value to validate a specific assumption with real users and generate learning about whether to invest further — not simply the smallest version that can ship.
Q: What are the different types of MVPs? A: Concierge MVP (manual delivery), Wizard of Oz MVP (simulated technology), Landing Page MVP (demand test), Single-Feature MVP (core value test), and Piecemeal MVP (assembled from existing tools).
Q: What is a Wizard of Oz MVP? A: An MVP where users interact with what appears to be an automated system while humans fulfill the service manually behind the scenes — used to test user behavior before investing in backend infrastructure.
Q: How do you choose the right MVP type? A: Identify your riskiest assumption. If it's demand, use a landing page or concierge. If it's willingness to pay, include a real payment flow. If it's usability, use a prototype or single-feature build. Match the MVP type to the assumption being tested.
Q: What success criteria should you set for an MVP? A: Define what assumption you're testing, the metric that validates or invalidates it, the numerical threshold that means success, and a fixed time horizon for the decision — all before launching.
HowTo: Define and Launch an MVP
- Identify your riskiest assumption — the single belief that, if wrong, would make the entire product not worth building
- Choose the MVP type that tests that specific assumption with minimum effort: concierge, wizard of oz, landing page, single feature, or piecemeal
- Define success criteria before launching: what assumption you are testing, which metric validates it, what threshold means proceed, and a fixed decision date
- Launch the MVP to a small, representative segment of your target users — not internal team members
- Collect data and user observations against your pre-defined success criteria without changing the goalposts
- Make a clear proceed, pivot, or stop decision based on whether the riskiest assumption was validated or invalidated