What Is a Minimum Viable Product (MVP)? How to Build One That Actually Validates

Project Management

A Minimum Viable Product (MVP) is the simplest version of a product that can be released to test a specific hypothesis about its value with real users, generating the learning needed to decide whether and how to invest further. The MVP concept, popularized by Eric Ries in The Lean Startup, is grounded in a single insight: the most expensive type of product failure is building something nobody wants after spending months or years in development. An MVP tests the core assumptions of a product idea before that investment is made.

The critical word is “viable” — an MVP is not a low-quality or incomplete product. It is the minimum that is necessary to genuinely test the product’s core value proposition with real users in real conditions.

What an MVP Is Not

The MVP concept is widely misunderstood. Common misconceptions:

An MVP is not a prototype: A prototype demonstrates a concept visually; an MVP tests a real value hypothesis with real users. Users interact with a prototype to give design feedback; users interact with an MVP to potentially solve a real problem.

An MVP is not a version 1 with all features cut: Some teams call their first software release an MVP even when it’s a substantially complete product. A true MVP is built specifically to test assumptions, not to be a scaled-back version of the final vision.

An MVP is not necessarily software: MVPs can take many forms — a landing page, a manual service, a Wizard of Oz demonstration, a concierge experience — depending on what assumption needs to be tested.

An MVP is not the goal: The MVP is a learning vehicle, not a deliverable. The goal is validated learning, not the MVP itself.

The Defining Principle: Test the Riskiest Assumption

The most important MVP design question is: what is the riskiest assumption underlying this product idea, and what’s the smallest thing we can build to test it?

Riskiest assumptions typically fall into three categories:

Desirability: Do users actually want this? Will they use it to solve the problem it’s designed to solve?

Feasibility: Can we actually build what we’re imagining in a way that works reliably?

Viability: Will users pay for this? Can we build a sustainable business around it?

The MVP should be designed to test the assumption that, if wrong, would most undermine the product’s fundamental value — not to test all assumptions simultaneously.

Types of MVPs

Landing page MVP: A webpage describing the product and collecting email signups or pre-orders before the product exists. Tests interest and willingness to engage.

Concierge MVP: The team manually delivers the service that the product would eventually automate. Airbnb’s founders manually photographed hosts’ apartments; the product eventually automated the listing process.

Wizard of Oz MVP: Users interact with what they believe is a working product, but humans are providing the service behind the scenes. Tests the value of the end experience without building the automation.

Single-feature MVP: A software product built with only the single most critical feature — the one capability that represents the product’s core hypothesis — without any supporting features.

Paper prototype: A hand-drawn representation of the product tested with users to validate core interaction assumptions before any digital design work begins.

How to Know When Your MVP Has Done Its Job

An MVP has served its purpose when the team has enough evidence to make a confident decision: proceed with the current direction (validate), adjust the approach (pivot), or stop investing in this idea (abandon). The learning from the MVP should change the team’s next decision in a meaningful way.

Key Takeaways

The MVP is the discipline of learning before building — testing the most critical assumptions about a product’s value before committing to the full investment required to build it. Teams that practice genuine MVP thinking consistently build products that are better aligned with real user needs, because they’ve validated their assumptions rather than acting on them. The goal is not to ship a minimal product; it’s to learn as much as possible with as little waste as possible.

Share this article