A minimum viable product is not a stripped-down, buggy version of a real idea — it’s a deliberate experiment built to answer one question as cheaply as possible: will anyone actually want this? The “minimum” refers to effort, not quality, and the “viable” half of the phrase matters just as much as the first.
Where the Term “MVP” Actually Comes From
The concept was popularized by entrepreneur Eric Ries in his 2011 book The Lean Startup, building on ideas he developed while working at IMVU. Ries defined an MVP as “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” The emphasis sits on learning, not on shipping something smaller. Ries has even said building an MVP is “quite annoying” for most teams, because it forces founders into real customer conversations, real metrics, and honest analysis rather than simply building what they assume customers want.
Why “Minimum” Doesn’t Mean Sloppy
A common misreading treats “minimum” as license to cut corners on quality. In practice, an MVP still has to work well enough for early users to form a genuine opinion about it. If the product is so broken that people can’t use it, the test fails before it starts — you only learn that broken software is broken, nothing about whether the underlying idea has merit. The goal is the smallest version that can still generate trustworthy signal from real users, not simply the smallest version.
How Long Building One Should Take
There’s no fixed timeline, and Ries has been explicit that it varies by situation. He has described one venture that took nearly five years before its first MVP reached customers, and says IMVU’s own original MVP took about six months to build. By contrast, he has also pointed to teams that spent two weeks building a feature a simple ad campaign could have tested in days. The right scope depends entirely on the specific assumption being tested and how fast a real answer can be gotten.
What MVPs Have Actually Looked Like
Some of the most famous startups began with MVPs that look nothing like their current products. Uber’s earliest version, UberCab, let San Francisco riders request a black car by text message — there was no app yet, and the founders used that manual process to test whether people would actually pay for the experience before investing in engineering. Spotify’s first version was a simple landing page built to test whether streaming technology could play music quickly and reliably enough to satisfy both users and skeptical record labels, with early revenue coming from on-page ads rather than subscriptions. Amazon itself started as an online bookstore run out of a garage, and customer buying patterns — not a five-year roadmap — drove its later expansion into electronics, clothing, and everything else.
How You Know When an MVP Is Done
Ries frames the MVP not as a single deliverable but as the first lap of a build-measure-learn loop, where customers, not founders, decide what counts as “minimum.” If early users are satisfied and the team has learned what it needed, further polish can wait. If they’re not, that’s a signal to iterate and test again, not proof the idea has failed. He also cautions that not every project needs this discipline: building something to scratch a personal itch, or for a quick flip rather than a sustainable business, can make the whole MVP framework unnecessary overhead.