Published on: Tue Feb 22 2022
In fall 2021 I did an internal presentation about some of the learnings I had during my first two years at Unity Technologies. This post covers the first topic of that presentation; the Minimum Viable Product (MVP).
At Unity I’ve been building a new web interface for an internal CI (Continuous Integration) service. This has been a profound learning experience for me; I’m a much better developer today than I was two years ago, and I’ve learned a lot in terms of product development. One of the concepts I didn’t know that much about is the MVP, which is a well-known product development term. I already knew the abbreviation, and thought that I knew what it was about, due to the (seemingly) self-explanatory name. But assumptions are dangerous, which is certainly the case for the MVP, a commonly misunderstood and misused term.
Let’s try to understand the different parts first:
By combining those words you might intuitively end up with a definition similar to this:
a product of the smallest amount possible which is able to work as intended.
So now we know all about the MVP, and can use it for our product? Not a good idea. I’ve found the MVP to be tricky, because it has a catchy and prescriptive name. You easily end up thinking you know what it’s about even if you don’t.
What is the MVP about then? According to Wikipedia, the MVP has been around since 2001, where it was coined and defined by Frank Robinson. It’s all about how to nail your first release of a product, but it’s surprisingly easy to get wrong. I really like Eric Ries’ definition (many do), which is outlined in his famous book, The Lean Startup by Eric Ries:
Version of a new product, which allows a team to collect the maximum amount of validated learning about customers with the least effort.
This definition captures why you would want to use an MVP: we want to learn as much as we can about customers and our product with the least effort. A keyword here is learning. Your MVP can easily become synonymous with the first release of your product, and you’re missing out if it does. Products fail because of assumptions that aren’t true - and if you find out too late, or never, your product is likely to fail.
One of the core challenges is deciding how minimal your MVP should be. This goes hand in hand with viability. You want something that can be put into the hands of users, and elicit real feedback and learning, which can be used to correct the path you’re on. But you do not need a polished product to elicit this feedback. In fact, you want to avoid polishing something that is likely to change drastically. You should instead focus on viability, and the viability of your product depends on the assumptions you have about the product. You might actually favour the newer kid on the block, the Riskiest Assumption Test (RAT), over the MVP, because it puts a stronger focus on testing your assumptions about a product.
Regardless of which of those you choose, you should narrow down on the assumptions that can make or break your product. Some of these assumptions might not be unique to your product and/or can be validated with research, UX or other means. But you are likely to have assumptions that are unique to your product, and which will have to hold true for your product to succeed. If you do not, then an MVP/RAT might not even be the correct tool for you. If you do, you’re gonna be much more likely to succeed if you put your assumptions to the test, and learn as early as possible.