The Minimal Viable Product (MVP) celebrates its 20th anniversary in 2021.  The concept was introduced by Frank Robinson in 2001.  Steve Blank expanded on it in 2005 with the Customer Development Methodology.  In 2011 Eric Reis popularized the MVP concept in his book The Lean Startup.  Since 2001 there have been several attempts to improve on the core MVP concept.  Like all breakthrough technology concepts, people just can’t leave good enough alone.  Think Agile and SAFe, Since 2001 there have been seven different attempts to redefine the MVP.  What has happened to the MVP on its 20th anniversary?

Three fathers Minimum Viable Product
DevelopmentCorporate

The Three Fathers of the MVP

Frank Robinson 2001

Frank Robinson, the CEO of SyncDev, introduced the concept of the Minimum Viable Product in 2001 as a part of his firm’s SyncDev™ methodology.  SyncDev, PMDI’s flagship product, is the single most powerful way there is to stretch safely, allocate capital, reduce risk, increase return, and achieve smooth profitable growth.”

Frank’s definition of MVP was:

Minimum Viable Product™ (MVP)

PROBLEM: Teams often brag, “We added 800 new features.” Some even consider feature count a badge of honor. Unfortunately adding features doesn’t necessarily improve the business case. It may take longer, make the product less usable, and carry more risk.

SOLUTION: The MVP is the right-sized product for your company and your customer. It is big enough to cause adoption, satisfaction and sales, but not so big as to be bloated and risky. Technically, it is the product with maximum ROI divided by risk. The MVP is determined by revenue-weighting major features across your most relevant customers, not aggregating all requests for all features from all customers.

Frank Robinson

The MVP is the sweet spot between return on investment (ROI) and risk, which correlates directly to effort and time to market. Robinson illustrates MVP with a grid. “Risk or Effort” is on the horizontal axis, and it is plotted against “ROI” on the vertical axis:

Frank Robinson MVP Return on Risk
HackerNoon

Steve Blank 2005

Steve Blank took Frank Robinson’s ideas forward.  In his 2005 book The Four Steps to the Epiphany: Successful Strategies for Products that Win, he introduced the Customer Development methodology.  According to Blank, startups are not simply smaller versions of larger, more developed companies.  A startup operates in a fashion vastly different from that of a large company and employs different methods. While larger companies execute known and proven business strategies, startups must search for new business models. Customer Development guides the search for a repeatable and scalable business model.

The process assumes that early ventures have untested hypotheses about their business model (who are the customers, what features they want, what channel to use, revenue strategy/pricing tactics, how to get/keep/grow customers, strategic activities needed to deliver the product, internal resources needed, partners needed and costs). Customer development starts with the key idea that there are no facts inside your building so get outside to test them. The hypotheses testing emulates the scientific method – pose a business model hypothesis, design an experiment, get out of the building and test it. Take the data and derive some insight to either (1) Validate the hypothesis, (2) Invalidate the Hypothesis, or (3) Modify the hypothesis.

The customer development method consists of four steps that are designed to help avoid common pitfalls and repeat successful business strategies:

  • Customer discovery first captures the founders’ vision and turns it into a series of business model hypotheses. Then it develops a plan to test customer reactions to those hypotheses and turn them into facts.
  • Customer validation tests whether the resulting business model is repeatable and scalable. If not, founders should return to customer discovery.
  • Customer creation is the start of execution. It builds end-user demand and drives it into the sales channel to scale the business.
  • Company building transitions the organization from a startup to a company focused on executing a validated model.

Blank expanded on this approach in his Customer Development Manifesto from The Startup Owner’s Manual: The Step-By-Step Guide for Building a Great Company published in 2012.  The Customer Development Manifesto had 14 rules.  

  1. There Are No Facts Inside Your Building, So Get Outside
  2. Pair Customer Development with Agile Development
  3. Failure is an Integral Part of the Search
  4. Make Continuous Iterations and Pivots
  5. No Business Plan Survives First Contact with Customers So Use a Business Model Canvas
  6. Design Experiments and Test to Validate Your Hypothesis
  7. Agree on Market Type. It Changes Everything
  8. Startup Metrics Differ from Those in Existing Companies
  9. Fast Decision-Making, Cycle Time, Speed and Tempo
  10. It’s All About Passion
  11. Startup Job Titles Are Very Different from a Large Company’s
  12. Preserve All Cash Until Needed. Then Spend.
  13. Communicate and Share Learning
  14. Customer Development Success Begins With Buy-In

Dr. Alan S. Gutterman does a great job of summarizing the Manifesto in this PDF.

Eric Ries – 2011

Beginning around 2004 Steve Blank was an investor and advisor for IMVU, a company Eric Ries cofounded.  In 2011 Eric Ries popularized the MVP concept in his book The Lean Startup.  He defined an MVP as:

The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

Eric Res

The core of the Lean Startup approach is the Build-Measure-Learn feedback loop:

Lean Startup Diagram
The Lean Startup Diagram

The PresentationLoad Blog  does a great job of summarizing the  Build-Measure-Learn feedback loop:

At the heart of the methodology is the Build Measure Learn feedback loop which illustrates the iterative nature of Lean Startup. It illustrates the iterative process of Lean Startup. As its name suggests, customer feedback is a key component. The cycle can be continually adapted using this feedback and the knowledge gained from it. The process starts with the Build phase, followed by Measure and Learn. The process can also be seen as a test of hypotheses. Each idea and its implementation represents a hypothesis about the product and market. With the market launch, data is collected and used to analyze and interpret the hypotheses. the final step, Learn, the hypotheses are verified. If the evaluation is negative, the hypothesis must be adapted and checked in a new test run.

Build

In the first phase of the cycle, everything revolves around the future product. The focus is on how to develop a product that can meet market demand and excite the customer. There is no long and costly market research or detailed planning. Rather, the focus is on finding a solution that doesn’t waste time or resources – the minimum viable product (MVP). It’ s not about producing a perfect product; the primary goal of this phase is to bring the product to market quickly and in doing so, minimize the process throughput time. The product ideas are usually limited to just a few functions that can solve customers’ problems and provide value. In a nutshell, a prototype is developed to gain customer feedback for further development steps. Once this prototype is developed, it’s time to move from the Build phase to the Measure phase.

Measure

This is when customer feedback and reactions are collected. This data can be used to analyze and evaluate the product idea and its practical implementation. The most valuable data points out errors and problems, which then lead to opportunities for improvement. The scope of this data can be limitless. To keep this phase of the loop short, parameters for the data should be defined and set prior to market launch. The organization needs to decide which customer reactions are important and how to interpret these reactions. This can then be used to generate insights in the Learn phase.

Learn

The Learn phase is about validated learning. Assumptions about the product are checked against the collected data. The blind assumptions made at the beginning of the process are replaced by hypotheses. If these hypotheses can’t be validated, they can be adapted when the loop is restarted. This Lean Startup phase determines how the company should proceed. The information about the product can be used to determine whether the chosen path is the right one. Lean Startup offers two options at this point: Continue development or start from scratch. This second option is called a pivot. The loop allows you to abandon course and reorient yourself. This promotes innovation and ensures that the company remains true to its customers.

Gaining knowledge with the minimum viable product (MVP)

A product must be developed for market launch before the Build-Measure-Learn loop can even begin. A prototype is quickly built to minimize production cycles and costs. The prototype addresses the target group’s most pressing problem while still having the potential to be further developed. This means that the product should contain only a few basic functions. Before developing an MVP, the company needs to identify the most important problems of the customer group. Then a solution-oriented product can be 

The core task of the MVP in Lean Startup is to generate maximum data to gain knowledge with minimal effort. The MVP does not claim to be a finished product and shouldn’t be considered one. The MVP will ultimately be further developed or realigned with the knowledge gained during the Learn phase and then tested again.
PresentationLoad

The Evolution of the Minimum Viable Product

Over the years, the MVP concept has evolved:

Minimum Viable Product Evolution
DevelopmentCorporate

Minimum Marketable Feature 2003

An MMP, also known as Minimum Marketable Feature (MMF), was introduced as a product development concept in 2003 by Mark Denne and Jane Cleland-Huang in their 2003 book Software by Numbers. By their definition, an MMP/MMF is a core set of functionalities that addresses the target customer’s immediate needs, while also being capable of delivering quantifiable value back to the business. In other words, an MMP delivers the must-have functionality that can evolve to include nice-to-have functionality and enhanced user experience.

Minimum Delightful Product MDP: 2013

Adam Berrey originated the term Minimum Delightful Product.  He said:

“For consumer apps, I like to think about ‘minimally delightful product (MDP)’ instead of MVP. The reason for this is that in the consumer world ‘viable’ isn’t really compelling. It’s like someone in the ICU. They are alive, but not really fun to hang out with. Create a product with just enough features (lean) and the right UX to be delightful, and you’ll capture the passion of consumer users.”

Adam Berrey

Minimum Viable Investment 2016

The theitriskmanager proposed the concept of the MVI in 2016:

“Over the past few years, I have seen a pattern emerging in organizations that have mature products as they adopt Agile. They all have a flagship Agile project that has a scarily familiar description. They have successfully implemented “Scrum” (This is in no way a criticism of Scrum because they are not really doing Scrum). They proudly tell everyone about their two-week sprints and monthly/bi-monthly releases. The problem is that the releases are always into a “testing” / “staging” / “pseudo production” environment. The flagship project normally has one or two years worth of inventory in the non-production environment and they are about to release a huge change on the business. The only risk this approach addresses is the risk that “IT” will deliver into that environment. There is no feedback from the market that the rewrite product is fit for the purpose. In effect, the risk that the business case (understanding of the target market’s needs) is wrong or the damage to the existing product (market share) are ignored.

The alternative for organizations with mature products is to consider an MVI or Minimum Viable Investment approach. First instrument up your product so that you understand your current metrics. Then identify investments into your product to improve it. Gradually make small investments into your product until you can make big architectural changes easily. In effect, you refactor your product towards a new vision of the product. Start from the outside and work your way in. In other words, start with your customer and work back through the value stream. Understand that taking an inside-out approach will lead to a massive and risky transformation that ignores your customer.

heitriskmanager 

Simple, Lovable and Complete (SLC). 2017

Jason Cohen  CTO of WP Engine, introduced the idea of a Simple, Lovable and Complete product in 2017. He wrote a great post I hate MVPs. So do your customers. Make it SLC instead.  In it he says:

MVPs are great for startups and product teams because they maximize validated learning about customers as quickly as possible. But it’s a selfish act.

The problem is that customers hate MVPs. Startups are encouraged by the great Reid Hoffman to “launch early enough that you’re embarrassed by your v1.0 release.” But no customer wants to use an unfinished product that the creators are embarrassed by. Customers want great products they can use now.

MVPs are too M and almost never V. Customers see that, and hate it. It might be great for the product team, but it’s bad for customers. And ultimately, what’s bad for customers is bad for the company.

“Fortunately, there’s a better way to build and validate new products. The insight comes by honoring the useful attributes of MVPs, which are listed above, while also giving just as much consideration to the customer’s experience.

In order for the product to be small and delivered quickly, it has to be simple. Customers accept simple products every day. Even if it doesn’t do everything needed, as long as the product never claimed to do more than it does, customers are forgiving. For example, it was okay that early versions Google Docs had only 3% of the features of Microsoft Word, because Docs did a great job at what it was primarily designed for, which is simplicity and real-time collaboration.

Docs was simple, but also complete. This is decidedly different from the classic MVP, which by definition isn’t complete (and in fact is embarrassing). “Simple” is good, “incomplete” is not. The customer should have a genuine desire to use the product, as-is. Not because it’s version 0.1 of something complex, but because it’s version 1.0 of something simple.

It is not contradictory for products to be simple as well as complete. Examples include the first versions of WhatsApp, Snapchat, Stripe, Twilio, Twitter, and Slack. Some of those later expanded to add complexity (Snapchat, Stripe, Slack), whereas some kept it simple as a permanent value (Twitter, WhatsApp). Virgin Air started with just a single route — small, but complete.

The final ingredient is that the product has to be lovable. People have to want to use it. Products that do less but are loved, are more successful than products which have more features, but that people dislike. The original, very-low-feature, very-highly-loved, hyper-successful early versions of all the products listed in the previous paragraph are examples. The Darwinian success loop of a product is a function of love, not of features.”

The Minimum Viable Product in 2021

None of the alternatives to the MVP since 2011 has gotten serious traction like RIes’ original concept.  It is important to remember Ries’ original definition:

The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

Eric Res

The alternatives fall down on one or more of the following points:

  • Startups. MVPs were designed for startups.  They do not directly translate for businesses that have crossed the chasm into early majority/late majority.  As noted earlier Blank believed that startups are not simply smaller versions of larger, more developed companies.  A startup operates in a fashion vastly different from that of a large company and employs different methods. While larger companies execute known and proven business strategies, startups must search for new business models.  Most of the MVP alternatives focus on post-startup businesses.
  • New Products.  MVPs focus on new products, not extensions or add-ons to existing products. The Minimum Viable Investment approach does address existing products, but the concept has gained little traction since its launch.
  • Validated Learning. Validated learning is a key concept for MVPs and Lean Startups. As noted by Artur Belka “Validated learning is quantifiable, based on data such as revenue, user engagement, and feedback. The result is learning that is evidence-based and actionable, leading to genuine product improvements in each iteration. Done properly, validated learning is remarkably efficient.”Lean Startup Series: Validated Learning.
  • Least Effort.  Speed, iteration, and learning are critical.  As Steve Blank noted “Founders act like the “minimum” part is the goal.  Or worse, that every potential customer should want it.  In the real world not every customer is going to get overly excited about your minimum feature set.  Only a special subset of customers will and what gets them breathing heavy is the long-term vision for your product. The reality is that the minimum feature set is 1) a tactic to reduce wasted engineering hours (code left on the floor) and 2) to get the product in the hands of early visionary customers as soon as possible.
  • Monetization.  Monetization is not the goal of an MVP, learning is.  Learning so you can build a product that will meet all of your target market’s needs.  The post-2011 MVP alternatives all tend to have a monetization focus.

How Has the MVP Fared After 20 Years?

The Minimum Viable Product has become a standard part of Agile software product development.  Its focus on hypotheses, measurement, iteration, and learning is how almost all modern products are developed.  WhatsApp is often cited as an MVP product.  In reality, WhatsApp slowly evolved from text messaging in 2009 to voice calls in 2016 to finally video calls in 2019.

When faced with someone claiming to be building an MVP, ask them four questions. 1) What hypotheses are you investigating? 2) What measurements/quantifiable evidence are you collecting? 3) How will you apply what you learn? 4) Are you monetizing your MVP or just learning?

Like many great ideas, the market likes to declare 20-year-old innovations dead (spoilr alert: Agile is not Dead)  In reality, some great concepts live on and prosper when people stick to their original concepts and value.


Also published on Medium.