MVP Meaning: What Minimum Viable Actually Means

Before Zappos had a warehouse, Nick Swinmurn photographed shoes in stores near him and put the pictures on a website. When someone ordered a pair, he went back to the store, bought it at full price, and shipped it. Each sale lost money. That was fine, because the business wasn't trying to make money yet. It was trying to find out whether people would buy shoes online without trying them on, and a handful of orders answered that question for almost nothing.

That is the MVP meaning the people who popularized the term had in mind: the smallest thing you can put in front of real customers that tells you whether a key assumption about them is true.

Where the term came from

Frank Robinson, of the product development consultancy SyncDev, is usually credited with coining "minimum viable product" around 2001. Steve Blank's customer development work and Eric Ries's The Lean Startup (2011) made it common vocabulary.

Ries defines the MVP as the version of a product that lets a team learn the most about its customers for the least effort. The unit of output is learning. A release that ships on time but leaves the team no more certain about whether anyone wants it has not done the job, however small it was.

That definition also explains why an MVP doesn't have to be software. Swinmurn's shoe photos were an MVP. So was the short video Drew Houston made showing how Dropbox would sync files, before most people could use the product. Ries reports that the beta waiting list went from about 5,000 to 75,000 people overnight after the video went up.

What "minimum" and "viable" each rule out

The two words pull in opposite directions, and most bad MVPs come from honoring only one of them.

Minimum rules out anything that doesn't bear on the question. If you are testing whether small accounting firms will pay for automated invoice reminders, you don't need a settings page, an admin role, dark mode, or a second integration. Every extra feature adds build time and also adds noise: when people use the product, you can't tell which part they came for.

Viable rules out anything that can't produce a trustworthy answer. A reminder tool that fails to send half its reminders will tell you nothing about demand, because people will leave over the bugs. Viable means that the part being tested works well enough that a customer's reaction is a reaction to the idea itself.

Henrik Kniberg's widely shared drawing makes this point with vehicles. If the customer needs to get from A to B, building a wheel, then a chassis, then a car gives them nothing usable until the end. Building a skateboard, then a scooter, then a bicycle gives them something that moves at every step. In the article that accompanied it, Kniberg suggested replacing "MVP" with a sequence of terms (earliest testable, earliest usable, and earliest lovable product) because so many teams read "minimum" as "a part of the final thing."

Four kinds of MVP

Concierge MVP

You deliver the service by hand, openly, to a few customers. A meal-planning startup might start by having a person write each customer's weekly plan in a spreadsheet and email it. The customer knows a human is doing the work.

This is the right format when you don't yet know what the service should do. Doing it by hand for ten customers shows you which steps they care about before you automate any of them.

Wizard of Oz MVP

Same manual work as a concierge MVP, hidden from the customer, who sees what looks like a finished product. Zappos was a Wizard of Oz MVP: the website looked like a shoe store, and the fulfilment was Swinmurn driving to the mall. It suits a team that knows roughly what the product should do and wants to see whether customers use it in that form. Be careful with anything involving personal data or promises about automation; if customers would object to a human reading their information, this format needs their consent first.

Fake door test

You add a button, a menu item, or a pricing tier for a feature that doesn't exist yet, and measure how many people click it. Those who click see a message explaining the feature is coming and, ideally, a way to leave their email.

A fake door measures interest cheaply. A click costs nothing, so click-through overstates real demand. Pair it with a follow-up step that costs the user something, such as joining a waitlist or booking a call, and count those instead. Show the message honestly and don't run fake doors on actions people depend on, like checkout, where a dead end damages trust.

Single-feature MVP

You build one feature, properly, and ship it to a small audience. This is the closest to what most teams mean by MVP, and it is the most expensive of the four. Teams pick it when the question can only be answered by real usage over time, such as whether people come back to the feature every week.

If you can answer the same question with one of the cheaper three formats, start there.

MVP, prototype, and proof of concept

These three get used interchangeably, and they answer different questions.

	Answers	Who sees it	Typical form
Proof of concept	Can we build this?	The team	A technical spike, a script, a test harness
Prototype	Can people use this?	Test participants	Clickable mockups, paper screens, a coded demo
MVP	Will people want and use this in real life?	Real customers	Any of the four formats above

A prototype is tested in a session where participants are asked to try it. An MVP is put in front of customers who choose, on their own, whether to use it. The difference shows up in the data: a participant in a usability test will complete a task because you asked, while a customer will only come back if the product is worth their time. The prototyping tools comparison covers the tools for the prototype stage.

Writing the hypothesis before the build

An MVP without a written hypothesis can't fail, which means it can't teach you anything. Before building, write down three things:

1. The assumption. "Owners of small accounting firms will pay to stop chasing unpaid invoices themselves."
2. The test. "A concierge service sending reminders by hand for 15 firms over six weeks, at $49 a month."
3. The threshold. "At least 8 of 15 firms still paying after the second invoice cycle."

Teams skip the threshold more than any other part. Without it, any result can be read as encouraging: twelve sign-ups looks like traction to someone who wanted it to work and like failure to someone who didn't.

Choose the riskiest assumption to test first. If the plan depends on customers wanting the outcome, on them paying for it, and on you being able to deliver it at a sensible cost, start with whichever one you have the least evidence for. User interviews can narrow that list before you build anything. The business model canvas is a useful map of which assumptions the plan rests on.

Signals that an MVP worked

Good MVP signals involve customers giving up something: time, money, data, or effort.

• Payment or a commitment to pay. A pre-order, a deposit, a signed letter of intent.
• Return use without prompting. Customers coming back in weeks two and three.
• Workarounds. Customers bending the MVP to do something it wasn't built for, which points to the job they actually hired it for.
• Disappointment at removal. Sean Ellis's survey asks how people would feel if they could no longer use the product. A large share answering "very disappointed" is a stronger signal than any satisfaction score.

Weak signals cost the customer nothing: page views, compliments in an interview, likes, and survey answers about what people would do in the future. When an MVP is on the edge, a controlled comparison helps; the A/B testing guide covers when a split test is worth running and when the sample is too small for one.

Three ways teams get MVP wrong

One is treating the MVP as a first release with fewer features. The team spends four months on a reduced version of the full product, launches it, and only then asks whether anyone wanted it. That's a small product, not an MVP, because no question was set before the build and no threshold was agreed.

Another is treating "minimum" as permission to ship something broken. If customers leave because the core action fails, the test has measured quality, not demand. The minimum lovable product is one attempt to correct this reading.

Some teams never leave the MVP stage. An MVP that hits its threshold has answered one question, and the next test should go after the next riskiest assumption.

FAQ

What is the MVP meaning in product development?

MVP stands for minimum viable product: the smallest version of a product, service, or test that lets a team learn whether a key assumption about its customers is true.

Who coined the term minimum viable product?

Frank Robinson of SyncDev is generally credited with coining it around 2001. Steve Blank and Eric Ries popularized it, Ries mainly through The Lean Startup in 2011.

Does an MVP have to be software?

No. A landing page, a demo video, a manual service delivered by email, or a spreadsheet can all be MVPs, as long as real customers interact with it and their behaviour answers the question you set.

How long should an MVP take to build?

Long enough to make the tested part work, and no longer. For concierge and fake door tests that's often days. A single-feature MVP built in code can take several weeks. If the estimate runs to months, the scope probably includes things the hypothesis doesn't need.

What is the difference between an MVP and an MLP?

An MLP, or minimum lovable product, asks the first version to be something customers enjoy using. The term grew out of MVPs shipped in such poor condition that the test ended up measuring their flaws.

Is the MVP meaning different outside software?

Yes. In sport, MVP means most valuable player, the award for the best performer in a season or a game. In software architecture it can also mean Model-View-Presenter, a pattern for structuring UI code. In startups and product management it means minimum viable product.

Further reading

The product insights hub has more on research methods, product strategy, and the frameworks product teams use to decide what to build next.

Sources: Ries, E. (2011), The Lean Startup · Blank, S. (2005), The Four Steps to the Epiphany · Kniberg, H. (2016), "Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable."