What Is an MVP? Types of Minimum Viable Products With Examples

A minimum viable product, or MVP, is the simplest version of a product that lets a team learn what real customers want and will pay for. The word that matters is "learn." An MVP isn't a rough draft of the finished product. It's an experiment built to answer a question you can't answer by thinking harder.

Plenty of founders hear "MVP" and picture a stripped-down app with a handful of features. That's one possibility, but often it's the slowest and most expensive way to run the test. Some of the most useful MVPs contain no working product at all.

This guide covers where the term came from, the main types of MVP, a few well-documented examples, and a practical way to decide what goes in. It sits inside the startup fundamentals collection and follows naturally from the idea stage.

What an MVP is, in the founder's own words

Eric Ries, who popularized the term through the Lean Startup movement, defines it in a post titled a guide to the minimum viable product as "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort."

Read that closely. The definition has no features in it. It talks about learning, customers, and effort. A team that ships something small but learns nothing from it hasn't built an MVP. A team that learns a lot from a landing page has.

On the same page, Ries says plainly that MVP, "despite the name, is not about creating minimal products." He also stresses that the definition uses "maximum and minimum" and is "decidedly not formulaic," meaning it takes judgment to decide what makes sense in a given situation.

The Lean Startup site frames the MVP as the second step in a sequence: first figure out the problem that needs solving, then develop an MVP "to begin the process of learning as quickly as possible." That learning feeds the build-measure-learn loop, which the same page calls a core component of the method. If you want the full method, read the Lean Startup method article.

Where the term came from

Ries made the term famous, but he wasn't the first to use it. A write-up on the 20th anniversary of the MVP credits Frank Robinson, CEO of SyncDev, with introducing "minimum viable product" in 2001 as part of his firm's SyncDev methodology. It quotes Robinson's definition: "The MVP is the right-sized product for your company and your customer. It is big enough to cause adoption, satisfaction and sales, but not so big as to be bloated and risky."

SyncDev's own site defines an MVP as "the unique product that maximizes return on risk for both the vendor and the customer." Notice the difference in emphasis. Robinson's framing is about the right-sized product for a customer and a vendor. Ries's framing is about learning. Both are still in use, and they sometimes get blended together, which is one reason the term is so slippery.

MVP types at a glance

There's no official list. The categories below are common working labels among startup teams, and the boundaries overlap. Treat the table as our own summary of the patterns, not a standard.

Landing page or smoke test

You describe the product as if it exists, then measure how many people take a meaningful step: join a waitlist, enter an email, or click through to a price. Ries himself mentions the idea in his MVP guide, noting that "a simple AdWords smoke test would have revealed how utterly bad the concept was" for a feature his team had spent two weeks building.

Buffer is the well-known example. Founder Joel Gascoigne wrote on the Buffer blog that his first test was a simple two-page landing site, then he added a pricing page between the landing page and the email signup so the extra click would show who was genuinely interested. Only after those signals did he build the working product, which took seven weeks of evenings and weekends, and he got his first paying customer within four days of launch.

Explainer video

When a product is hard to describe in text, a short demo can stand in for it. The best-known case is Dropbox. In a guest post on TechCrunch, Ries wrote that for Dropbox "the video was the minimum viable product." The post says the video drew more than 10,000 Diggs within 24 hours and that, in its words, the beta waiting list "went from 5,000 people to 75,000 people literally overnight."

One caution. Attention isn't the same as demand. A video can win clicks from people who'd never become customers, so check that the audience reacting matches the buyer you need.

Concierge MVP

In a concierge MVP, you do by hand what the software would eventually do. If you're thinking about a meal-planning app, for example, you might personally plan meals for five households each week. You learn what customers want, what they ignore, and where the real value is, long before you write code. It's slow and doesn't scale, and that's the point: scaling comes later, once you know what's worth scaling.

Wizard of Oz MVP

Here the customer sees something that looks and feels like a finished product, but a person is working behind the curtain. Zappos founder Nick Swinmurn described an early version of this to Fortune: he told a local shoe retailer, "I'll take some pictures, put your shoes online, and if people buy them, I'll buy them from you at full price." No warehouse, no inventory, just a test of whether people would buy shoes online. Some teams would call that a Wizard of Oz test and others a concierge one, which shows how fuzzy the labels are.

Piecemeal MVP

You stitch together existing tools: a form, a spreadsheet, a payment link, an email tool. The customer gets the outcome and you spend almost nothing on engineering. A productized service often starts this way, sold as a fixed offer and delivered with a few connected tools.

Single-feature MVP

You build the one feature that delivers the core promise and leave everything else out. This is the version people usually picture. It works best when you're confident about the problem and unsure only about the solution.

Key Facts

Key Facts: Minimum Viable Products

• Eric Ries defines the MVP as that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.
• Ries also writes that MVP, "despite the name, is not about creating minimal products".
• The Lean Startup site describes the MVP as the step where you begin learning as quickly as possible, after identifying the problem to solve.
• A 20th-anniversary retrospective credits Frank Robinson of SyncDev with introducing the term in 2001.
• Per Ries's TechCrunch post, Dropbox's demo video served as its MVP and the beta waiting list grew from 5,000 to 75,000 people overnight.
• Joel Gascoigne built Buffer's first test as a landing page plus a pricing page before writing the product, then took seven weeks to build it.
• The MVP types in this article are common working labels, not a formal standard.

MVP vs prototype vs MLP vs RAT

These terms get mixed up. A rough way to keep them straight:

"Minimum lovable product" is an informal label some teams use to push back on bare-bones releases; there's no single authoritative definition, so check how a team is using it. The riskiest assumption test is often a better first move than an MVP, because it narrows the test to one belief. Many MVPs are really RATs wearing a bigger costume.

Common misreadings of "MVP"

"It's just a cheap version 1." Ries is explicit that an MVP isn't about producing minimal products. A cheap v1 can be perfectly designed and still teach you nothing if no one measures what customers do with it.

"Minimum means bad." The "viable" half of the name matters. If the experience is so poor that no customer can judge the idea fairly, you've learned about your execution, not your market. A thin product can still be good at the one thing it claims to do.

"An MVP must be software." Several of the best-known examples above contained little or no software.

"Launch it and wait." An MVP only counts if you plan what you'll measure and what result would change your mind. Ries notes that getting learning from the first iteration often takes "energy invested in talking to customers or metrics and analytics."

"One MVP is enough." Most teams run several, each answering a different question. The first might test interest, the next whether people will pay, and a later one whether they come back.

How to decide what goes in

A workable process has five steps.

1. Name the riskiest assumption. What has to be true for this business to work? Customers have the problem, they'll pay, they'll find you. Pick the one most likely to be false. The riskiest assumption test guide covers this in detail.
2. Write the learning goal as a sentence. "We'll learn whether operations managers at small logistics firms will join a paid pilot." If you can't write the sentence, you're not ready to build.
3. Choose the cheapest type that answers it. Use the table above. If a landing page can answer the question, don't build an app. If you need to see how people behave with the real workflow, go concierge or Wizard of Oz.
4. Set a success threshold before you start. Decide in advance what number or behavior counts as a yes. Otherwise any result will look encouraging.
5. Cut everything that doesn't serve the test. A feature goes in only if removing it would make the learning unreliable.

A clearly hypothetical example: a founder wants to sell a tool that auto-schedules appointments for dental clinics. The risky belief is that clinic managers will pay for scheduling help at all. A single-feature app would take months. A concierge test, where the founder manually manages scheduling for three clinics for a month, answers the question much faster, and shows which parts of the work are actually painful.

When the learning comes in, the team decides whether to keep going, change direction, or stop. That's the idea behind validated learning and the Lean Startup's persevere-or-pivot decision. The growth experimentation framework covers how to structure repeated tests once a product is live, and lean software development is a related set of ideas from the engineering side.

After the MVP

A good MVP result isn't a finished product. It's a decision. Strong signals, such as people paying, returning, or asking for more, justify building further and moving toward product-market fit. Weak signals tell you to change the problem, the audience, or the solution. Either way, you spent far less than you would have on a full build. Keep an eye on burn rate as you go, because the real constraint on learning is how many experiments your cash allows. If you're still deciding which customer to test with, start with a few conversations before you build anything, as outlined for the idea stage.

Related reading

• Idea stage of a startup
• Pre-seed startups
• Riskiest assumption test
• Lean Startup method
• Productized service