Times are changing, and so are technologies, markets and customers. By now, everybody has realized that in the big lottery called “digitalization”, some have a lot to gain, some have a lot to lose and we all have a lot to learn. In this context, a swath of new management tools and techniques touted as “agile” and “lean” have taken middle management by storm. One of these shiny, new Silicon Valley tools is the MVP or Minimum Viable Product.
You can barely get into a discussion about developing a product, working on a project or solving another problem of substantial complexity and vagueness these days without somebody suggesting you “just do an MVP”. There seems to be no problem an MVP approach cannot solve. Don’t know what the scope of our project is? Let’s do an MVP. Don’t know what our customer wants? Let’s do an MVP. Don’t really have any time or budget? Let’s do an MVP.
Maximum Vexing Problem
And this could be fine. While an MVP approach might not solve all the problems just mentioned on its own, in almost all cases some valuable insights can be derived from applying it. Who would disagree, that in a volatile environment, with vaguely defined problems and even vaguer solutions, an approach based on many small steps might be better suited than one big (mis)step? In this context, the concept of developing a product (or solving any other problem) by quickly implementing possible ideas, testing hypotheses, gathering feedback and gradually improving on the found solution is not that much of a stretch. There is only one caveat to this: in order for the magic to work, all sides involved must have a common understanding of what the concept actually entails. Which, often, is unfortunately not the case.
Minimum and Product
As with many simple and memorable concepts, the devil is in the detail, so, let’s dig in a bit: MVP is defined by three distinct terms; Minimum, Viable and Product. The first and the third, we (and our stakeholders) usually grasp quite quickly and easily:
Minimum states that we are aiming for something small, efficient and effective. 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 upper management) hooked after all: the promise of getting big X while spending little Y.
Product is also rather easy to grasp; we are not creating something for our personal enjoyment, we aim to create something a customer might want to use or buy. Therefore, this person, group of stakeholders or demographic and their feedback naturally sets the bar for our efforts.
“V” as in “Viable”
Which leaves us with the term “viable”, which teams struggle with the most and which can make or break this approach. Let’s rephrase “viable”, so the problem is clearer: a solution is “viable” if it is capable of delivering on our expectation of success. As these “expectations of success” might vary widely from stakeholder to stakeholder, a shared understanding of what “viable” means, or lack thereof, is what makes or breaks a team taking the MVP route.
Depending on their professional training, current role, subjective perception and many other variables involved, each stakeholder might have a drastically different understanding of what “viable” means. So, it should be clear that in order to make it with an MVP approach it is crucial to make each stakeholder’s expectations as explicit and clear as possible and continuously attempt to align them as much as possible.
Making “Viable” more “Viable”
One way to do away with the gravest misunderstandings of what should be achieved by using an MVP approach has been suggested by Lean/MVP coach Henrik Kniberg. He proposes three substitutions for the term “viable” depending on the main objective a team tries to achieve through the use of an MVP:
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 value propositions, risks or chances.
Minimum Useable Product – Something a user can get a (limited) use from and give feedback in terms of 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. Ideally this builds on insights gained from previously established Minimum Testable and Minimum Useable Products.
These substitutions make the many facets of “viability” explicit and thus sharpen the concept of MVP based on the context. With them you can provide the right terminology to onboard teams and stakeholders enthusiastic about the concept. They might also come in handy with teams in distress, where a clarification of “viable” would provide some basic structure and orientation allowing them to successfully complete product or project they have already started. Last but not least, they can serve as a means for a more informed discussion with stakeholders who have already had negative experiences with the careless use of an MVP approach.
At Plan.Net we have been successfully making use of MVP-based approaches in a variety of situations: For example, in the development of ambitious digital products. Such as a lean solution for partner integration we created for a global logistics company. Or location based offers and services for the apps of one of Germanys biggest loyalty programs. In this case a focused and iterative approach helped to implement a challenging technology stack of GPS, Bluetooth and NFC in a stable way, while still being able to react in a flexible way to new inputs in regard to product specification. In general MVPs are especially viable (you see what we did here) in cases were technological and creative demands have to be reconciled. Situations that often are informed by conflicting priorities, high pressure and uncertainty.
Another case where we made good use of an MVP, was the relaunch of the platform-portfolio of a big German energy supplier. It helped managing an ambitious roadmap and a big scope. But also in trialing new technology, as in the development of an AR prototype for a big railway company, an MVP-approach helps to keep cool in the heat of the digital jungle.
Beyond the buzzword
So, new challenges need new ideas. We need new approaches for working together, we need new tools and we need new ways of collaborating. We need to be willing to try out things together, to achieve greatness or sometimes even fail together. What we do not need are buzzwords being detonated in meetings like stun grenades, leaving behind nothing but a headache and a ringing sound in everybody’s ears. We need to look “beyond the buzzword” and pragmatically assess how “agile” and “lean” approaches can help us solve problems instead of obscuring them.
This page is available in Deutsch (German)