Will the real MVP please stand up...

The concept of "minimum viable product" has gotten plenty of press in the last several years, having become quite prominent in discussions regarding Lean startups. As I did some research for a course I'm developing, I noticed that multiple definitions have emerged which represent what appear to be different sets of expectations. In this post I'd like to share a few of those definitions and outline why I find some of the most popular ones either incomplete or somewhat naive. I'd also like to offer what I consider a superior definition. It turns out that the MVP concept is underpinned by even more fundamental concepts that require a surprising amount of level-setting in terms of terminology to be useful.

First, a few prominent definitions:

• Wikipedia: "In product development, the minimum viable product (MVP) is the product with the highest return on investment versus risk."
• Technopedia: "A minimum viable product (MVP) is a development technique in which a new product or website is developed with sufficient features to satisfy early adopters. The final, complete set of features is only designed and developed after considering feedback from the product's initial users."
• Steve Blank: "The reality is that the minimum feature set is 1) a tactic to reduce wasted engineering hours (code left on the floor) and 2) to get the product in the hands of early visionary customers as soon as possible."
• Eric Reis: "the minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

If I'm being direct (as I am wont to be), I, as a PM with experience in big B2B shops, find at least some aspects of almost all these definitions silly for a variety of reasons. To wit:

• Wikipedia says that MVP is a "product or Web site". Can't a Web site be a product? What is so special about a Web site that it should be distinguished from other products?
• In an apparent attempt to further fowl already murky waters, Technopedia labels MVP as an "engineering technique" and in the next paragraph calls it a "pared down version of a product". 
• The definition I infer from Steve Blank's blog post tells me that MVP is a "tactic" and (I guess) an approach to get the product in the hands of early adopters. It seems to me he's trying to describe why we would build an MVP (minimum feature set) without a precise definition of what it is. I also ask myself if MVP is relevant when I'm not concerned about early adoption. I contend it is.
• Eric Reis's definition is the one that resonates with me the most, although the special emphasis on learning rather than other business objectives seems a bit naïve or oversimplified outside the context of startups (I'll elaborate more on this point in a moment).

I think part of my dissatisfaction with popular definitions is that they seem overly startup-centric to me. I can assure you the MVP is relevant to virtually all software product organizations and absolutely critical in the complex enterprise B2B space. I also think the traditional concept is focused on the first release of the product, even though the underlying philosophy is hugely important throughout the entire product life cycle. I toyed with the idea of defining a "minimum viable release" (or something similar) but don't think an additional concept is really needed.

To derive what I consider a superior definition, I think we need to deconstruct MVP as a phrase, providing definitions for each word. I address them out of order to underscore which I consider to be causing the most confusion.

• product: In the software world, a product is software that I intend to ship to multiple customers in the exact same form and manage it throughout its life cycle. Shipping good software for one customer can be tough; doing it for multiple customers, especially over a set of increments (releases), is astronomically more difficult.
• viable: Here I interpret viability in the spirit of Tim Brown's innovation drivers, meaning that it represents the potential of the product to meet business ("economic") objectives
• minimum: While I don't think most folks have taken the time to provide clear definitions of the other parts of this phrase, I believe "minimum" is the word that causes the most divergence in terms of both definitions of MVP and people's intuition thereof.

So, here we go. Based on my experience shipping commercial software and in the light of the deficiencies I perceive in current definitions, allow me to present my definition of MVP as it relates to software (and a bit of decomposition for clarity):

The minimum viable product is the smallest increment of a product that is reasonably likely to produce desired business objectives, where:

• A product is software that is intended for delivery to multiple customers, where it will be managed over its life cycle.
• An increment is a version of a product delivered to customers that differs in terms of feature set from previous versions (typically implying an increase in feature scope and including no previous version at all)
• An objective (per OMG's Business Motivation Model) is a statement of an attainable, time-targeted, and measurable target that the enterprise seeks to meet in order to achieve its goals.
• I use the phrase "reasonably likely" as the use of the term "product" implies that we must define minimum scope before we deliver the product and thus cannot know if it will meet sensible business objectives
• The term "minimum" refers to the smallest functional increment of a product relative to other alternatives

A few relevant corollaries/elaborations:

• If it ain't delivered to customers with the intent of its passing through its life cycle there, it ain't a product. POCs, prototypes and other toys, while valuable, are not products by my definition.
• It is critical that we explicitly define "measures of success" (objectives) long before we deliver software to customers. Any other approach reduces product development to a hobby rather than a business.
• The term "minimum" implies that we are leaving features out that may cause customer dissatisfaction. Anticipating the degree of that dissatisfaction and its impact on our business objectives is a skill which often separates commercial success from failure.

I would say Eric Reis's definition comes the closest to my own if we acknowledge that learning is a legitimate business objective in some contexts. Thinking back on management teams I've worked for over the years, imagining my telling them that I'm going to invest months (or more) of development to deliver a complex enterprise product that will help me learn entertains me to no end. The idea of creating a prototype (as opposed to a product as I've defined it) to drive learning would have gone over much better with this crowd.

Digging a layer down regarding the motivation for defining MVP at all, I believe the fact that there is so much discussion on this topic is an acknowledgement of some hard-won lessons from commercial software development since its inception, namely:

• Most of us are in the software business, so product scope must be defined in the context of our commercial objectives
• The less we deliver, the less we tend to invest in development and the more likely we are to maintain commercial viability
• Shipping features should be avoided when possible as every one you deliver is a potential liability in terms of:
• Initial development costs
• Support costs throughout the product life cycle
• Security vulnerability
• Complexity that will eventually negatively impact business performance.

I could easily write more, including further definition of underlying terms like goals, life cycle etc., but alas, I am weary and want to digest this post myself before elaborating on it, likely in future posts. I would add that I believe profound discussions on this topic are valuable although the points may seem pedantic on the surface.

So what do you think of my definition? What is yours? What are your experiences shipping MVPs? You can find out more about my offerings, including software product management training, on my site.