An MVP is a Minimum Viable Product. However, now that the term has been around for a few years, we tend to focus on the “minimal” part more than the “viable” or the “product” parts. I personally like to break down each piece of an MVP:
Minimum - without excess, nothing more than what is needed. This concept was the biggest challenge to the traditional model of product development so it shocked the system the most.
Viable - capable of working successfully. Most likely, your product will have bugs, won’t work for some people, and won’t be scalable to millions of users. But, if it is a working solution to a problem, then it’s viable.
Product - products are things that people use to solve problems. The goal of your MVP should be to determine whether your product is solving the right problem for your customers and give them confidence that your product is capable of solving their problem.
BE EMBARRASSED (Because you know too much.)
Reid Hoffman, founder of LinkedIn once said, “If you are not embarrassed by the first version of your product, you’ve launched too late.” I believe this is true in that you should be embarrassed by your product, not because you went too fast and made messy oversights that customers discovered, but because YOU know your future product vision will solve the problem 10 X better than what you are giving customers today. It is common and normal to feel this way. But remember, the goal is to test the overarching question, “Will something like this product solve the customer’s problem?” not, “Will this version of the product dominate the industry?”
Most people I meet think they have to build all the tech and that everything needs to work automatically for them to test an MVP. In reality, testing an MVP is more about the way the customer experiences the product, and not about what goes on “behind the scenes.” If you wanted to test the technical nature of a product, you would be building a proof of concept that would show its technical feasibility. An MVP is about testing the customers’ reactions. Put yourself in the mind of the customer. What do they see, feel, and experience? Make that as real as possible. However, for things that happen behind the scenes, you can do those manually, use pre-defined data or paths, and a bunch of different approaches that can save you time and money building an MVP. Remember, a “viable” product is capable of working successfully, but that doesn’t mean it needs to work across 1 million different potential paths.
WHEN AM I DONE?
MVP’s are purpose-built products, meaning they were built to test a specific hypothesis (remember the scientific method). Sometimes that same MVP can be just slightly modified to test additional hypotheses, but they are still built to test one specific thing. We are looking for directionality in the data, meaning, from your MVP, you should be able to answer questions like, “Did this go in the direction I thought it would?,” “Was the customer delighted?,” and, “Did he/she ask the right questions?”
But, to answer the question, “When am I done?”: you are not done until you have a product that meets the market need (this is where “product/market fit happens”) and you feel like there are not any major risks or gaps in the product’s solution to the customer’s problem.
In his annual letter to shareholders, Jeff Bezos, Amazon CEO, wrote that you should make decisions when you have about “70% of the information you wish you had” and if you have any more information, you are probably deciding too slowly. Hopefully, your MVP testing will answer several questions and provide lots of new insights; however, you will always wish you had more information. New product innovation is inherently risky. Yes, there are several things you can (and should do) to mitigate those risks, but dealing with some degree of uncertainty is par for the course. The same way you can’t steer a parked car, innovation (the process of iterating, remixing, and improving ideas) isn’t possible without action and some risk-taking.
Don't miss a step!
Subscribe to the series — you won't regret it.