For a term that’s so well-established in our profession and so widely used, it always surprises me when people abuse and misuse the concept of Minimum Viable Product (or “MVP”). It seems like such a fundamentally simple and clear concept, but often in practice it gets all wrapped up around the axles of internal struggles, until it no longer bears any resemblance to the basics of the concept itself. And when we abuse such a basic concept, bending it to our own purposes rather than using it for the purpose it was conceived for, we wind up watering down the meaning of the term and missing the entire point of engaging in the process of defining and building that MVP in the first place. We create MVPs to confirm a set of hypotheses, to ensure that the problems we’re trying to solve are real and valuable, and to make sure that the technology behind the solution functions as expected. At least, that’s the theory…here are some common missteps that Product Managers make that change their efforts from an actual MVP into something else.
It’s constantly surprising to me that people seem to have such widely different ideas of what the term “MVP” or “Minimally Viable Product” really means. Perhaps it’s a result of the term becoming an industry buzzword, or perhaps it’s because it’s used in some very different contexts, but it always baffles me that people focus on the “minimal” part of the term and completely forget the “viable” and “product” side of things. To me, you don’t have an MVP unless you meet all three criteria:
- You have identified the minimum set of features necessary to engage your users and to solve their valuable problem;
- You have identified a way to ensure that your solution is scalable enough, stable enough, and valuable enough that you can confirm your product hypothesis; and
- You actually have something that you can sell, market, or test.
Whenever I think of what MVP means to me, I think of Dropbox, the cloud-based file-sharing system that pretty much encapsulates everything that an MVP should be.