Talking with companies and teams aiming for rapid innovation and growth, over a wide range sizes and stages, I find many will eagerly tell me about their progress and challenges in implementing their Minimum Viable Product (MVP). While I’m always heartened to find people already thinking along the lines of Eric Reis’ Lean Startup, all too often a few quick follow-up questions reveals what we are talking about isn’t actually an MVP. The MVP idea remains very important, but many people have heard it and starting using it without having really understood it, and it can be dangerous to enter MVP discussions without a healthy dose of skepticism.

The truth is that many supposed MVPs are:

  • too big or too small;
  • too early or too late;
  • an idea or a feature, not a product; or
  • just off the mark.

And, for that reason I often respond to the start of a conversation about an MVP with a redirect about finding a Minimum Viable Business, to draw attention to the elements of an MVP that are frequently under-developed.

Searching for minimum viability

There is a natural tension between two opposing processes — “dilation” and “contraction” — when envisioning a company, product or service. Dilation means expanding the concept into larger and new areas, and “contraction” means constraining the concept to smaller and smaller sub-problems. They are both essential, and effective innovators will fluidly go back and forth between these processes.

Dilation is important for looking at big-picture and long-term potential and hazards. If you are too light on dilation, your vision will be too small, and you will struggle to inspire collaborators and investors. From a starting vision for a new type of car, dilation could cause you to consider elements of the wider ecosystem of transportation, including applications to transportation as a service, or larger road vehicles and logistics. But, just as it is important to know what business you are in, it also is vital to be clear on which business(es) you are not in, to avoid chasing too many “shiny objects,” too soon.

Contraction is important for finding practical execution pathways and risk management opportunities. If you are too light on contraction, you will struggle to organize around and execute a coherent plan that will move you towards your goal. From the same starting vision for a new type of car, contraction could cause you to consider what value you could deliver to your customers without having to make a completely new car from scratch. What is the core — the essence — of what you are trying to do, and what is a way you can get practice at doing it, and validate your hypothesis that customers will find it valuable?

The car example above is not just hypothetical. Consider Tesla’s story. Contraction is clearly visible in the way they executed the first phase of their Master Plan. Their first vehicle, the Roadster, was launched in 2008, just five years after the company’s founding in 2003. How did they achieve that result? A car is a very complex piece of machinery, and there are many design and regulatory constraints. Through a partnership with Lotus inked in 2005, Tesla was able to focus largely on the differentiating drivetrain elements of their vehicle while leveraging the Lotus Elise as a pre-existing, well-engineered base. This allowed Tesla to move quickly to validating their technology and putting their first product in the hands of real customers in just a few years’ time. There is plenty of dilation to be seen in the same company’s Master Plan Part Deux.

Imagine if Tesla had over-biased on contraction, though. What if their idea of MVB wasn’t the Roadster, but instead was the battery pack, or the motor. They did go through a development phase where they tested these components by integrating them into a vehicle they did not make themselves: the Tzero by AC Propulsion. But, their first launched product was the Roadster because they saw their customers as early adopter consumers, not makers of vehicles. And, a fully baked consumer value proposition had to include a complete, drivable vehicle, not vehicular components.

Alternatively, imagine if Tesla had over-biased on dilation. What if their MVB was a privately owned worldwide fleet of autonomous vehicles delivering transportation-as-a-service. That is part of their overall vision, but way too much to achieve as a first market entry, even for a company as capable and ambitious as Tesla. Even the Roadster’s successor, the Model S, would have been too big as an MVB. There were too many skills to learn. Starting with the Roadster allowed Tesla to practice the tools, techniques and technologies needed to perfect the core elements of their differentiation, while being paid to do so.

To define a Minimum Viable Business (MVB), you need to use your contraction skills to search your larger vision for a constrained customer segment and value proposition to go after. Notice that I said “value proposition” and not “feature set”. Your hunt for “minimum” should be anchored on customer needs and corresponding value propositions. That will lead you to thinking about features, but its important to start from the target customer need and value proposition and work backward from there.

Equally important is to be very clear about the customer behavior hypothesis you are testing, and how you will measure to determine if your MVB does or does not confirm the hypothesis, once it is launched. Be prepared to measure not just a single outcome, but user engagement and behavior with the product across features, so you can learn which are contributing most to the success (or not) of your product.

Since you are defining a business, not just a product, you need to think about how you will measure its success. Of course, the most natural way of measuring the success of a business is its profits. But, your measurements may be broader than that. At this point, you are not obligated to actually charge customers if there is a good reason not to, but since you are designing a business, you should have identified a value proposition you could reasonably charge for and people would happily pay for.

Now that you know you are going after a realistic customer value proposition, and you’ve constrained the scope to the smallest reasonable unit of value, you can figure out what features you need to build, and how you can most efficiently build, deploy, measure and evolve your customer solution.

Leaning out, learning, and leaning in

In product development, we usually use the term “lean” to mean “efficient and with no waste”. By happy coincidence, the verb sense of the word in English also applies. We have been discussing how to go about “lean” (efficient) product development, and the process can be thought of as happening in a three-phase Lean Innovation Cycle:

  1. Lean out — Form a hypothesis and define an MVB to test it
  2. Learn — Learn new capabilities through building the MVB, and validate (or not) your hypothesis through launching it
  3. Lean in — Once you find something that works, invest in that direction.

And, repeat.

If you are able to achieve strong engagement and traction, congratulations! You’ve found your first bit of product-market fit. If instead, you are not able to get traction, congratulations! You just saved yourself, your team, your company and your investors a ton of time and trouble by doing so in the most lean and logical way possible. Now, you can leverage what you’ve learned to do a rapid pivot to an alternate MVB.

If your organization is not used to thinking and operating in these terms, you might have some difficulty getting people out of the mindset of evaluating investments on ROI and into the Lean Product Development mindset. In this situation, frame these techniques as being about finding the best things to invest in by making smart (well-reasoned and constrained) bets, and rapidly finding the ones worth pursuing further. From a board or executive perspective, what we are really doing is learning to innovate faster while at the same time managing down-side risk.


Have you successfully tested a Minimum Viable Business? Please share your success story in the comments below. Or, have you witnessed an effort to build a Minimum Viable Product that really wasn’t? How did that work out?