Slalom loves Agile. We’re excited about the real, measurable benefits we’ve seen businesses gain from it, and we’re talking about some of its greatest advantages in a series of blog posts and a free Agile webinar—watch on-demand.

The MVP, or Minimum Viable Product, is basic to the practice of Agile. And it’s also something that generates resistance. We’ve heard our clients say things like, “Our execs don’t want the minimum—they want the best quality possible.” Indeed, why wouldn’t you want to do your best? It’s a great question, but one based on a misunderstanding of the MVP.

Coined by Frank Robinson in 2001, and popularized by Eric Ries through his book Lean Startup, the MVP has become a pillar of high-performing product teams all over the world. Why has Google been so dominant for so long? Why does Apple make some of the most popular products in the world? Why has Netflix not only survived, but thrived beyond their original business model? Many factors contributed, but one common thread is that they all use the MVP.

So what is the MVP? Here’s Eric Ries’s definition: That version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

As this definition makes clear, the MVP is not a product with the least possible functionality necessary for a public launch. It has nothing to do with publicly releasing a product at all. Rather, the MVP is the key to using the scientific method for building products. It is purely a mechanism for validated learning, used to test hypotheses and discover what will meet customers’ needs.

At Slalom, we’ve integrated the concept of the MVP into both how we build products for companies and in how we partner with them to reap the benefits of incorporating Agile principles and practices in their business model. However—after more than twenty enterprise Agile transformations and hundreds of partnerships across industries—we’ve found that it’s sometimes simpler to not force the use of terms like the MVP. Some have shifted to the term, “Minimum Lovable Product,” and Henrik Kniberg (best known for his work with the Spotify engineering culture) proposes the use of the terms Earliest Testable, Earliest Usable, and Earliest Lovable Products.

Any of these terms is fine. Agile is about happier, more productive teams—not terminology. Our approach to this or any other misinterpreted, unclear Agile concept is to skip the word and ask the following three questions:

1. Why do it? In the case of the MVP, it’s all about learning fast, as well as the underlying principles: customer satisfaction, continuous improvement, and simplicity.
    
2. What would it take to do it in my company? Oh, the power of framing! Instead of asking if you can do it, we hone in on blockers—organizational or otherwise. The answer to this question often takes the form of buy-in from individuals that were thought to be unmovable.
    
3. What if we didn’t do it? Another framing strategy: focus on the costs of slogging along with the status quo. This can build a sense of urgency and establish alignment around a new way of working.

Here’s a story about the dangers of the status quo: A project for a company we recently worked with involved spending six months on a major software release impacting more than 200 internal users. They locked themselves in a room and completed the build and all testing. And it was only at this point that they solicited feedback from a handful of business analyst proxies—not actual users. This kind of checkbox activity, too late to make any real impact, and without a true focus on validated learning, hardly even qualifies as soliciting feedback. It’s really an attempt to validate the inevitable.

The result was predictable. Since so much time and money had already been spent, they felt compelled to move forward, and all 200 users rejected the new software due to its slow performance and lack of usability. Six months and over $12 million spent, with only finger pointing between business and technology teams to show for it.

Now imagine this same scenario with an MVP deployed to a group of end users early in the project. Developers could immediately learn what they were getting wrong, then deploy further MVPs improving iteratively with each one until the deployment of a final product—developed with and approved by real users. A further benefit: The users in the test group would be thoroughly invested in the project and would evangelize it among their peers.

We’ve seen exactly that scenario play out, and that’s why we’re such firm believers in the MVP—whatever you choose to call it.