minimum viable product

An MVP is not a bad version of your full product. It is not a prototype, a demo, or a v1. It is a tool for learning: the smallest thing you can ship that tests your most important assumption about whether the product will create value.

Why products fail without MVPs

Here is the failure pattern. A team identifies a problem. They brainstorm a solution. They design and build a full product over six to nine months. They launch. No one uses it. Six months of work, wasted.

The cause is almost always that they validated the wrong thing. They confirmed that users understood the problem. They did not confirm that users wanted the solution, would change their behavior to use it, or valued it enough to pay for it.

An MVP breaks this pattern by testing the riskiest assumption before building the full thing.

The MVP progression: expectations, satisfaction, delight

Users' relationship with a product moves through three levels:

Basic expectations (MVP territory): The product solves the core problem at minimum acceptable quality. Early adopters will use this. The broader market will not, yet.

Satisfiers: Features that generate steady growth in the customer base. Good to have, not critical to the initial value proposition.

Delighters: Unexpected features that attract specific segments and create strong loyalty. These come after the core is proven.

The MVP only needs to meet basic expectations for the specific user segment that is actively looking for a solution. That is your early adopter base.

Zappos is the canonical example. Nick Swinmurn's hypothesis: people will buy shoes online. His MVP: photograph shoes at local stores, post them to a website, manually buy the shoes and ship them when orders came in. No inventory. No digital infrastructure. The MVP was operationally painful and unscalable — but it tested the hypothesis. People did buy shoes online. Zappos built from there.

Airbnb: The founders' hypothesis: people will rent space in their home to strangers. MVP: post an ad offering air mattresses in their San Francisco apartment before a major political conference. People responded. The assumption was validated. They built from there.

Running an MVP experiment

Step 1: Listen to the customer. Who will buy this? Why? How? Before building anything, these questions need enough of an answer to proceed. Uber's founder observed that people wanted premium black cars but found them too expensive through traditional taxi companies. The problem was identified from direct observation.

Step 2: Identify your riskiest assumption. Any product involves many assumptions. Some are obvious — "users have this problem." Others are buried — "users will change their existing behavior to solve this problem." The riskiest assumption is the one that, if wrong, invalidates everything else.

For Uber: a reasonable riskiest assumption early on might have been "office-goers prioritize timeliness over price when booking rides." If that is wrong, the premium black car model does not work.

Step 3: Build a testable hypothesis. An assumption is not a hypothesis. A hypothesis is measurable, actionable, and has an outcome.

Assumption: "Users who complete onboarding are more likely to become active."
Hypothesis: "Users who complete the three-step onboarding flow will have a Day-7 retention rate at least 20% higher than users who do not."

The hypothesis version can be tested. The assumption cannot.

Step 4: Define minimum criteria for success.

This is the break-even point — the minimum result that validates the hypothesis.

Step 5: Plan and execute. Set up data collection for each success criterion. What data will be collected? Where does it come from? How much data is needed? Run the MVP with real users.

Step 6: Measure and learn. Collect feedback. Survey tools (Qualtrics, Google Forms, Typeform) are the common method. Live chat or direct calls supplement surveys for richer qualitative data. Analyze: did you validate or invalidate? What was unexpected? What do you build next?

The build-measure-learn loop

MVPs are not a single event. They are the first iteration of a continuous loop:

Build the minimum testable version → Measure user behavior and outcomes → Learn what is true or false about your assumptions → update your model → Build the next iteration.

Each loop reduces uncertainty. The product becomes better at serving its core users. As the core is proven, the investment increases — more features, more polish, more scale.

The product adoption curve maps directly to this: your MVP targets innovators and early adopters who are actively seeking a solution. As you validate assumptions and improve the product, you become viable for the early majority.