What Is an MVP? The Real Definition and Why Most Founders Get It Wrong

What Is an MVP? The Real Definition and Why Most Founders Get It Wrong

Ask ten founders what MVP stands for and all ten will say "Minimum Viable Product." Ask them what that means and you will get ten different answers, most of them wrong.

The confusion is not accidental. The term has been stretched, distorted, and misappropriated to justify everything from buggy prototypes to full-featured launches. Getting the definition right matters because building the wrong thing under the right label is still building the wrong thing.

The Original Definition

Eric Ries coined the term in "The Lean Startup," published in 2011. His definition was precise: "A minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort."

Notice what is emphasized: validated learning. Not shipping fast. Not cutting corners. Not having the minimum number of features. The MVP is a learning instrument. It exists to answer a specific question about whether your assumption about customer behavior is true.

Ries was influenced by Steve Blank's customer development work, which argued that startups should treat every product decision as a hypothesis to be tested rather than an assumption to be built on. The MVP is the lowest-cost test of the most important hypothesis.

The Three Things an MVP Must Have

The word "minimum" gets all the attention, but "viable" and "product" are doing just as much work in the definition.

Minimum

Minimum does not mean broken. It does not mean ugly. It does not mean missing core functionality. It means the smallest set of features that allows the hypothesis to be tested with real users in a real context.

What is minimum depends entirely on what you are trying to learn. If your hypothesis is "users will pay $99 per month for a tool that automates expense reporting," your minimum is everything required to let a user actually automate an expense report and pay for it. Anything else is out of scope.

Viable

Viable means it works well enough to deliver actual value to an actual user. A product that crashes, produces wrong results, or creates more work than it saves is not viable - it is a prototype. Viable means someone can complete the core task and walk away having received real value.

This is where most so-called MVPs fail. They ship something that technically exists but does not actually work well enough for honest evaluation. You cannot learn whether users will pay for a value proposition they have not genuinely experienced.

Product

Product means it is offered to real users in a real context, not shown in a controlled demo environment. A product has users. Those users have found it on their own or been recruited through realistic channels. They are using it without you holding their hand through every step.

A product is not the same as a demo. In a demo, you control the conditions. In a product, the conditions are real. The gap between demo and product is where most hypotheses get invalidated.

What an MVP Is Not

An MVP Is Not a Prototype

A prototype is a tool for internal exploration. You build it to understand what you are building and to communicate it to your team. A prototype tests whether a solution is buildable. An MVP tests whether a solution is wanted.

Prototypes are usually not shown to customers in an uncontrolled context. MVPs must be.

An MVP Is Not a Demo

A demo is a curated presentation of what your product could do under ideal conditions. It is useful for sales, fundraising, and internal alignment. It is not a test of real behavior.

When you demo to someone, you are in control. You guide them through the best path. You skip the rough edges. A real product puts users in an uncontrolled environment and watches what actually happens.

An MVP Is Not a Buggy First Version

"Buggy but functional" is a false reading of "minimum." Shipping a product full of bugs is not a lean strategy - it is just shipping a bad product. Bugs do not just create a poor experience. They make it impossible to evaluate the underlying value proposition because users cannot tell whether they are unhappy with your idea or with your execution.

An MVP Is Not a Full Feature Set Released Quickly

Some teams treat MVP as a synonym for "version 1." They build every planned feature, rush to launch, and call it their MVP. This misses the point entirely. The purpose of the MVP framework is to ship less, learn faster, and avoid building features nobody needs.

The Difference Between an MVP and a POC

A Proof of Concept (POC) answers the question "is this technically possible?" A POC might be an internal prototype, a technical spike, or a demo that proves a technology works. It does not need to be shown to real users. It might run on a developer's laptop.

An MVP answers the question "do real users want this enough to change their behavior?" It requires real users in realistic conditions.

A POC comes before an MVP. If you are not sure whether your technical approach is feasible, build a POC first. Once you know it can be built, build the MVP to find out whether it should be.

Famous MVPs - What They Actually Were

Dropbox

Dropbox's MVP was a video. Drew Houston recorded a three-minute demo showing how Dropbox would work. He shared it with Hacker News. Overnight, the beta waitlist went from 5,000 to 75,000 people.

There was no software. There was no product to download. There was a video demonstrating a product that did not yet exist. The hypothesis was "people want effortless file synchronization across devices." The test was the video. The result was validated demand.

Airbnb

The Airbnb MVP was a simple website where the founders offered air mattresses in their San Francisco apartment for $80 per night during a design conference. No sophisticated booking system. No trust infrastructure. No global inventory.

The hypothesis: "Strangers will pay to sleep in other strangers' homes." The test: three guests who paid and had a good experience. The validated learning: yes, people will do this.

Zappos

Zappos did not build a shoe warehouse or an inventory system to start. Nick Swinmurn walked into local shoe stores, photographed the inventory, posted the photos online, and when someone placed an order, he went back to the store, bought the shoes at retail, and shipped them to the customer.

The business was completely unscalable. The economics were terrible. But the hypothesis - "people will buy shoes online without trying them on" - was tested at near-zero cost before a single warehouse or fulfillment system was built.

How to Scope Your MVP Correctly

The right way to scope an MVP starts with the hypothesis, not the feature list.

1. Write the hypothesis in the form: "We believe [type of user] will [do this behavior] because [reason]."
2. Define what evidence would prove it true or false. What does success look like after 30 days? What metric tells you the hypothesis is validated?
3. Work backwards from the evidence. What is the minimum experience that gives a real user a real shot at producing that evidence?
4. Cut everything else. If a feature is not required to test the hypothesis, it does not belong in the MVP.

Use our MVP Planner to work through this scoping process and get a structured output you can use with a development team.

The Landing Page MVP vs the Functional MVP

Not every MVP needs to be working software. Sometimes the hypothesis can be tested with much less.

Landing Page MVP

A landing page MVP is a website that describes a product that does not yet exist, with a call to action (sign up, join waitlist, purchase). It tests whether there is demand before anything is built.

This works when: the hypothesis is about demand, not usability. If you want to know whether people want a product, a landing page MVP can tell you before you build it.

This fails when: the value is in the experience itself. If your hypothesis requires users to actually use the product to determine its value, a landing page cannot answer the question.

Functional MVP

A functional MVP is working software that delivers the core value proposition to real users. It is the right choice when the hypothesis cannot be tested any other way.

The functional MVP should be designed, tested, and working - just limited in scope. It is not a shortcut on quality. It is a shortcut on breadth.

What Comes After the MVP

The MVP is not the product you will eventually ship to the world. It is the tool you use to validate the foundation before you build on it.

After an MVP, you have one of three situations:

• Validated: Users are doing the thing you hoped, retention is positive, and there is evidence of willingness to pay. Now you can invest in scaling.
• Partially validated: Some things are working, some are not. You iterate and test again.
• Invalidated: Users are not doing the thing, retention is poor, or nobody will pay. You pivot or stop.

The faster you get to one of these outcomes, the less you have wasted on building the wrong thing. That is the entire point of the MVP.

If you are working through what your MVP should include, use our MVP Cost Calculator to get a sense of what building it will cost, and read our guide on How Long It Takes to Build a Web App for realistic timeline expectations.

Ready to build your MVP with a team that understands what an MVP actually is? Get a free quote or estimate your project to start the conversation.