Lately I’ve been wondering… if present-day Eric Ries had access to a time machine, would he go back and convince his younger self to never use the term MVP?
MVP is a clever initialism. It’s familiar and it feels instantly important — a near perfect buzzword. (In the North American context, where Ries grew up, “MVP” is well-known from the world of sports, referring to the Most Valuable Player.)
But in the world of innovation — from startups to huge corporations — MVP actually obscures the important process Ries was trying to promote.
Every element of Minimum Viable Product is potentially confusing, but the biggest problem is the V.
According to Ries, MVP is “one of the most important lean startup techniques.” He defines it as:
that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.
The word “viable” is a bad choice here. It literally means that something will succeed. It will not fail. It can live on its own.
But the whole point of the MVP in the Lean Startup approach is that we have to be prepared for the thing to fail. (However, calling this “failure” is almost as misleading as calling the thing you’re testing an MVP!)
This kind of “failure” is actually a good thing — it gives us an opportunity to learn, iterate, pivot, until we arrive at a product that really is viable. That’s also why the “minimum” part of MVP makes sense — we need to be as efficient and cost-effective as possible in learning what we need to know so that “failure” doesn’t put us out of business.
So what makes a product viable?
A viable product provides a solution for real customer needs while also serving the business goals that keep it alive. In a for-profit context, a viable product must at least generate enough revenue to keep it working or growing and deliver some returns to the business.
This is more like Ash Maurya’s definition of a Minimum Viable Product:
the smallest thing you can build that delivers customer value (and as a bonus captures some of that value back).
How can we figure out if the solution we want to provide actually delivers customer value?
There are two roads you can go here. In Lean Startup, you can use the MVP process to test your idea with real customers. This solution-first approach can work, but it can also be time consuming and expensive unless you’re a lucky genius unicorn.
Even better, with a little bit of time and a little bit of money, you can start out by doing just enough research to understand people’s needs and discover new opportunities.
Taking this problem-space first approach, we start out by discovering and validating real problems. We can identify people’s needs in an area of their lives — spaces where there’s just no existing solution, and places where the solutions that exist are cumbersome, frustrating, or unfair. Problem-space research (thanks Indi Young!) can help identify opportunities for innovation and disruption before you’ve invested time and money into a brilliant solution without a problem.
Once we’ve identified some real problems, we can start to imagine (better) solutions. This is where Ries’ concept of build-measure-learn comes in and works really well.
Starting small, we can quickly test our ideas with real people and learn whether we’re on the right track. As we learn more, we’ll correct course and build things that are more right — getting towards better solutions for people’s needs, and eventually reaching viability.
If it’s not an MVP, what is it?
If we accept that an MVP has to be viable — something that can live on its own and generate customer value and business revenue — what do we call the things we test and learn with?
Timan Rebel of NEXT wrote the other day about how they use solution experiments, prototypes, and first versions to describe what many others call an MVP. All great words that describe specific things for specific purposes. If you absolutely need a set of three letters, try MTP — Minimum Testable Product.
It doesn’t really matter what you call it (as long as you don’t call it a Minimum Viable Product, yet). The key is to remember that you can use almost anything to communicate and test a concept, vision, or product with real people — but what you put in front of people should allow you to get the the most possible information to answer your most important questions with the least amount of effort.
The more quickly you learn, the faster you’ll be able to revise and refine your product to better solve people’s problems. And the faster you get to the right solution, the sooner you’ll be able to scale up and start delivering value to customers and your business.
This piece was originally published on Medium, and added to theUXblog, which lives on on Medium but appears to be defunct since 2018.
If you made it this far down the page, thanks for reading.
Like with every post on this blog, consider this an invitation to join in thinking together, and maybe doing together. Why not get in touch with me on the Get in touch on the Fediverse to share your thoughts?