With the right vision, appropriate resources, and more than a sprinkle of luck, a really good idea can quickly become a sensational success. When that happens, as late-night comedian John Oliver might say, such an idea becomes “a thing.”

Unfortunately, when a good idea becomes “a thing” — like the product equivalent of John, Paul, George, and Ringo – the quality can suffer if too many producers try to put their imprint on the hit record. The idea can get watered down, generalized, and misused.

One such sensation in our recent past was the concept of minimum viable product – first popularized Eric Ries’ book, “The Lean Startup.”  It is a concept, now more than a decade old, that refers to a product that is introduced to the market with the absolute minimum set of features to allow it to be deployed, and to collect learning from actual customers.

In theory, launching a minimum viable product means getting the product into user hands quickly, so you can prioritize ongoing work based upon actual customer feedback. The "minimum viable" part of that paradigm is the safety gate that helps to minimize feature creep, while holding to release schedules.  

It also helps teams that the idea fits quite nicely into the Agile development methodology that many development teams have implemented, while also fortifying the startup-growth hacking idea of using operational performance to drive marketing approaches. As a result, engineering execs and CEOs can talk about it with investors under the banner of capital efficiency.

So: What’s not to like?  In my opinion — plenty. I certainly believe that every one of the objectives that I mentioned is possible—however, as MVP has become a thing, it has also been tainted, in some cases, by human nature, and used in ways that can create poor results. Here are some oft-quoted statements about the purpose of MVP, and my take on their truth or falsehood:

1. Getting an MVP to market lets you maximize learning from actual customers. True, with a caveat. Product and engineering managers will say that early adopters are the target for MVPs. But early adopters in B2B markets don’t evaluate products the same way as pragmatic, early majority buyers do. The value proposition that appeals to them can be quite different. Developing feature sets purely to serve the early adopters is wrong-headed, in my opinion. Engaging with them feels right, because these early adopters are quite happy to spend time talking with you about new product concepts and doing online trials, but the reasons noted they can be driving you directly down a product improvement path that is overkill.
   
   
2. MVPs minimize feature creep.  Partially true – see above.
   
   
3. MVPs help development teams make release schedules. True. But, let’s get real. Is this because the team has correctly identified what is truly minimally viable?  Or is this because the concept of viability has been repeatedly scaled back in a bid to stick to a release schedule? Academically, the MVP concept works, but not when human nature uses it to frame development slips.
   
   
4. Making release schedules is not the same as getting to market on time. True. In B2B markets, direct and indirect selling teams get confused about MVPs. Remember that in theory, a MVP is just a step on the way to the complete product. “Minimum viable” is the minimum required to deploy to some customers. But when MVPs get "launched" commercially, sales and channel reps expect “minimum viable” to support their ability to sell to typical customers. The gap between the needs of “some” and “typical” customers can cause tremendous problems with messaging and wasted sales effort. Other than for minimally disruptive innovations, freemium, or very low-cost software products, going to market with a MVP is best accomplished through strictly limited channels.
   
   
5. MVPs fit quite nicely into an Agile development methodology.  Again, true – with caveats. Here, the problem is more about how Agile is adopted than with just the MVP concept.  Agile methods tend to be useful when criticality is low. New and disruptive products entering new markets, particularly in complex B2B markets, don't qualify as “low criticality,” in my opinion. So, when I see startups or new business units launching new products into new markets using what they describe as an Agile development process, I always do a quick gut-check. If I find that the level of process disruption to the customer or to the value chain is going to be high, the alarm bells ring. The combination of “Agile” and “MVP” concepts together can create an ingrained go-to-market approach that pre-wires the process for friction, if not failure.
   
   
6. The MVP concept fits nicely with growth hacking, using quick-start operational efforts to drive different marketing initiatives. Partially true. If the product is largely a continuous innovation that maps into what customers are already comfortable with, if “minimum viable” is truly fulfilled, and if the customer process or value chain isn’t significantly disrupted, then great!  If not, just make sure that early sell-cycle analytics, such as visits to landing pages, download, trials, product feedback, are viewed in context with analytics about customers that actually purchase. Otherwise, the perceived insights from trials can just validate value propositions and features that fit users who have no ability to buy after trial, or who want capabilities that the part of the market with funding could really care less about.

Of course, one of my objectives in poking holes in the MVP idea is to be a bit controversial. In fact, I am actually a huge fan of the MVP idea and of Ries’ Lean Startup. Even so, the dangers need to be carefully managed in order to take mitigation steps. Now that the MVP idea has become a thing, we’re best served by making sure it’s not used out of context or used to serve purposes other than delighting the customer.