
Busting the Myth of the Minimum Viable Product
The term “minimum viable product” (MVP for short), popularized by Eric Ries in his 2011 book “The Lean Startup” has become fixed in the entrepreneurial lexicon. All entrepreneurs, whether they know the term or not, are instinctively familiar with the concept: You don’t have enough money to be able to build everything you envision, so you have to be very efficient in how you develop your idea into a product.
This holds true for big companies and startups alike. In startups, you often have people with energy and very little money. In big companies, there is plenty of money, but they still have to be capital efficient in how they approach new ideas, and there are a lot of internal governance processes around handing out piles of cash. Since the least efficient thing you can do is build the entire product and launch it out into the market only to realize that nobody wanted it in the first place, you always want to validate your product idea as quickly and cheaply as possible. Whether you’re a bootstrapped startup or an incubator inside a Fortune 100 company, you ignore the concept of the MVP at your peril.
However, I have come to believe that the term MVP, specifically the “P,” is creating confusion. The presence of the P-word seems to pre-assume that the way to validate your idea is to go ahead and build something. First time entrepreneurs, even at big companies, especially get tripped up on this, focusing on the product as the deliverable. They hire engineers, go into development mode and spend a bunch of money to put something in customers’ hands, when what they really need to do first is validate their assumptions.
What they should be focused on first are MVEs — minimum viable experiments. There are many ways to test different aspects of a business idea short of building a product. MVEs will vary depending on what you want to test, and may need to include product features, but in essence, you’re going to use scientific methods to create a hypothesis and then run a test to either prove or disprove your initial assumption.
Measuring Innovation
Let me give you an example that illustrates the process, and also underscores the challenge of getting first time entrepreneurs to buy into it: A recently launched corporate innovation center aims to take on challenges from the business and present validated opportunities for developing new solutions. They believe one of their challenges is to get employees to include more innovation in their daily work.
The group had already organized over 800 staff members into an online community focused on innovation, so they knew there was interest. They were planning to develop training materials and workshops to help members of this group use innovation techniques in their daily work. This is an example of moving right into product, with the underlying assumption that by publishing out these materials to interested staff, innovation would increase.
They would spend money and time to develop these materials, and to be sure they’d be able to measure results, they wanted to first create an innovation time code staff could bill to in order to measure the kind of casual innovation that was already happening, and draw a baseline.
Let the Validation Begin
This is where the validation process began. To design experiments to validate this idea, we broke this hypothesis down into its components (staff members, time code, billing, innovation) and ran each against a series of brainstorming exercises to tease out all the underlying assumptions and uncover all possible risks.
We used sections of the business model as a jumping off point for these exercises. We considered questions such as: Are there really people there with this problem? Are they the same people we think they are? Do they define it the same way? Is the problem big enough? What data did we need, how we would get it and use it? What was the right technology platform?
We identified 30 core risks, and stack ranked them from highest to lowest, with the highest being the ones that would cause the whole project to fall apart. What we identified as the highest risk was executive buy in. Nobody would use the time code if they didn’t have leadership buy in, but more importantly, staff members had to feel empowered to step outside their day to day work to try innovative things.
It looked like the group might have been focusing on the wrong customer. The barrier to innovation was at the leadership level. Their educational efforts should be pivoted away from the staff, who were already excited about innovating their work, to leadership, who needed to prioritize innovation over profits.
I wish I could tell you how the rest of the MVE process proceeded, but shortly thereafter executive leadership pulled the plug on the innovation challenge altogether, and pivoted to focus on piloting some products that had already been developed because they thought they could get faster business value.
Crushed Dreams
This perfectly illustrates how excessive focus on getting to a revenue-generating product can stifle innovation and lead to failure. In the startup world, there’s a certain energy and momentum that builds up behind an idea. Once people become true believers and hop on board the product release train, and there’s VC money behind it, it’s pretty tough to put the brakes on and say, “Maybe this is not the right thing for us to build. Let’s take a step back.”
In the realm of corporate innovation, the MVE is a difficult concept to convey because it’s difficult to admit that you’re unsure of your ideas in the first place. Corporate careers are built on consistently and reliably delivering on objectives, which in many ways conflicts with the “drunken walk of the entrepreneur” — this kind of stumbling, meandering path that is how innovation happens. It’s dirty and it’s messy and you learn — many times over — that you were wrong and you wasted time and effort and you have to go back to the drawing board.
At least startups are built to pivot quickly and change directions in a hurry. Big corporations are not. But, in both cases, financial and governance structures are often out of alignment with the kinds of metrics that indicate that a startup venture is on the right track. We’re so tied to delivering on quarterly goals and equating success with revenue that it makes it easy to think, we should be delivering product to customers at any cost.
Different Metrics
Early innovation efforts should instead be judged by different kinds of metrics, such as the number of experiments they run; validated learnings achieved, or even the number of pivots in a period of time. Those kinds of things don’t bring in dollars, and they don’t even create anything you can demo, which can make it hard for people to get behind them. Subscribe to the myth of the MVP, on the other hand, and it will seem like you are making tangible progress right up until the minute you run out of cash.
The MVP as Ries envisioned it is actually a process that includes customer research and competitive analysis, but as it has become mythologized, it has become more narrowly focused around delivering product. Experienced innovators and entrepreneurs — usually those who have been burned by failure — usually have a much easier time embracing the validation phase of the process. Ideally we can take some of the pain out of the process for all entrepreneurs by reincorporating the MVE process into our thinking about MVPs.
What MVEs do is reduce risks, primary among them whether there is a customer for the product, and whether the technology will work as envisioned. They save resources, helping you validate your biggest underlying assumptions in the cheapest possible way.
Entrepreneurs may have to conduct many experiments to validate that an idea is worth investing and building. It’s not as sexy as leaping headlong into development. Validation and risk mitigation rarely are. But it can also be an exciting time, ripe with discovery and insights. In the end, if your idea is a good one, you’ll get to a better product faster once you do start to build. If it’s not, you’ll find that out sooner and with a lot less pain, and then you can move on to validating your next idea.