What Is an MVP? Minimum Viable Product Explained

Most new products fail because nobody wanted them, not because they were built badly. The minimum viable product, or MVP, is the idea that you should find that out as cheaply as possible, before spending a year building something the market ignores. The term is everywhere in startups and product teams, and it’s often misunderstood.

The short answer: an MVP is the smallest version of a product that lets you test your key assumption with real users: do people actually want this, and will they use or pay for it? It’s not a rough first draft of the full product; it’s an experiment. It should be minimum (only what’s needed to learn) and viable (good enough that people can get real value from it). The term was coined by Frank Robinson around 2001 and popularised by Eric Ries in The Lean Startup. Famous examples include Dropbox’s demo video and Zappos photographing shoes in local stores.

Why MVPs matter

Building a full product before anyone uses it is a big bet on a guess. You might be right about the problem but wrong about the solution, right about the solution but wrong about who’ll pay, or wrong about all of it. An MVP swaps that single big bet for a series of small, cheap tests.

The payoff is learning speed. Eric Ries described the loop as build, measure, learn: build the smallest thing that tests an idea, measure how real people respond, and learn whether to keep going, change direction, or stop. The faster you go round that loop, the sooner you find something people want, which is the path to product-market fit.

What minimum and viable actually mean

The two words pull in opposite directions, and getting the balance right is the whole skill.

• Minimum means cutting everything that isn’t needed to test your main assumption. No settings page, no admin dashboard, no second user type, no perfect design.
• Viable means what’s left still solves the core problem well enough that people get value. If it’s too broken or too thin to use, you’ll learn nothing except that people don’t like broken software.

A useful picture: if you’re testing whether people want to get from A to B faster, don’t build a wheel, then an axle, then a chassis. Build a skateboard. It’s crude, but it gets someone from A to B, and you’ll learn from how they use it.

Famous MVP examples

Dropbox. Before building the full syncing product, Drew Houston made a short video showing how it would work. The waiting list jumped from about 5,000 to 75,000 sign-ups, which proved demand before the hard engineering was done.

Zappos. To test whether people would buy shoes online, Nick Swinmurn photographed shoes in local shops and posted them on a simple website. When someone ordered, he bought the pair at full price and shipped it. No inventory, no warehouse, just a test of demand.

Airbnb. The founders rented out air mattresses in their own San Francisco flat during a busy design conference, using a basic website. It tested whether strangers would pay to stay in someone’s home.

Buffer. Joel Gascoigne put up a landing page describing a tool for scheduling tweets, with a pricing page, before building anything. Enough people clicked through to the plans to convince him it was worth building.

Types of MVP

Not every MVP is a stripped-down app. Choose the cheapest one that tests your riskiest assumption:

Type	What it is	What it tests	Example
Landing page	A page describing the product with a sign-up or pre-order button	Whether people are interested	Buffer
Explainer video	A short demo of how the product would work	Demand for a hard-to-build idea	Dropbox
Concierge	You deliver the service by hand to a few customers	Whether the solution solves the problem	A founder doing meal planning over email
Wizard of Oz	Looks automated to the user, but people run it behind the scenes	Whether users want the experience	Zappos
Single-feature product	A real product that does one thing well	Whether people use and return	An early version of most apps
Pre-sale or crowdfunding	Customers pay before it’s built	Willingness to pay	Kickstarter campaigns

How to build an MVP, step by step

1. Write down your riskiest assumption. For example: “Freelance designers will pay $10 a month to send invoices from their phone.”
2. Define who it’s for. One specific group, not everyone.
3. Pick the one core job. The single thing the product must do to test the assumption. Here: create and send an invoice.
4. Cut everything else. Reports, recurring invoices, multiple currencies, team accounts can all wait.
5. Choose the cheapest test. Could a landing page with a price answer the question? Could you send invoices by hand for ten designers first?
6. Set success criteria before launch. For example: “30 sign-ups in two weeks, and 10 people sending a second invoice.”
7. Launch to real users and measure behaviour. What people do matters more than what they say.
8. Decide: persevere, pivot, or stop. Then run the next test.

Step 6 is the one people skip, and it’s the one that makes an MVP honest. Without a target set in advance, any result can be spun as a success.

Common MVP mistakes

• Building too much. If it’s taken six months, it’s a version one, not an MVP.
• Building too little. A product so buggy nobody can use it doesn’t test demand.
• Asking instead of watching. People say they’d use things they never will. Measure sign-ups, usage, and payment.
• Testing on friends. Friends are kind. Test with strangers who have the problem.
• Not deciding anything. An MVP that doesn’t lead to a clear next step wasn’t really an experiment.

MVP vs prototype vs proof of concept

These get mixed up often:

• A proof of concept checks whether something is technically possible. Usually internal.
• A prototype shows how something would look and work, to test usability or get feedback. Often not fully functional.
• An MVP is released to real users to test whether they want it.

Before building an MVP, a product team usually writes a short spec of the problem, the user, and what’s in and out of scope. That’s what a product requirement document is for.

MVP thinking for your job search

The MVP idea works well outside products, too. Job seekers often spend weeks perfecting one resume before sending it anywhere. The MVP approach: get a solid version out, apply to a handful of well-matched roles, see which versions get responses, and improve from real feedback.

The key is that each application is tailored enough to be a fair test. A generic resume that gets no replies tells you nothing about whether you’re a fit. Tailr tailors your resume from the job listing you’re viewing, drafts a cover letter, and tracks each application, so you can see what’s working and adjust. If you’re interviewing for product roles, you’ll almost certainly be asked about MVPs, so it’s worth reading what a product manager actually does too.

Related guides

• RICE, MoSCoW and Kano: Prioritization Frameworks for PM Interviews
• 10 Terms You Should Know Before a Product Management Interview

Conclusion

An MVP is the smallest version of a product that tests whether people actually want it. It has to be minimal enough to build quickly and viable enough to deliver real value. Start from your riskiest assumption, choose the cheapest test that answers it, set success criteria in advance, and let real user behaviour tell you what to do next. Dropbox, Zappos, Airbnb and Buffer all started this way.

Try Tailr to send tailored applications and learn from what gets replies.