MVPs (Minimum Viable Products) are all the rage nowadays. There seems to be no problem (in product development and project definition) an MVP approach cannot solve. We do not know what the scope of our project is? Let’s do an MVP. We do not know what budget we need? Let’s do an MVP. We have really limited time available to find a solution? Let’s do an MVP.
And actually I think it is true. While MVP as an approach may not solve all of the problems associated with product development (and project definition), in almost all cases some valuable insights can be derived from it. There only is one caveat to this: In order for the magic to work, all sides involved have a clear grasp of what the concept actually entails. Which unfortunately often is not the case.
MVP – Minimal and Product
So, whats an MVP anyways? Well, it is a concept defined by three key terms, two of which we (and our stakeholders) usually grasp quite quickly and easily:
- Minimum or minimal, states we are aiming for something small, lean and agile. We want to reach a maximum of X with a minimal input of Y (often time, money, people). That’s what gets most people (and managers) hooked after all: The promise of getting a big X while spending little Y.
- Product, is also rather easy to understand, we aim to create something a customer might want to use and/or buy. So, our approach should be centered at exactly this customer. More precisely his feedback to the solutions we propose to his problems.
MVP – “V” as in “Viable”
It is the “Viable” that people struggle the most and that can make or break this approach. Fortunately Henrik Kniberg, the guy behind the simple scribble at the top of this article, that you might have spotted in one too many MVP presentation, went on a real deep dive explaining not only his thinking behind the scribble and his understanding of MVP and providing a treasure trove of real world examples but most importantly some really great thoughts on the meaning of “viable” and “viability” in the context of product development.
The ambiguity of “viable” is not an accident however, it actually is key to the term. “Viable” means “capable of working successfully”. What product, function or solution is “viable” inherently depends on the criteria of success for the given solution and therefore its context. These criteria are going to radically differ not only by industry or application. But, more importantly by the stage of product development and most importantly by the subjective position of each stakeholder involved.
Making “Viable” more “Viable”
Which is exactly why “viable” has so much more potential than “product” or “minimal” to make or break a team taking the MVP road. Henrik Kniberg suggests to do away with the ambiguity surrounding “viable” by getting rid of the term completely. He suggests replacing it with terms that make clearer the current shared expectations of all parties involved in regards to the criteria of success.
- Minimum Testable Product – Anything that you can learn something from. Starting with those things that provide the most value (in regards to functionality, general viability, assessment of risks or chances).
- Minimum Useable Product – Something a user can get a (limited) use from and give a feedback in regards to how to improve the product. Again, focusing on those things that provide the most value in regards to “use” and/or “feedback”.
- Minimum Loveable Product – Something a user might actually like enough to buy, use continuously or recommend to others. The focus here would be on improving and retaining the key value areas defined by former stages.
While I would not go as far as to do away with the term MVP completely, as Henrik suggests, I still think Minimum Testable, Useable and Loveable Product are essential additions to the core concept. This is especially true if stakeholders have little or negative experience with the MVP approach or there is no alignment on the (current) criteria of success.