UX glossary · engl. Minimum Viable Product
Minimum Viable Product
A minimum viable product (MVP) is the smallest usable version of a product. It lets you test with as little effort as possible whether real people actually want your idea.
Imagine a team with an idea for an app that lets neighbors lend each other tools. It could spend a year building profiles, reviews, calendars and payments. Or it could find out within a few weeks whether anyone actually wants to borrow tools through an app.
The second path leads to a minimum viable product.
Explained simply
A minimum viable product, or MVP, is the smallest version of a product that lets you learn from real people whether your idea holds up. “Minimum” means building as little as possible. “Viable” means just good enough that people actually use it. Think of it this way: before you open a restaurant, you can run a stall at the farmers’ market first. Do people buy, and do they come back?
The term is attributed to Frank Robinson, who coined it in 2001. It became widely known through Steve Blank and Eric Ries, author of “The Lean Startup”. Ries describes the MVP, in essence, as the version of a new product that lets a team collect as much validated learning about its customers as possible with the least effort. Validated learning means learning that is confirmed by what people actually do.
MVP or prototype?
The two often get mixed up. A prototype is a model to try things out. It may look real, but usually there is nothing behind the clicks, and it often gets thrown away after testing. An MVP, on the other hand, is a real, if very lean, version that people use in their everyday lives. A prototype tells you whether people understand something and can use it. An MVP tells you whether they actually want it.
An MVP doesn’t even have to be software. Among other examples, Ries mentions a landing page or an ad that measures interest in an offer before it exists. You can read more in Minimum Viable Product (MVP): What UX Designers Should Know.
An example
Back to the tool lending app. Before, the team plans twenty features and a launch in twelve months. After, it starts with a simple website for a single neighborhood: list your tools, send a request, and sort out the handover by message. After six weeks it turns out that drills and ladders are in highest demand and that many people want a deposit. These insights go into the next version instead of into an app that misses what people need.
Common misconceptions
An MVP isn’t a half finished product full of bugs. It does little, but it does that little well. If it’s so hard to use that people leave in frustration, all you learn is that the execution was poor, not whether the idea is any good. Good usability is part of an MVP too.
In practice
- Write down an assumption. Note what the MVP should prove or disprove and how you’ll measure it.
- Cut boldly. For every feature, ask whether the team would learn less without it. If not, it can wait.
- Plan for the learning. Decide up front when you’ll review the results and which outcome leads to which decision. The book Lean UX für kleine Teams (in German) shows what this looks like for small teams.
Related terms
Prototype, Lean UX, A/B Testing, User Research