What Is a Minimum Viable Product (MVP)? Definition, Examples & How to Build One
The term “minimum viable product” is one of the most used — and most misunderstood — concepts in product management. Teams build MVPs that are too big, too small, or that confuse an MVP with a beta release. And some companies call things MVPs that are really just incomplete products.
This guide answers what is a minimum viable product in plain terms, where the concept came from, what it’s not, real-world examples from companies you know, and a practical process for building one. Across early-stage teams, the projects that fail usually aren’t the ones with bad ideas — they’re the ones where nobody agreed in advance on what “minimum” and “viable” actually meant.
What Is a Minimum Viable Product?
A minimum viable product (MVP) is the smallest version of a product that allows a team to collect the maximum amount of validated learning about customers with the least effort.
That definition comes from Eric Ries, who popularized the concept in The Lean Startup (2011) and has continued to refine it on Lean Startup Co.’s own site. It’s worth reading slowly: the goal of an MVP isn’t to build a product quickly. It’s to learn quickly. The “minimum” refers to how much you build. The “viable” means it must be real enough to generate genuine customer feedback.
An MVP is not a prototype (which is a mockup). It’s not a beta (which is a nearly finished product with rough edges). It’s not an incomplete product (which just lacks features). It’s a deliberate strategy for learning whether your core assumption — that a specific product will solve a specific problem for a specific group of people — is actually true.
Where the Concept Came From
The term was coined by Frank Robinson of SyncDev around 2001, but it was Eric Ries and Steve Blank who brought it into mainstream product thinking through the Lean Startup movement. The Agile Alliance’s glossary entry traces the concept’s adoption timeline if you want the fuller history.
The core insight behind MVPs came from observing how most startup failures happen: not because the engineering was bad, but because teams spent months or years building something nobody actually wanted. They had assumed the market, assumed the problem, and assumed the solution — without ever testing any of those assumptions with real users.
The MVP was the answer: build the minimum necessary to test your core assumption, learn from real users, and then decide whether to iterate, pivot, or abandon the direction entirely.
What Makes an MVP “Viable”?
This is where teams often get it wrong. The “minimum” part gets all the attention. The “viable” part is what makes it work.
Viable means the product must:
- Deliver enough value that users can form a genuine opinion of it
- Be something a real user would actually interact with (not just a Figma mockup)
- Test the core hypothesis — the fundamental assumption your product is built on
A landing page that describes a product is not an MVP. It can test whether people are interested in a concept (demand validation), but it doesn’t test whether the product actually delivers value.
An MVP is the smallest product experience that puts your core value proposition in front of real users in a real context.
Types of MVPs
Not all MVPs take the same form. The right type depends on what you’re trying to learn.
Concierge MVP
Instead of building software, you manually deliver the service to a small number of customers. This is the fastest way to test whether the core value proposition works before investing in automation.
Example: The early version of Food on the Table (a meal planning app) had no app at all. The founder personally visited one customer per week, learned what meals they liked, found grocery deals at their local store, and hand-delivered a meal plan. Once he understood what made the service valuable, he automated it.
Wizard of Oz MVP
The product looks like it’s automated on the outside, but humans are manually performing the operations behind the scenes. Users interact with what appears to be a working product.
Example: Zappos founder Nick Swinmurn wanted to test whether people would buy shoes online. Instead of building inventory management and fulfillment infrastructure, he took photos of shoes at local stores, posted them online, and when someone ordered, he went back to the store, bought the shoes, and mailed them himself. The “store” looked automated. It wasn’t.
Landing Page MVP
A web page that describes the product and includes a signup or waitlist button. Used to measure demand and interest before building anything.
Example: Dropbox’s first MVP was a demo video that showed the product working before it was built. Drew Houston posted the video to Hacker News overnight. Signups went from 5,000 to 75,000 by morning. They knew demand was real before writing a single line of the actual product.
Single-Feature MVP
Build only the single most important feature — the one that delivers the core value proposition — and nothing else.
Example: When Instagram launched in 2010, it had one defining feature that no other app had: the ability to take a photo, apply a beautiful filter, and share it in under 30 seconds. No DMs, no Stories, no Reels. Just filtered photos. That single feature was enough to validate the concept and grow to 1 million users in two months.
Piecemeal MVP
Assemble an MVP from existing tools and services rather than building custom software. This is increasingly common thanks to no-code tools.
Example: Buffer, the social media scheduling tool, started as a two-page website. Page one described the concept. Page two had a pricing table. If someone clicked a pricing plan, they got an email from the founder saying the product wasn’t ready yet but asking if they’d like to join the beta. The founder used those responses to validate demand before writing any code.
Famous MVP Examples
Airbnb
In 2007, Brian Chesky and Joe Gebbia couldn’t pay rent on their San Francisco apartment. They set up air mattresses in their living room, took photos, and created a simple website called “Air Bed and Breakfast” to rent out floor space to conference attendees. No booking system, no payment infrastructure, no trust and safety platform. Just a webpage and email communication. The positive response showed them the concept worked.
Uber
The first version of Uber (then UberCab) launched in 2010 in San Francisco with a simple iPhone app that could only request a black car service. No UberX, no UberPool, no dynamic pricing algorithm. The founders manually managed dispatch, using SMS messages to coordinate drivers. It worked well enough in that limited form to validate the core idea.
Spotify
Spotify’s first MVP was a desktop app that streamed music to a small group of testers in Sweden. No mobile app, no social features, no podcasts. Just proving that music streaming could work without buffering — which was the core technical hypothesis at the time.
Twitter started as an internal tool at Odeo, a podcasting company. The MVP was a basic SMS-based status update service used only by Odeo employees. They first tested it at the 2007 South by Southwest festival, where usage tripled over the event weekend. The response validated the concept before the team built it out further.
How to Build a Minimum Viable Product: Step by Step
Step 1: Identify Your Core Assumption
Every product is built on a set of assumptions. Some are obvious; some are hidden. The most dangerous are the ones you’ve never made explicit.
Write down the single most important assumption your product depends on. Something like: “Freelancers struggle to track billable hours across multiple clients using existing tools” or “Small business owners would pay for automated bookkeeping if it required no accounting knowledge.”
If this assumption is wrong, your product has no foundation. That’s exactly what you need to test first. Running a product discovery sprint before you build is one of the most effective ways to validate these assumptions quickly.
Step 2: Define What You’re Testing
The core assumption becomes your test hypothesis. Make it specific and falsifiable:
“If we build [X], then [target user] will [take action Y] because [reason Z].”
For example: “If we build a one-click expense capture feature for freelancers, then freelancers will capture expenses daily because it’s faster than their current method.”
Step 3: Choose the Right MVP Type
Based on your hypothesis, choose the MVP type that gets you learning the fastest. Ask: what’s the minimum thing we need to build (or fake) to find out if this assumption is true?
Use a concierge or Wizard of Oz MVP when you need to test the full service experience without automating it. Use a landing page MVP when you’re testing demand. Use a single-feature MVP when you have a technical or UX hypothesis to validate.
Step 4: Define Your Success Criteria
Before you build, decide what success looks like. This is critical — without pre-defined success criteria, you’ll rationalize whatever result you get. It’s a common trap: a team decides, after the fact, that a 4% conversion rate they’d have called a failure the week before was actually “encouraging” — because nobody had written the number down in advance and admitting the test failed felt worse than moving the goalpost.
Good success metrics for an MVP might include:
- X% of users who try the feature complete the core task
- Y% of users return within 7 days
- Z% conversion rate from landing page to signup
Step 5: Build Only What’s Necessary
Resist the pull to build more. Every feature you add beyond the minimum is a hypothesis that hasn’t been tested. It’s also engineering time you can’t get back.
A useful filter: Will removing this feature make it impossible to test the core assumption? If removing it doesn’t break the test, remove it.
Step 6: Get It In Front of Real Users
An MVP tested internally is not an MVP — it’s a prototype. Get it in front of real users who represent your target audience. This could mean launching publicly, recruiting testers, doing a soft launch to a small segment, or running guerrilla user testing. Our guide to conducting user interviews covers how to get honest reactions instead of polite ones once you’re actually in front of them.
The important thing is that the feedback comes from people who genuinely have the problem you’re solving — not from colleagues who are trying to be supportive.
Step 7: Measure and Learn
Collect both qualitative and quantitative data:
- Quantitative: Did users complete the core task? What were the conversion rates? What was the retention?
- Qualitative: What did users say? Where did they get confused? What delighted them?
Compare results against your success criteria and make an honest decision: persist (you validated the assumption), pivot (you learned something that changes the direction), or stop (the assumption was wrong and the opportunity isn’t there).
A strong MVP process eventually leads to the ultimate goal — product-market fit. Your MVP is how you begin finding it, and the direction it points you toward should feed directly into your product strategy rather than living as a one-off experiment nobody revisits.
Where MVPs Break Down (And How to Fix Them)
Building too much. The most common mistake. If your MVP takes three months to build, it’s not minimal. Push back on every feature that isn’t essential to testing your core assumption — the fix is a hard rule: if removing a feature doesn’t invalidate the test, it doesn’t ship in v1.
Skipping the “viable” part. An MVP so rough that users can’t form a genuine opinion doesn’t generate useful learning. A checkout flow shipped with enough bugs that every tester’s feedback is about the bugs, not the actual pricing question the team needed answered, is a classic version of this failure. The fix: if your bug list is longer than your findings list, the test isn’t running yet.
Testing with the wrong users. Getting feedback from friends, family, or team members is not MVP testing. You need feedback from people who actually have the problem you’re solving — recruit through the channel where your actual target user already spends time, not through whoever answers fastest in your network.
Ignoring negative feedback. Confirmation bias is real. Teams often dismiss negative feedback as outliers or user error. Take it seriously — it’s the most valuable signal you’ll get, precisely because it’s the signal everyone in the room is motivated to explain away.
Treating the MVP as the final product. An MVP is a learning tool, not a permanent artifact. Don’t get so attached to it that you can’t iterate based on what you learned — the moment a team starts defending the MVP’s architecture instead of the hypothesis it was built to test, it’s stopped being an MVP.
MVP vs Prototype vs Beta: What’s the Difference?
| Prototype | MVP | Beta | |
|---|---|---|---|
| Purpose | Explore/test design | Validate core assumption | Polish before launch |
| Users | Internal team | Real target users | Wider early adopters |
| Code quality | Throwaway | Production-capable | Near-production |
| Features | May be simulated | Minimum for real use | Most features present |
| Outcome | UX insights | Build/pivot/stop decision | Bug discovery, feedback |
Ship Your Riskiest Assumption This Week
Stop reading and write down the one assumption that, if wrong, would sink the thing you’re building. Not the safest one to admit to a stakeholder — the one that actually scares you. That’s your MVP’s job this week, not the polished version three sprints from now.
Pick the cheapest MVP type that can test it — concierge, Wizard of Oz, landing page, or single feature — and set a success threshold before you build anything, in writing, where you can’t quietly move it later. Learn. Then decide, honestly, even when the honest answer is to stop.
References
- Ries, Eric. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Business, 2011.
- Lean Startup Co. “What Is an MVP?” leanstartup.co
- Agile Alliance. “What is a Minimum Viable Product (MVP)?” agilealliance.org
- Cagan, Marty. Inspired: How to Create Tech Products Customers Love. Wiley, 2nd ed., 2018.
- Blank, Steve. The Four Steps to the Epiphany. K&S Ranch, 2013.
