The term MVP (Minimum Viable Product) has long been incorporated into corporate vocabulary: it's often used to describe preliminary versions of digital products.
However, it's not merely a product with fewer features than the final version: it's a strategy to explore the unknown, to mitigate risks and uncertainty. Sometimes, it's not even a "product" at all.
Is your MVP truly "minimal"?
It's not uncommon to hear digital products with extensive technical specifications and detailed release schedules that span multiple territories referred to as "MVPs". I've pondered: are these products genuinely minimal?
My impression is that today the term MVP has supplanted the old "beta version" in corporate speak: it describes preliminary, incomplete versions to be tested on a broad or specific audience. What seems to be lost, or at least relegated to the background, is that an MVP should stem from a question to which the answer is unknown: the MVP is the tool to gather the necessary information to answer that question.
An MVP is thus concerned with uncertainty and the need to mitigate it by seeking to learn as much as possible while expending the least resources: reducing waste is one of the core principles of Agile/Lean.
On the other hand, if an MVP has 5 out of 15 planned functionalities, defined by a list of technical requirements, it's not an MVP, because we already know what comes next: we are facing a Waterfall process, not Lean, where there's no room for discovery and iteration.
To clarify, it may be useful to step back and remember what an MVP originally is and its purpose.
An MVP starts with a question
The term Minimum Viable Product was coined by Eric Ries in his now-classic The Lean Startup. For Ries, an MVP is something that allows a team to collect the maximum amount of validated information about customers with the least effort.
Another definition comes from Jeff Gothelf and Josh Seiden in Lean UX, breaking it down into two questions:
What’s the most important thing we need to learn first (or next) about this hypothesis? In other words, what’s the biggest risk currently associated with this approach?
What’s the least amount of work we can do to learn that?
The answer to the second question is the MVP.
In both definitions, the emphasis is on learning, discovering something about our customers through minimal effort: understanding if our project is heading in the right direction. The process starts from a question, not from a list of requirements. Thus, the focus shifts from the material realization of a "thing" to the underlying question, which is far more fundamental: posing the wrong question means we are completely off track.
Upon closer inspection, an MVP might not at all be a "product" as we commonly understand it.
An MVP Isn't Necessarily a "Product"
Jared Spool shares an exemplary experience: an insurance company wants to cut costs by having customers submit photos of claims instead of using professional photographers. What's the MVP in this case? Perhaps a mobile app that allows customers to send photos? In reality, the most urgent question is: will customers be able to take photos that meet the company's requirements?
To find out, there's no need to develop software: the insurance agents provide a group of customers with instructions on how to take the photos and an email address to send them to. Initially, the results are discouraging: but through subsequent iterations, with clearer instructions and examples, things improve until the majority of photos received become acceptable.
Spool's MVP meets all the fundamental requirements:
- It starts with the most urgent question for the project's continuation, the greatest risk at that moment;
- It requires minimal effort: not a single line of code is written, an email address suffices;
- It is iterated multiple times: each new iteration builds on what didn't work, on what was learned.
The only thing missing from this MVP is... the product. It's not a beta or alpha version, not even a proof of concept: from a material standpoint, it's almost nothing. Many types of MVPs share this characteristic of "intangibility," such as the so-called "Wizard of Oz" MVPs or "button to nowhere" MVPs.
AND EMILI specializes in development and strategic consulting for digital channels.
An MVP Is disposable (or almost)
An even more radical approach is outlined by James O’Brien, who suggests an MVP should possess four attributes:
- Cheap: It allows us to discover insights at the lowest possible cost.
- Fast: It should enable rapid discovery to move onto the next phase swiftly.
- Measurable: Its outcomes must be quantifiable in terms of the success/failure criteria we've established.
- Dead: An MVP is created for learning and should be discarded afterward; an overly elaborate or expensive MVP appears "too good" to be abandoned or altered, contradicting the principle of iteration.
According to O’Brien, ideally, an MVP should not have a dedicated budget for its creation: the moment someone authorizes expenditure for something, they feel vested in its success. How then can one explain that the project's success lies in its failure, given our need to err to learn?
On the other hand, can we still refer to creations that resemble more "real" products as MVPs? For instance, we might envision that in Jared Spool's narrative, they eventually arrived at MVPs in the form of websites or apps where users could upload photos of their claims.
Perhaps, however, we might consider some distinctions, starting from which phase of ideation we're in to understand what we need.
An MVP for every occasion
The types of MVPs listed here are not meant to be rigid categories: they serve as guidelines to ascertain whether our current requirement more closely resembles the "almost nothing" in Jared Spool's example, a "nearly finished" product, or something in-between.
MVP (the P stands for Proof)
In its purest form, an MVP is focused on learning things we do not know: its essential requirements are to stem from a question, be cost-effective, and iterative. Being a tangible "thing," however, is not a requirement. This is why James O’Brien advocates for the term Minimum Viable Proof: We're seeking evidence that we're heading in the right or wrong direction, not aiming to create something aesthetically pleasing or durable.
This interpretation fits especially well in the early stages of a project when we're exploring whether an idea can genuinely attract an audience and meet a need. For example, a web form might suffice to gauge public interest in an app we have yet to develop.
ETP: Test, Test, Test
Another scenario arises when we require a tangible product because we intend to present it to real users in a context akin to the final product's future environment: at this point, our MVP additionally needs to be functional in terms of what it promises to do, it must enable users to fulfill the need for which it's designed.
This is exemplified in the classic illustration by Henrik Kniberg, where we see MVPs for a client needing to travel from point A to point B:
For this type of MVP, Kniberg introduces the concept of the Earliest Testable Product: the crucial attribute is that our product (because it is indeed a product now) is testable, thus functional, so that it enables the user to accomplish their desired task (in this case, moving from A to B). All other principles remain intact: starting with a question, being cost-effective, and above all, iterating. What is often forgotten is that the journey initially looks like this:
The client's reaction to MVP 1 will determine the next step, and so on.
The path is not predefined: each subsequent step is determined by the outcomes of the previous one, and we cannot predict how many steps will be necessary. Users conduct tests and provide us with positive and negative feedback, which allows us to identify the next question to address.
MDP: functional, but do I like it?
When assessing the potential success of our product in the market, it's insufficient for it to be merely functional and testable: it must offer the user a taste of the final user experience, including emotional aspects. It should not just do the bare minimum but should promise to leave us with positive feelings and emotions. In this context, we refer to the Minimum Desirable Product (or Earliest Lovable Product, according to Kniberg).
IBM exemplified this type of product in its approach to Design Thinking with the illustration of an MDP for pizza: it's crucial that there be an opportunity to taste all its parts, including those that, in addition to feeding us, should make us want to eat another piece: hence, not just the crust but also tomato, mozzarella...
The MDP is the yellow part of the pyramid, and the slice of pizza (© IBM)
Our MDP (Minimum Desirable Product) provides not only functional value but also emotional value, allowing the user to evaluate it as a whole: understanding whether, in addition to being able to use it, they want to use it.
Some Reminders
I'd like to conclude this discussion with some suggestions for selecting the right MVP according to our project needs.
- Focus on the problem, i.e., the most imminent risk: what could potentially derail our project? What are we trying to learn about our customers or users?
- Determine what we need in order to learn what's important: in the early phases, we might not need any product in the strict sense (which would indeed be overly risky and costly); later on, we can focus on functional and emotional aspects, always one step at a time to minimize waste.
- Be willing to iterate, and, if necessary, eliminate: if an MVP (or ETP or MDP) follows Lean principles, it should never be "too expensive" to be changed or discarded, otherwise we miss the most significant benefit, namely improving our understanding of the problem. If at some point we have "expensive" MVPs (like the motorcycle in Kniberg's illustration), their risk will be mitigated by everything we've learned beforehand.
- Embrace uncertainty: product design is not a road laid out from the beginning but a journey of exploration, questioning, and continuous discovery.
Interested in exploring ways to reduce risks and uncover new opportunities to satisfy your customers? Talk to us.
AND EMILI specializes in development and strategic consulting for digital channels.
This page has been translated using automated translation tools and artificial intelligence technologies. We strive to ensure that the content is accessible in multiple languages, but please be aware that the translation may not be perfect. If you have any doubts or need clarifications, please feel free to contact us.
