Our Dangerous Misunderstanding of Minimum Viable Product

700 466 David DeWolf

In a recent post on TechCruch, Bill Aulet writes that the tech community has come to have a “dangerous obsession with the MVP [minimum viable product].”

While I agree with him that over-pursuing minimum viable products can be the fastest way for a company to “go broke saving money,” I also believe we are at a point in time where something more damaging than an obsession with MVPs is the case.

There now seems to be dangerous and widespread misunderstandings of what a minimum viable product really is, some of which are perpetuated in the post. It’s essential that our industry come to a proper understanding of what an MVP is and is not in order to put it in its rightful place.

A minimum viable product, by definition, is one that requires the absolute smallest amount of development work necessary to gain customer feedback. The exact purpose of the MVP is exactly what Bill is asking for.

Sure, the MVP is no golden hammer and, as with all things, we can become overly reliant on it. However, what’s more dangerous is that his entire opinion is based upon a misunderstanding of what an MVP actually is. Let’s not throw the baby out with the bathwater.

The MVP was first brought to prominence in Eric Ries’ book The Lean Startup. In the book, Eric is quite clear that the entire purpose of the minimum viable product is to shorten the feedback cycle in order to obtain more customer feedback.

He even argues that sketches and mockups are quite sufficient MVPs early on in the product development cycle. Building in a vacuum – as Bill suggests working on MVPs and encourages companies to do – is the furthest thing from his mind.

To fully understand an MVP, it’s important for the industry to understand what it is not. An MVP is not a beta or initial release of a product. The objective of an MVP is not to grow revenue or capture market share.

The entire purpose of an MVP is to solicit valuable feedback in order to understand what could drive revenue, capture market share, and drive user adoption. It is simply a tool, not a result.

In other words, an MVP should never be positioned as the end goal – it is simply the first, second, and third step along the way to building a sustainable, market-ready product. The ultimate goal of the product development cycle is to build a sustainable product, not merely a viable idea.

A successful MVP will result in one of three outcomes: enough information to prove that the idea will not work, enough information to accelerate and build the full product, or enough information to show that there are valid concepts but the idea needs to “pivot.”

A successful product, on the other hand, results in real business results: revenue, market share, and user adoption.

A frequent objection and barrier to successfully deploying an MVP is the argument that “no one would ever use it.” Product managers and engineers are often challenged to envision what an incomplete, truly minimal product might look like, never mind understand why anyone would choose to use it.

In his book Crossing the Chasm, Geoffry Moore outlines the technology adoption cycle and the psychological profiles of each adoption group along the continuum. In the incubation stages of a product, where the MVP is most relevant, it is the “Innovator” (not even the early adopter) who needs to be attracted. These individuals are dominated by curiosity and intrigued by risk. They have a different psychological makeup than an early adopter or even the early majority.

Two common techniques – the Flintstone and the Steal Thread – can be used to help “pare down” a product concept to the minimally viable feature set.

The “Flintstone” refers to a product that is essentially “mocked up.” It has the appearance of being complete, but relies on manual processes where automation would typically be assumed by the user.

“CardMunch,” the app acquired by LinkedIn that processes pictures of business cards in order to convert them into digital contact cards, may be the most famous business to use this technique. In fact, it was so successful that Flintstoning remains a key differentiator for their business today.

In order to test the market and adoption, CardMunch made the decision to build only the functionality necessary to upload a picture of the business card from your smartphone. Unlike competitors in the space, they manually transcribed the business cards before pushing the results back to the user. Adoption exploded. Within five months they were acquired by LinkedIn and in less than a year they had processed their millionth business card. There was obviously a market.

However, what they learned was even more compelling. Their core differentiation became accuracy. By manually transcribing the business cards, they were able to do something others were unable to match with technology. If they had automated the process in the first place, they may have never discovered their true differentiator and their technology development efforts may have been a total waste.

The Steal Thread refers to a singular, core, feature that by itself would not make for a sustainable product.

Gmail is most likely the most famous product ever launched as a Steal Thread MVP. Phil Buchheit, the original creator, wrote, “The first version of Gmail was literally written in a day.” 

This original version was iterated upon and developed internally based on the feedback of “innovators” within Google before finally being rolled out to the public market as a “beta” release several years later. This feedback proved invaluable in helping to shape the product direction of Gmail to be focused on search rather than taxonomy.

The true problem is that as an industry we have bastardized the meaning of the MVP, not that we have become obsessed with it. Aulet is right in his notion that fixating on MVPs can be the fastest way to “go broke saving money.” Successful startups and enterprises, however, can embrace the original intent of the MVP, build incrementally, and, to Bill’s point, create value and leverage customer feedback along the way.