MVP (Minimum Viable Product)

Definition: The smallest version of a product that can be released to real users to test a core assumption, deliberately leaving out anything not essential to that test.

How It Works

Starts from a hypothesis about what users actually need, not a full spec of what the product could eventually become
Strips a product idea down to the minimum needed to learn whether the core value proposition resonates with real users
The goal is learning, not launching a polished product. An MVP can, and often should, look rough around the edges
Can be a real working product, a manual “fake it” process behind the scenes (a concierge MVP), or just a landing page with a signup form
Feedback from the MVP directly shapes what gets built next, replacing internal guessing with observed behavior
Once the assumption is validated or killed, the team either invests further or changes direction, instead of continuing to build on a guess
The riskiest assumption gets tested first. If the product depends on users paying for it, that’s what the MVP should test, not the UI polish
“Viable” is doing real work in the name: the product has to genuinely solve the user’s problem, even if clumsily, or the test measures nothing real
Scope is usually set by working backward from one success metric (signups, paid conversions, repeat usage) rather than a feature checklist
A good MVP has a clear kill criterion set in advance: a specific result that would mean the idea doesn’t work, decided before the data comes in and creates bias
An MVP is not one-and-done. Each release either confirms the next assumption or kills it, and the cycle repeats with a slightly less minimal product each time
Qualitative signal (what users say) and quantitative signal (what users actually do) are both collected, since the two frequently disagree

Common MVP types:

Concierge: the team manually delivers the service by hand behind the scenes, no automation at all (Zappos below)
Wizard of Oz: users interact with what looks like a working product, but a human is quietly doing the work behind it
Landing page: a description of the product and a call to action, before anything is built (Buffer below)
Single-feature: a full product stripped to just its one core feature, with everything else cut
Piecemeal: existing third-party tools are wired together manually to simulate the eventual product, before any custom code is written

Under the Hood

This loop, Build-Measure-Learn, comes from Eric Ries’s Lean Startup methodology. The point isn’t speed for its own sake, it’s minimizing the total time spent finding out whether an assumption is wrong. Each pass through the loop should be cheaper and faster than fully building the idea would have been.

Worked example: Zappos, a concierge MVP (1999)

Given:

Hypothesis to test: people will buy shoes online without trying them on first
Building real inventory and a warehouse system first would take months and real capital, all before learning if anyone would buy

Step 1, Build: founder Nick Swinmurn photographed shoes at local shoe stores and posted them on a simple website, with no actual inventory behind it.

Step 2, Measure: when an order came in, he went back to the store, bought the shoes at full retail price, and shipped them himself, at a loss on every sale.

Step 3, Learn: real orders arrived consistently. The core assumption, that people would buy shoes sight-unseen online, held up. That was enough evidence to justify building real inventory, warehousing, and logistics.

Answer: the MVP cost a small fraction of building a warehouse system, and it tested the one assumption that actually mattered before committing to the rest. Zappos was acquired by Amazon in 2009 for roughly $1.2 billion.

Worked example: Buffer, a landing-page MVP (2010)

Given:

Hypothesis to test: people want a tool to schedule social media posts in advance
Founder Joel Gascoigne had an idea but no working product yet

Step 1, Build: a two-page landing site. Page one described the idea; clicking “Plans and Pricing” led to page two, which said the feature wasn’t built yet and asked for an email address.

Step 2, Measure: click-through from page one to the pricing page, and how many people left an email address on page two, before a single line of the scheduling tool existed.

Step 3, Learn: enough signups came in to justify actually building the product. The pricing page also doubled as an early test of what people were willing to pay.

Answer: the entire test cost a weekend of work building two static pages. Buffer used the validated signups as the reason to start building, and later grew into a company serving hundreds of thousands of customers.

Why It Matters

Prevents months of engineering time going into a fully-featured product built around an assumption that turns out to be wrong
Gets a product in front of real users far earlier, when feedback is cheap to act on, instead of after launch, when it’s expensive
Forces a team to name its riskiest assumption explicitly, instead of building everything at once and hoping it all works
Converts “we think users want this” into “we watched users do this,” which is a much stronger basis for the next roadmap decision
Buys a startup or a new product line more shots on goal: the same budget that funds one full launch can fund several cheap MVP tests
Gives investors and internal stakeholders real evidence of demand instead of a pitch built entirely on projections
Reduces sunk-cost pressure: it’s far easier to kill a weekend’s work than to kill a feature six engineers spent a quarter building

Common Pitfalls

Confusing “minimum viable” with “low quality.” An MVP still has to actually work and solve the core problem, just without every extra feature
Building an MVP so stripped-down it can’t actually test the real hypothesis, which wastes the effort without producing a real answer
Treating the MVP as a permanent, minimal product instead of the first iteration of a larger one, and never coming back to build it out
Adding features “just in case” because they seem cheap, which quietly turns the MVP back into the full product it was meant to avoid building
Skipping the “measure” and “learn” steps entirely and treating “we shipped it” as success on its own
Testing with friendly early adopters only, then generalizing their enthusiasm to the broader market the product actually needs to win over
Picking a hypothesis so vague (“users will like this”) that no result from the MVP could ever disprove it
Ignoring negative or lukewarm signals because the team is emotionally invested in the idea already
Running the MVP for too short a window to see real behavior, especially for products with a slow adoption curve like B2B tools
Skipping the kill criterion entirely, so an ambiguous result gets quietly reinterpreted as a win after the fact
Letting the MVP’s manual, unscalable process (like Zappos’ own founder buying shoes at retail) run for so long that it becomes a hidden operational cost center instead of a temporary test

Comparison

	MVP	Prototype	MMP (Minimum Marketable Product)
Audience	Real users, real usage	Internal team, stakeholders, sometimes a few test users	Real, paying customers
Goal	Test a core assumption	Visualize or demo an idea before building it	Launch something sellable and competitive
Built to last?	Often thrown away or heavily reworked	No, disposable by design	Yes, production-grade
Feature set	Bare minimum to test one hypothesis	Whatever’s needed to demonstrate the concept	Enough to be genuinely competitive in market
Comes at what stage	Before product-market fit is confirmed	Before any real building starts	After the MVP has validated demand
Failure cost	Low, by design	Very low, nothing is shipped	High, real customers and revenue are on the line
Typical lifespan	Days to a few months	Hours to days	Years, becomes the core product
Who sees it	External, real users	Internal, or a closed test group	External, the general market

An MVP sits between the two: more real than a prototype because actual users depend on it, less complete than an MMP because it’s not trying to win the market yet, only to prove the market exists. Teams often move through all three in sequence on the same idea: prototype to sanity-check the concept internally, MVP to test it on real users, MMP once the assumption is proven and it’s time to actually compete.

Example

Before writing a single line of the file-syncing engine, Dropbox founder Drew Houston posted a three-minute screencast video demonstrating the product as if it already worked, narrating features like automatic folder sync that hadn’t been built yet. The video, posted to Hacker News and Digg in 2007-2008, is widely reported to have grown the beta waitlist from around 5,000 to roughly 75,000 signups almost overnight, without a working product behind it, giving Dropbox strong evidence of demand before committing to the harder engineering work of building reliable file sync across platforms.

Both Dropbox’s video and Zappos’ concierge approach share the same underlying move: neither team built the actual product first. They built the smallest possible thing that could produce a real yes-or-no answer from real people, and only invested in the hard engineering after that answer came back yes.

Product-Market Fit — what an MVP is ultimately trying to find evidence of
User Story — the format used to scope exactly what the MVP does and doesn’t include
A/B Testing — a complementary way to validate a specific change once the MVP already has real users
Product Roadmap — where the next build cycle gets planned once the MVP’s learnings come in

Dig deeper

Spot an error in this note?