What an MVP Actually Is
An MVP is not a bad version of your product. It is not a product with fewer features. It is not a product that looks ugly. It is not an excuse to ship garbage.
An MVP is the smallest thing you can build to test your riskiest assumption.
That definition matters. Most startups get it wrong by building too much. They think MVP means "version 1.0 but worse." It does not. An MVP is an experiment. Its purpose is to produce learning, not to produce a product.
If you launch your MVP and learn nothing new about your customers, you built the wrong MVP.
The Riskiest Assumption
Every startup is built on a stack of assumptions. An MVP tests the riskiest one — the one that, if wrong, kills the entire business.
Airbnb's assumptions:
1. People will let strangers sleep in their homes
2. Travelers will prefer homes to hotels
3. A marketplace can match hosts and guests
4. People will trust an online platform for this
Riskiest assumption: #1 — Will people actually let strangers into their homes?
Airbnb's MVP did not need a beautiful booking system, sophisticated search, or a review platform. It needed to answer one question: will real people in a real city let strangers pay to sleep in their spare rooms?
Their MVP was a simple website, photos of their own apartment, and three guests at a design conference in San Francisco. That was enough to validate assumption #1. Everything else came after.
Your MVP framework:
1. List all your assumptions
2. Rank them by risk (if wrong, how dead are we?)
3. Build the smallest thing that tests #1
4. Ship it and measure
5. If validated, move to assumption #2
What MVPs Actually Look Like
The most effective MVPs often do not look like software products at all.
The Landing Page MVP
Buffer tested demand for a social media scheduling tool with a landing page. The page described the product, had pricing tiers, and a "Sign Up" button. Clicking "Sign Up" showed a message: "We're not quite ready yet. Leave your email."
No code. No product. Just a landing page and a Mailchimp list. Joel Gascoigne had 120 email signups in the first week. That was enough evidence that people wanted the product. Then he built it.
What Buffer's landing page tested:
- Do people want to schedule social media posts? (Yes)
- Will people pay for it? (Signups on paid tiers said yes)
What it did not test:
- Can we build the product? (Irrelevant until demand is proven)
- Will people stick around? (Cannot test without a product)
Cost: One page, one afternoon
Learning: High enough to justify building
The Video MVP
Dropbox could not easily demonstrate their product with a prototype because syncing files seamlessly across devices is technically complex. So Drew Houston made a three-minute demo video showing how the product would work.
He posted the video to Hacker News. Signups went from 5,000 to 75,000 overnight.
The video was the MVP. It tested whether people wanted seamless file syncing badly enough to sign up for a waitlist. The answer was a resounding yes. Then they built the product.
The Concierge MVP
Food on the Table was a meal planning and grocery list service. Instead of building an app, the founder manually created meal plans for a single customer. He went to her house, asked what her family liked to eat, checked local grocery store sales, and emailed her a custom meal plan.
This tested the core assumption: will people pay someone to plan their meals? He did not need software to answer that. He needed one customer and a few hours of his time.
The Wizard of Oz MVP
Zappos started by posting photos of shoes from local stores online. When someone ordered, Nick Swinmurn went to the store, bought the shoes at retail price, and shipped them. There was no inventory, no warehouse, no supply chain.
This tested the riskiest assumption: will people buy shoes online without trying them on first? The answer was yes. Only after validating this did Zappos build actual e-commerce infrastructure.
The Single Feature MVP
Instagram launched as Burbn, a location-based check-in app with many features. Nobody used most of them. But people loved one feature: photo filters. Kevin Systrom and Mike Krieger stripped the app down to just photo taking, filtering, and sharing. They renamed it Instagram.
The MVP was not a "simple version of a photo app." It was the discovery that one specific feature — making your phone photos look good — was what people actually wanted.
How Small Is Small Enough
If your MVP takes more than four weeks to build, your scope is too big. Many successful MVPs were built in days.
Too big for an MVP:
- Full user auth with roles, permissions, password reset
- Comprehensive admin dashboard
- Multi-step onboarding flow
- Payment processing with subscriptions and refunds
- Email notification system with preferences
Right-sized for an MVP:
- Login with Google (one auth method, no passwords to manage)
- Hardcoded admin operations (you do them manually)
- One-screen onboarding or none at all
- Stripe Checkout link (handles everything)
- You manually send emails
The pattern: automate later, validate now. Anything that can be done manually for 10 users should be done manually for 10 users. Automation is for when you have 100 users and it is proven to work.
Identifying Your One Assumption
The hardest part of building an MVP is identifying what to test. Here is a framework:
Step 1: What is your startup's core thesis?
"People will pay for X because Y."
Step 2: Break it into testable assumptions.
- People have problem Y (problem exists)
- People currently solve Y with Z (existing solution exists)
- People find Z inadequate (opportunity exists)
- Our solution X is better than Z (value proposition)
- People will pay $N for X (willingness to pay)
- We can deliver X sustainably (feasibility)
Step 3: Which assumption is riskiest?
Usually it is "people have problem Y" or "people will pay $N."
Step 4: What is the cheapest test for that assumption?
Often it is a landing page, a manual service, or a conversation.
For most startups, the riskiest assumption is demand. Not "can we build it?" but "does anyone want it?" Engineers default to testing feasibility because building is comfortable. But the graveyard of startups is full of products that worked perfectly and nobody wanted.
Measuring MVP Success
An MVP without a success metric is just a side project. Before you build, define what success looks like.
Landing page MVP:
- Success: 200+ signups in the first week
- Failure: Under 50 signups
- Action if success: Build the product
- Action if failure: Change the value proposition and try again
Concierge MVP:
- Success: 5 out of 10 customers willing to pay
- Failure: Fewer than 2 willing to pay
- Action if success: Build automation for the service
- Action if failure: The problem is not painful enough
Single feature MVP:
- Success: 40%+ weekly retention after 4 weeks
- Failure: Under 20% retention
- Action if success: Expand features
- Action if failure: Wrong feature, try another
Do not move the goalposts after the experiment. If your success metric was 200 signups and you got 60, that is a signal. Rationalizing "well, we didn't promote it enough" is how startups die slowly.
The Anti-MVP: What Happens When You Build Too Much
The opposite of an MVP is a "full product launch." You spend six months building, polish every feature, write comprehensive documentation, and launch with a press release. This fails more often than it succeeds.
Color Labs raised $41 million before launch and built an elaborate photo-sharing app. They spent months on technology and design. When they launched, nobody cared. The product solved a problem that did not exist. They could have learned this in a week with a landing page.
Google Wave was built by a large team over two years. It was technically impressive — real-time collaboration, federated protocol, rich media support. Users were confused by it. Google shut it down within a year. A simpler experiment could have revealed the confusion months earlier.
Juicero built a 100 million in funding. Then someone discovered you could squeeze the packs by hand. A prototype and ten customer interviews would have surfaced the fundamental value proposition problem.
The pattern: the more you build before testing, the more painful the lesson when the market says no.
Time to learn you're wrong:
- Landing page MVP: 1-2 weeks
- Concierge MVP: 2-4 weeks
- Single feature MVP: 4-6 weeks
- Full product launch: 3-6 months
- Elaborate product: 6-12 months
Cost of being wrong:
- Landing page: $0 + a weekend
- Concierge: $0 + your time
- Single feature: 1-2 months of engineering
- Full product: 3-6 months of engineering + team morale
- Elaborate: Potentially the whole company
Common Pitfalls
Building a product instead of an experiment. If your "MVP" has a settings page, you built too much. Strip it down to the one thing that tests your one assumption.
Testing the wrong assumption. Engineers love testing "can we build this?" But if nobody wants it, the answer is irrelevant. Test demand before testing feasibility.
Ignoring negative results. Your MVP showed that nobody wants your product. That is painful but valuable. Do not ignore it and keep building. Pivot.
Confusing an MVP with a demo. A demo shows what your product does. An MVP tests whether anyone cares. If your MVP does not produce data, it is a demo.
Perfectionism. The MVP looks bad. The UI is ugly. The flows are clunky. This is fine. If the core value proposition works, users will tolerate rough edges. If it does not work, no amount of polish will save it.
Skipping the M in MVP. "Minimum" does the heavy lifting in the term. If you cannot bring yourself to cut scope, you are building a v1, not an MVP.
Key Takeaways
- An MVP is the smallest thing that tests your riskiest assumption. Not a bad version of your product.
- Identify your riskiest assumption before building anything. Usually it is "does anyone want this?"
- The most effective MVPs are often not software: landing pages, videos, manual services, or single features.
- If your MVP takes more than four weeks to build, your scope is too big.
- Define success metrics before you launch. Do not move the goalposts.
- Do anything manually for 10 users before automating it for 100.
- The purpose of an MVP is learning. If you did not learn something new, you built the wrong MVP.