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.
An MVP That’s Not the Minimum is NOT an MVP
Far too often, when we start engaging in discussions about MVP outside of the Product Team, we wind up being challenged to broaden the capabilities, to add features and functionality, and to solve more problems than we should with a first iteration of our efforts. When we do this, we are no longer building an MVP, but rather building a bigger and more actualized product. The more you add to your MVP, the further away you’re going to get from being able to reliably confirm or disprove your product hypotheses, and the more time it’s going to take to deliver. Creating an MVP that’s really and MVP requires an intense amount of discipline from the Product Manager to challenge each and every requested addition to the project to ensure that the only things added to the scope of the effort are things that truly are required as a minimum feature set. While we’re not necessarily aiming for “perfection”, we should keep in mind the following quote when we’re trying to establish and maintain our Minimum Viable Product:
It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove. – Antoine de Saint Exupéry
An MVP That’s Not Evolutionary is NOT an MVP
The second biggest mistake that I often see Product teams making when trying to work on their MVP is not focusing on the fact that the intent is to build upon the foundation set by your MVP with another set of MVP capabilities, then to iterate this process until your entire product is complete and live (assuming that any product is really “complete”). While we obviously want all of our products to be as innovative and revolutionary as possible, that’s the market goal. We need to ensure that the technical goal of any efforts we spend on building an MVP includes the ability of the basic building block to be expanded on and enhanced over time. All too often, we lock ourselves into some technical debt that ties our hands in the future, or that requires that we perform significant refactoring on the backend or middle-tiers of our products — all in the name of “creating an MVP”. Doing so besmirches the name, however — MVP is not the straightest line from idea to execution — it’s the first step in an evolutionary process that starts with the MVP and builds over time into the “full” product that your market needs.
What’s dangerous is not to evolve. – Jeff Bezos
An MVP That’s Not Focused on a Hypothesis is NOT an MVP
The last mistake that Product teams and companies make when trying to figure out what their MVP is supposed to be is that they forget the fundamental purpose of building it in the first place — to test a product hypothesis. We’re trying to design our MVP so that it’s narrowly focused on validating our assumptions — it needs to be the smallest amount of work needed to confirm or challenge our assumptions, then we can move on to the next test. And the next. And the next. But all too often, there is no underlying hypothesis around which the MVP is being defined — rather, it’s being defined against a specific user context, or a feature set, or even a marketing target of some form. And all of that is fine and dandy…it’s just not an MVP. When we try to define and build an MVP that’s not focused on testing a hypothesis, we lose our focus and with that loss of focus comes almost inevitable scope creep. If we can continually point to the hypotheses that we’re trying to test, and challenge incoming requests against that goal, we gain the discipline that we need to truly build a Minimum Viable Product, and not just some small set of features that are spread out among different goals.
The lesson of the MVP is that any additional work beyond what was required to start learning is waste, no matter how important it might have seemed at the time. – Eric Ries
