A really good idea can quickly become a norm in the tech sector. The late night comedian John Oliver might say that such an idea becomes “a thing” (as in “is that really “a thing?”)  But, when a good idea becomes a thing it can also get watered down, generalized, and miss-used when compared with itsoriginal intent.

In my opinion, one such “thing” that is invoked regularly by product teams is the concept of minimum viable product (MVP) that was popularized in Eric Ries’ book, “The Lean Startup.”  If you aren’t involved with software or other tech products, you might not realize this is actually a thing. The concept has been around for a decade, but it took on the elevated status of “a thing” to me by 2014 when it was exemplified on the television series Silicon Valley [season 1, episode 1].  I won’t spend much time here rehashing it, but the link above provides plenty of reference sources. Cliff’s notes: an MVP is 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 fast so that you can prioritize ongoing work based upon actual customer feedback. “Minimum viable” helps minimize feature creep. It helps teams achieve release schedules. The idea fits quite nicely into the Agile development methodology that many development teams have implemented. Engineering execs and CEOs can talk about it with investors under the banner of capital efficiency. And, it fits quite nicely into the startup growth-hacking idea of using operational performance to drive different marketing approaches over time.

So… what’s not to like?  In my opinion… plenty. I certainly believe that every one of the objectives that I mentioned is possible, reasonable, and viable in certain circumstances. My issue is that as it has become a thing, it has also been regularly co-opted by human nature and used in ways that can create poor results.

1. Getting an MVP to market lets you maximize learning from actual customers. Product and engineering managers will say that early adopters are the target for MVPs. This makes sense for products and services introduced direct via the web to consumers or prosumers, using a process and value chain that is already in place. It also makes sense when the company has direct access to friendly customers of the same type that it wants to market to generally. But in many B2B launches these assumptions are just not true. Early adopters in B2B markets don’t evaluate products the same way, and they certainly don’t buy the same way that the early majority does. They may not actually buy at all. The value proposition that appeals to them is different, perhaps opposite to the one that appeals to visionary or pragmatic manager who represents most of the market. Developing feature sets purely to serve the early adopters is often 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 for all the reasons noted they can be driving you directly down a product improvement path that is overkill.
2. MVPs minimize feature creep.  Well…. ibid.
3. MVPs help development teams make release schedules.  Yes!  But, let’s get real. Is this because the team has correctly identified what is actually viable?  Or is this because the concept of viability got cut back again and again while rationalizing the 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. 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. Communication helps, but there’s just a huge gulf between “some” and “typical” customer needs. Other than for minimally disruptive consumers, freemium, or very low cost software products sold to end users, go to market with a MVP only through limited channels or through a tightly controlled beta customer program, or through a tightly controlled outbound effort with a very focused customer-facing team.
5. MVPs fit quite nicely into an Agile development methodology.  Here, the problem is more about how Agile is adopted than with just the MVP concept.  In the book Balancing Agility and Discipline, A Guide for the Perplexed[i], Boehm and Turner point out that Agile methods are particularly 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. The Agile methodology assumes that continuous development is happening based upon ongoing direct feedback/interaction — with users. Real market feedback should drive much of the backlog for new sprints. 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, and if the company does not already have access to a significant number of prototypical accounts, the alarm bells ring. And, if they are planning to sell this new MVP using normal sales channels, the alarm volume in my head rises to 100 decibels. 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. And perversely, everyone feels great about it at first. The internal team makes dates and achieves new product releases, and boards and investors believe that development is performed in a capital-efficient manner. But in the mean time, development gets insufficient feedback to drive what the actual product capabilities should be while time slips away.
6. The MVP concept fits nicely with growth-hacking, using quick-start operational efforts to drive different marketing initiatives.  If the product is 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 analytics such as visits, lead scoring, download, trials, product feedback, are viewed in contrast with analytics about customers that have actually purchased. Otherwise, the insights gained can just validate value props 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. You might now be surprised to learn that I am actually a huge fan of the MVP idea and of Ries’ Lean Startup. Even so, in my opinion, the dangers need to be carefully watched for 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.

-###-

[i] Boehm, B.; R. Turner (2004). Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA: Addison-Wesley. pp. 55–57. ISBN 0-321-18612-