Minimum Viable Product (MVP): Meaning & Examples [2026]
A. Togay Koralturk, Best-Selling PMP Author
Last updated on July 29, 2026
12 min read
The idea behind a minimum viable product is simple: before spending a year building something, ship the smallest useful version, learn how real users respond to it, and let that learning shape what you build next. Yet it's one of the most misunderstood concepts in product development — teams routinely confuse "minimum viable" with "cheap and unfinished," and ship junk in its name. A real MVP is minimal and genuinely usable, built to learn rather than to impress. This guide explains the minimum viable product in full — what it means, where it came from, how it differs from a prototype, how to build one, real examples, and how it appears on the PMP and CAPM exams.
What is a minimum viable product (MVP)?
A minimum viable product (MVP) is the version of a new product with just enough features to be usable by early customers, who then provide feedback that guides its future development. Rather than building a complete product and hoping people want it, a team builds the smallest usable version, releases it to real users, and learns from how they respond.
The concept balances two words that pull in opposite directions. Minimum means the least you can build — the smallest slice that still tests your core idea. Viable means it must actually work and deliver real value; it has to be something a customer can genuinely use, not a broken fragment. The whole point is learning: an MVP exists to answer the question "do customers actually want this, and will they use it?" with the least possible time and money spent finding out. It's less a product strategy than a learning strategy — a way to test your biggest assumptions against reality before betting everything on them.
The origin of the MVP
The term "minimum viable product" was coined by Frank Robinson around 2001, but it was Eric Ries who popularized it in his 2011 book The Lean Startup, where it became a cornerstone of a whole movement. Ries built on the customer-development ideas of Steve Blank, framing the MVP as the engine of a scientific, experiment-driven approach to building companies and products.
The concept's roots run deeper still, into lean thinking and its obsession with eliminating waste. From that lineage, the MVP inherits a simple conviction: building features nobody wants is the biggest waste of all, so the smartest move is to build the minimum needed to learn whether you're on the right track before investing further. This is why the MVP is so closely tied to lean project management and to agile more broadly — all three share the belief that delivering something small and real, then learning from it, beats elaborate upfront planning. The MVP is essentially lean-startup thinking applied to the very first version of a product.
Ready to take the next step in project management?
200,000+ Learners Trust Our Instructors
The purpose: validated learning
The purpose of an MVP is validated learning — testing your most important assumptions about a product against real customer behavior, with the least possible effort. Every new product rests on hypotheses: that customers have a particular problem, that they'll value your solution, that they'll actually use it. An MVP is how you test those hypotheses cheaply, before they cost you a year of development.
This plays out through the build–measure–learn loop at the heart of the Lean Startup. You build the MVP, measure how real users respond to it, and learn whether your assumptions held — then decide whether to iterate on the idea or pivot to a different one. The power of the loop is that it replaces opinion with evidence: instead of arguing about what customers might want, you put something real in front of them and watch. This dramatically reduces the biggest risk in product development — spending enormous effort building something nobody actually wants. An MVP won't guarantee success, but it makes failure cheap and fast, which is often just as valuable.
"Minimum" vs. "viable": the balance
The hardest part of an MVP is getting the balance between its two words right, and it's where most teams go wrong. Lean too far toward minimum and you ship something broken or useless — a product so bare it tells you nothing, because no one can actually use it. Lean too far toward viable and you over-build, spending months adding features "just in case" until the MVP is neither minimal nor a fast way to learn. A good MVP is the narrowest possible product that still delivers genuine value for its core use case.
A famous analogy from Henrik Kniberg captures this perfectly. Imagine a customer who wants a car. The wrong way to build an MVP is to deliver a wheel, then a chassis, then a body — none of which is usable until the very end. The right way is to deliver a usable means of transport at each step: a skateboard, then a scooter, then a bicycle, then a motorcycle, and finally the car. Each version is minimal but genuinely usable, gets the customer moving, and generates feedback that shapes the next. The lesson is that "minimum" never means "half-finished" — it means the smallest complete, usable thing. An MVP is a skateboard, not a car with three wheels missing.
MVP vs. prototype vs. proof of concept
MVPs are often confused with prototypes and proofs of concept, but the three test different things and aren't interchangeable. The simplest way to tell them apart is to ask what question each one answers.
| What it tests | Who it's for | What it is | |
|---|---|---|---|
| Proof of concept (POC) | Can we technically build this? | The internal team | A small experiment, not a product |
| Prototype | How should the product look and work? | The team and select users | A mockup or model, often non-functional |
| MVP | Will real customers find value in this? | Real early customers, in the market | A usable, releasable product with core features |
A proof of concept answers a feasibility question (is this technically possible?) and never leaves the building. A prototype answers a design question (how should this look and behave?) and is usually a mockup you show to test the experience. An MVP is the only one of the three that answers a market question (will real customers actually value and use this?), because it's a genuine product released to genuine users. In practice a team might use all three in sequence: prove it's buildable, prototype the design, then release an MVP to learn whether the market wants it. Confusing them is a common and costly mistake, because a prototype shown to stakeholders tells you nothing about whether customers will pay.
How to build an MVP
Building an MVP is a disciplined process of narrowing down to what matters most, then releasing and learning. A typical path:
- Identify the problem and the user. Be clear about whose problem you're solving and what that problem actually is — the MVP exists to test whether that problem is real and worth solving.
- Define your core hypothesis and value. Pin down the single most important assumption the MVP needs to test, and the core value it must deliver to do so.
- Choose the one essential feature. Identify the minimum functionality that delivers that core value. Ruthlessly cut everything that isn't essential to testing the hypothesis.
- Build the minimal usable version. Create the smallest version that genuinely works for the core use case — minimal, but viable.
- Release it to real users. Get it in front of actual early customers, not just internal stakeholders, so you learn from real behavior.
- Measure, learn, and iterate. Track how users respond, learn whether your hypothesis held, and decide whether to iterate on the idea or pivot.
The discipline is in step three: the temptation is always to add "just one more" feature, and resisting it is what keeps an MVP minimal enough to build and release quickly. Start with the smallest thing that can teach you something real, and let what you learn drive what you build next.
MVP examples: Dropbox, Airbnb & more
Some of the best-known products started as remarkably scrappy MVPs, which makes the concept concrete:
- Dropbox didn't build its full syncing product to test demand. It released a simple explainer video demonstrating how the product would work, and measured the surge in sign-ups — validating that people wanted it before building the hard technology.
- Airbnb began when its founders rented out air mattresses in their own apartment and built a basic site to test whether strangers would pay to stay in someone's home. The minimal experiment proved the concept.
- Zappos tested whether people would buy shoes online by photographing shoes in local stores and posting them; when someone ordered, the founder bought the pair and shipped it. It validated demand without any inventory or warehouse.
- Amazon started as an online store selling only books — a deliberately narrow beginning that proved the model before expanding into everything else.
The pattern across all of these is the same: each company found the cheapest possible way to test its riskiest assumption with real customers, rather than building the full product first. The MVP wasn't a smaller version of the final product so much as a clever experiment to learn whether the final product was worth building at all.
Benefits and pitfalls
Used well, the MVP approach offers powerful advantages, but it's easy to get wrong:
- Benefit — faster to market and to learning: releasing a minimal version gets real feedback far sooner than building the full product, so the team learns what works while there's still time to act on it.
- Benefit — reduced risk and waste: by validating demand before heavy investment, an MVP avoids the biggest waste in product development — building something nobody wants.
- Benefit — early feedback and adopters: real users shape the product's direction, and early adopters can become advocates and a source of momentum.
- Pitfall — confusing "minimum" with "low quality": shipping something broken or useless in the name of an MVP damages trust and teaches you nothing, because no one can use it.
- Pitfall — not learning from it: an MVP that's released but never measured wastes the entire point; the value is in the learning, not just the shipping.
The overarching risk is treating the MVP as a way to ship less rather than to learn faster. Done right, it's an experiment with a clear hypothesis and a plan to measure the result; done wrong, it's just an excuse for a poor first version. The teams that benefit are the ones that stay honest about what they're trying to learn.
MVP on the PMP® and CAPM® Exams
Because the current PMP exam emphasizes agile and hybrid delivery and, above all, value delivery, the MVP fits naturally into its content as a way of delivering value early and validating assumptions. The exam frames this idea through concepts like the minimum viable product and the related minimum business increment — the smallest release that delivers value and generates learning — and treats releasing a usable increment early as a way to reduce risk.
Situational questions tend to reward incremental, learning-driven delivery over big-bang launches. Watch for scenarios where a team or stakeholder wants to build everything before releasing anything, where assumptions about customer needs are untested, or where risk could be reduced by delivering and validating a small usable version first — the right answers favor releasing an MVP to learn. The key nuance the exam expects you to grasp is that an MVP must be genuinely usable, not a low-quality throwaway. Our PMP Complete Study Guide, the most complete on the market, covers value delivery and incremental release as the exam frames them. If you're learning product and project fundamentals rather than sitting an exam, our Complete Project Management Course teaches these concepts from the ground up.
PMP Practice Question: MVP
A team is starting a new product with a twelve-month plan and a fixed budget to build the complete, fully featured offering before releasing anything. The project manager pushes back on the big-bang release, and the room produces three alternatives: the marketing lead wants to validate demand with a landing page and pre-orders before any build, the lead engineer proposes shipping a stripped-down version of every planned feature so customers see the full vision early, and the sponsor suggests keeping the plan but adding quarterly internal demos for course correction. The team still worries that anything "minimum" will feel low quality and hurt the brand.
Which approach should the project manager recommend?
a) Validate demand first with the landing page and pre-orders, and start building only once enough customers commit.
b) Build the single core feature to full quality, release it to a segment of real users, and expand based on what they do with it.
c) Ship the stripped-down version of every planned feature at once, so early customers experience the complete product vision.
d) Keep the twelve-month plan and add the quarterly internal demos so stakeholders can course-correct along the way.
Correct answer: B.
Rationale: A minimum viable product is minimal in scope and viable in quality: one core job, done well enough that real users can genuinely rely on it, released so their actual behavior — not their stated interest — steers the investment. That definition is exactly what separates b) from its rivals: a thin slice of every feature is minimal without being viable at anything, and confirms the team's low-quality fear; a landing page with pre-orders measures what people say before any value exists, and asks for money against a promise, which is its own brand risk; and quarterly internal demos gather feedback from the people already invested in the plan, so the riskiest assumption — that the market wants this — stays untested for a year. Building the core feature to full quality also directly answers the reputational objection, because viability is the brand protection. To drill this kind of value-delivery judgment, work through our PMP practice exams or, at the entry level, our CAPM practice exams.
Ready to take the next step in project management?
200,000+ Learners Trust Our Instructors
Frequently asked questions
What is a minimum viable product (MVP)?
A minimum viable product is the version of a new product with just enough features to be usable by early customers, who then provide feedback that guides its future development. Rather than building a complete product upfront, a team builds the smallest usable version, releases it to real users, and learns from how they respond. Its purpose is validated learning with the least possible effort and risk.
Where does the term MVP come from?
The term "minimum viable product" was coined by Frank Robinson around 2001 and popularized by Eric Ries in his 2011 book The Lean Startup, building on Steve Blank's customer-development ideas. It has roots in lean thinking and its focus on eliminating waste — in this case, the waste of building features or products that customers don't actually want.
What is the difference between an MVP and a prototype?
A prototype is usually a non-functional mockup used to test a product's design and experience, typically shown to the team and a few select users. An MVP is a real, usable, releasable product with core features, given to actual customers to test whether they find genuine value in it. A prototype answers a design question; an MVP answers a market question about real customer demand.
Does minimum mean low quality?
No. This is the most common misunderstanding of the MVP. An MVP must be both minimum and viable — the smallest version that still genuinely works and delivers real value for its core use case. It should be a small but complete and usable product, like a skateboard as a first step toward a car, not a broken or half-finished version. Shipping low-quality work in the name of an MVP defeats its purpose.
How do you build an MVP?
To build an MVP, identify the problem and the target user, define your core hypothesis and the value the product must deliver, and choose the single essential feature that tests it. Then build the smallest genuinely usable version, release it to real early customers, and measure how they respond so you can learn whether to iterate or pivot. The discipline is in ruthlessly cutting anything that isn't essential to what you're trying to learn.
What are some examples of MVPs?
Well-known MVP examples include Dropbox, which used a simple explainer video to validate demand before building its syncing technology; Airbnb, whose founders rented out air mattresses in their own apartment to test the concept; Zappos, which photographed shoes in local stores and only bought them when ordered, validating demand without inventory; and Amazon, which began by selling only books. Each tested a risky assumption cheaply with real customers.
Is the MVP on the PMP exam?
Yes. The current PMP exam emphasizes agile, hybrid delivery, and value delivery, and the minimum viable product appears as a way to deliver value early and validate assumptions. You are expected to understand that releasing a usable increment early reduces risk and enables learning, and to recognize that an MVP must be genuinely usable rather than a low-quality throwaway. The related idea of a minimum business increment may also appear.
Is the MVP on the CAPM exam?
Yes. The CAPM covers agile and value-delivery concepts including the MVP, usually a little more directly than the PMP — often testing its definition, its purpose of validated learning, or the difference between an MVP and a prototype. Because the CAPM is scenario-based, you should also be ready to recognize when releasing a minimum viable product is the best way to reduce risk on a new product.
Burnup Chart in Agile: Example & vs. Burndown [2026]
A burnup chart plots work completed and total scope as two lines, so scope stays visible. An example, how to read it, burnup vs. burndown, and the PMP exam.
Agile Release Planning: Process & Levels [2026]
Agile release planning maps features across sprints toward a release. The planning levels, date vs. scope, how to forecast with velocity, and PMP exam tips.
Kanban: Boards, WIP Limits & Kanban vs Scrum [2026]
Kanban is a visual, flow-based agile method. The kanban board, WIP limits, its 6 practices, kanban vs. scrum, metrics, when to use it, and PMP exam tips.
