The concept of MVP is an interesting one in the Product Management world — interesting, in that just like the role itself, it seems to mean something different to almost everyone that you talk to. On one side of the spectrum, you’ve got the Lean Product folks who seem to think that a landing page without any other context is an MVP; on the other you’ve got people who seem to think that you’ve got to have a full end-to-end solution that’s just ugly to achieve an MVP. The truth, however, lies somewhere in between the two — as I’ve noted before, there are some key considerations that come into play when coming up with our MVP (When is an MVP *not* an MVP?, but there’s more to it than just understanding the “Minimal”, the “Viable”, and the “Product”. Ultimately, MVPs must all serve some purpose; otherwise there’s really no point in it.
MVPs to Confirm Product/Market Fit
I will grant to the Lean Product camp that you can create something that is specifically designed to confirm that there’s a viable market for your product. I dispute, however, that this can be reasonably called a “MVP” as it fails pretty much everything but the “minimal” test. However, if we pivot our definitions just a little bit, we can absolutely consider something that Marty Cagan has called a “marketing MVP” to fit into precisely what the Lean camp thinks when they consider landing pages as an “MVP”. There’s absolutely value to be had in setting up a website that collects information about your market and confirms that there’s interest in your ideas. And this is exactly where that “marketing MVP” fits in! But don’t pretend that this is an actual “product MVP” — it’s just being used to test your market size and product/market fit hypotheses…there are far more interesting and important hypotheses that we need to test with our “product MVP”…
MVPs to Test a Hypothesis
The next type of MVP that we might build is a very specific, very targeted solution — this doesn’t have to be technical, it can be a “Wizard of Oz” type solution where someone physically fulfills the requests behind the scenes. But the point of this form of MVP is that it’s really strongly focused on the “minimal” side of the equation, while still delivering something of value to the customer. There’s a great many companies who started out with this form of misdirection, hiding manual processes behind a veneer of technology (Zappos comes immediately to mind, for example). The purpose of these MVPs is to focus on an early-phase hypothesis, to test it, and to incrementally improve the product without over-investing. We don’t want to do more than we need to, because if we do wind up failing, the cheaper we can do so, the better off everyone is.
MVPs to Enter the Market
Finally, we come to what I consider to be a “true” MVP — something that fits the requirements of “minimal”, “viable”, and “product.” This is the thing that we build that is the smallest technological solution that we can implement which is usable, functional, and to some degree, delightful. We’re probably past confirming product/market fit, and hopefully we’ve tested enough of our hypotheses to know that we’ve got something worth delivering. The common risk at this point, however, is that we start bloating the core product with features and functions that aren’t 100% necessary to hit the sweet spot of our market and our customers. And that is where ruthlessly focusing on the MVP is critical — when Dropbox launched, it was a very simple solution and succeeded because of that; you had a folder, you put files in it, and it synced to the cloud. That was it; there were a lot of things that it could have done, but they wisely chose to limit it — and in doing so they created perhaps the most successful MVP ever launched.