Along with principles like agile, lean, and just-in-time production, the principle of MVP—minimum viable product—is a popular buzzword in business. Especially among start-ups and small businesses with tight budgets. (Well, big businesses also have tight budgets, but in a small business, it’s much more personal.)

Except it looks to me as if many entrepreneurs might be missing the essence of MVP. I see it in businesses that waste time and money, ugly and buggy products, and services that fail to satisfy customers’ needs.

MVP too often turns out to be too much M and too little V.

MVP can be a powerful antidote to the perfectionist’s trap of failing to launch until the product is perfect, but pushing crap out the door swings the pendulum too far. Both scenarios lead to failure: customers either have nothing to buy, or there’s no demand for an inferior product.

The key to any successful MVP design is to intimately understand the customer’s needs. But how do we know whether our design will earn customer happiness points? How can we tell if our MVP is too minimal or truly viable?

Customer surveys, prototypes and opinion polls can cheaply give us some useful early indicators of demand. But they’re only indicators.

The only reliable way to validate our design is this: “Has a stranger bought it?”

Your real customers are not friends or family giving sympathy votes, or beta testers who get free access. Validation through actually selling the product is the only test for viability—the crux of MVP—does it give value to the customer?

Also key is that the M of MVP doesn’t mean incomplete, but simple. The point of M is to invest the least effort and cost to test what works. But an incomplete product probably won’t satisfy the customer’s need. This holds true for every stage of your MVP development path.

For example, early versions of Google Docs had only about 3% of MS Word’s functionality, yet it was a complete product—all functions worked—and it satisfied users' needs for simplicity and collaboration. (A Smart Bear)

Google Docs now has much more complexity than its early versions, yet the development path involved a series of complete products, albeit simpler versions of the final result.

This aligns with principle #1 of the Agile Manifesto’s 12 principles: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” (2001)

Contrast this with the waterfall lifecycle, which many newbies conflate with agile and MVP principles. For example, developing a software system might involve building the database, then the front-end user interface, then the functionality. Although this is an incremental development approach that seems consistent with agile principles, none of the product iterations has value to the customer until the last release.

In other words, it's unlikely you'll get to sell the final, complete version of your product if your development path doesn’t deliver products that customers value at every single stage.