Viability: The Missing Ingredient in most MVPs
Matthew Doty
I help the C-Suite build, scale & maximize the impact of their UX, CX & Product Design teams. Ask me about "the design impact equation". #OpenToConsult
After spending the bulk of the last 2 decades designing experiences and leading Experience Design (XD) teams, I've become very familiar with Agile, Lean and other methods for making rapid, iterative progress. I may lose my "UX Card" in some circles for saying this but here goes: I LOVE Agile, Lean and any other methodology that relies on the use of rapid, iterative, test-and-learn strategies with minimum viable products (MVP).
What I don't love is when teams and organizations who say they are "Agile" actually aren't. These teams and organizations have warped the concept of MVP so badly that is has become the subject of ridicule and is often completely rejected as a good way to design products, services & technology.
Part of the inspiration for this article is this hilarious post by Tom Greever and the commentary that ensued as a result. In response, I commented "I would argue that’s a minimum product but not viable" So what is viability and what makes a product minimally viable?
In this post, my aim is to scratch the surface on the concept of viability, its role in the MVP and hopefully ignite some additional curiosity in you, the reader, to reconsider what viability actually means.
Before diving in, I want to be clear on what I mean when I use a few terms going forward:
- Agile - Any process that relies on the use of rapid, iterative, test-and-learn strategies with minimum viable products (MVP).
- Product - Tangible products for sure but also, services, technologies and other experiences.
- Customer - The people who will be using products.
- Business - The people trying to make a living from providing products.
Clear as mud? OK, let's do this!
What an MVP is Supposed to Be
In their glossary of Agile terms, Agile Alliance (one of my favorite resources on all things Agile) states the following about the MVP:
"A key premise behind the idea of MVP is that you produce an actual product... that you can offer to customers and observe their actual behavior with the product or service." (emphasis added)
Creating an actual product means we start with a product that is just complete enough to be minimally viable for the customer to use and the business to provide (e.g., the skateboard in the diagram above). We can then observe how customers are interacting with it and learn what we need to do to make the next iteration better and so on. Too often, however, teams and organizations misunderstand this and simply launch minimum products without regard to viability
How Too Many Teams View an MVP
Agile Alliance notes that one of the pitfalls teams and organizations fall into is a misunderstanding of MVP. Specifically, they state the following:
"...this lack of understanding manifests in believing that an MVP is the smallest amount of functionality they can deliver, without the additional criteria of being sufficient to learn about the business viability of the product." (emphasis added).
What Makes a Minimum Product Viable?
To frame up this section, I'd like to revisit and tweak the quote in the previous section to read:
"...this lack of understanding manifests in believing that an MVP is the smallest amount of functionality they can deliver, without the additional criteria of being sufficient to learn about the [customer and the] business viability of the product." (emphasis added).
In other words, a product, service or technology cannot be considered minimally viable unless...
- The people we're designing for are likely to want it and will use it (I call this Customer Viability)
- The people trying to make a living from it will likely see the results they hope for (I call this Business Viability)
Let's explore these two kinds of viability a little further.
Customer Viability
The product must be considered by the customer to be minimally...
- Desirable - Customers want the product (or they will in the future).
- Useful - The product fills customer needs and helps them achieve something.
- Usable - Customers can use the product easily, naturally, intuitively.
- Valuable - The benefit of using the product outweighs the cost.
Business Viability
The business must regard the product as minimally...
- Feasible - It's possible for the business to do relatively easily/conveniently/successfully.
- Sustainable - The business can regularly provide the product with reasonable consistency.
- Scalable - The business can expand its ability to provide the product where it makes sense to do so.
- Valuable - The benefit of providing the product outweighs the cost
Wrapping Up
While the concept of MVP is simple to understand, getting to a minimum product that is actually minimally viable requires us to consider more than we typically realize. When I encounter the "MVP Sucks" attitude in my clients, I almost always discover that the MVPs they've experienced are consistently not minimally viable either from a customer perspective, a business perspective or both. Before you write off agile and subscribe to the belief that MVP isn't a good way to design products, take a moment and reflect on whether or not your MVPs are actually minimally viable.
Now that the surface on this topic is officially scratched, I'd love to know if and what aspects of this post resonated with you most. What did I get wrong? What did I miss? Comment away!
Senior UX Designer + UX Researcher
4 年I like to use the term MVE: Minimum Viable Experience "While Minimum Viable Products (MVP) focus on what you create, MVE focuses on the service you deliver to your customer - what's the quickest, leanest and most efficient way to deliver an experience that meets the needs of your customer for the purpose of gathering feedback and refining your offer."
Front End Software Engineer
4 年And, beyond just the concept of an MVP, you can embrace the agile spirit and build small working components and test them internally prior to a release. The incremental approach is still better than just designing and releasing a monolith on potential clients, even if you feel the small incremental releases don't have "business value" just yet. In the end, you waste less time, which is counterintuitive for people who haven't really embraced the agile mindset (just the "rules").