Every startup founder eventually hears the phrase “just ship the MVP” — but the term is one of the most misunderstood in the startup lexicon. A minimum viable product isn’t a stripped-down, buggy version of your real idea. It’s a deliberate experiment designed to answer one question as cheaply as possible: will anyone actually want this?

What Is a Minimum Viable Product? Where the Term Came 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 is on learning, not on shipping a smaller product. As Ries has put it, building an MVP is actually “quite annoying” for most teams, because it forces founders to invest real energy in customer conversations, metrics, and honest analysis rather than simply building what they assume customers want.

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 that early users can form a genuine opinion about it. If the product is so broken that people can’t use it, you learn nothing about whether the underlying idea has merit — you just learn that broken software is broken. The “viable” half of the phrase matters as much as the “minimum” half: the goal is the smallest thing that can still generate trustworthy signal from real users.

How Long Should It Take?

There’s no fixed timeline, and Ries has been explicit that judgment calls vary by situation. He has described one venture that took nearly five years before its first MVP reached customers, and IMVU’s original MVP took about six months to build. By contrast, he’s also pointed to cases where teams spent two weeks building a feature that a simple ad campaign testing demand could have validated in days. The right scope depends on what specific assumption you’re testing and how fast you can get a real answer.

What It Looks Like in Practice

Some of the most famous startups began with MVPs that look nothing like their current products. Uber’s earliest version, known as 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 expansion into electronics, clothing, and everything else.

Knowing When You’re Done

Ries frames the MVP not as a single deliverable but as the first step in a build-measure-learn loop: customers, not founders, decide what counts as “minimum.” If early users are satisfied and the team has learned what it needed to, further polish can wait. If they’re not, that’s a signal to iterate and test again — not to declare the idea a failure. He also cautions that not every project needs this discipline: if you’re building something to scratch a personal itch or for a quick flip rather than to build a sustainable business, the MVP framework may simply be unnecessary overhead.