MVP - Minimum Viable Product - Startup Super School

What Is an MVP?

A Minimum Viable Product (MVP) is the most stripped-down version of a product that still delivers enough value for early adopters to use it - and enough instrumentation for the team to learn from that usage.

The concept was popularized by Eric Ries in The Lean Startup and builds on Steve Blank’s customer development methodology. The central insight is simple: you don’t know what customers want until they tell you with their behavior, not just their words.

Why It Matters

Building a full-featured product before validating demand is one of the most common - and costly - startup mistakes. An MVP lets you:

Test your core assumption cheaply and quickly
Collect real behavioral data instead of relying on surveys
Iterate based on evidence, not intuition
Preserve runway for when you find what actually works

What an MVP Is NOT

A buggy, half-finished product you’re embarrassed to show
A prototype or mockup (though those can be part of the process)
The smallest thing you can build in a weekend
An excuse to ship something broken

An MVP must solve a real problem well enough that someone chooses to use it over doing nothing.

Types of MVPs

Type	Description	Best For
Landing Page	Describe the product, measure sign-ups	Early demand validation
Concierge	Manually deliver the service before automating	Service/marketplace ideas
Wizard of Oz	Fake automation behind the scenes	AI/automation products
Piecemeal	Assemble with existing tools (Zapier, Airtable)	Workflow products
Single Feature	Ship only the one core feature	Software products

The MVP Spectrum

Think of MVP not as a fixed point but as a spectrum:

Smoke Test → Prototype → MVP → MMP → Full Product

Smoke Test: Does anyone want this? (landing page, waitlist)
Prototype: Can it be built? (mockup, demo)
MVP: Will they use it? (bare-bones working product)
MMP (Minimum Marketable Product): Will they pay for it and tell others?

Common Mistakes

Building too much - perfectionism kills MVPs. Ship when you’re embarrassed.
Wrong success metric - define what “validated” means before you build.
Wrong audience - launch to your ideal early adopter, not everyone.
No feedback loop - an MVP without a mechanism to learn from users is just a bad product.

Key Takeaway

The goal of an MVP is not to build a product - it’s to learn as fast as possible whether you’re solving a real problem for real people. Speed of learning beats speed of building.

Frequently Asked Questions

What is the difference between an MVP and a prototype?

A prototype tests feasibility and design - it is typically non-functional or clickable only. An MVP is a working product that delivers real value to early adopters and is instrumented to capture behavioral data. The prototype answers 'Can it be built?' while the MVP answers 'Will they actually use it?'

How long should it take to build an MVP?

Most MVPs should take 4–12 weeks to build. If it is taking longer, the scope is almost certainly too large. The goal is to test your most critical assumption as quickly as possible - every extra week of building is a week without real user feedback.

Does an MVP have to be a software product?

No. An MVP can be a landing page, a manual concierge service, a Wizard of Oz simulation, or even a spreadsheet. The right form depends on what assumption you need to validate. If you need to test demand, a landing page with a payment CTA may be your MVP.

What is the most common MVP mistake founders make?

Building too much. Most founders treat MVP as version 1.0 rather than the minimum test of a single assumption. The result is months of development before getting any real user feedback. The famous rule: ship when you are embarrassed by it - if every feature feels polished, you have built too much.