I had the exceptional luck to work with Eric Ries at both the company that was his inspiration for The Lean Startup, and the company that was his catalyst for the change needed to build companies differently.
One of the fundamental ideas from The Lean Startup is the Minimum Viable Product (MVP), a product strategy now widely embraced by startups that minimizes investment while maximizing learning and market validation.
From my perspective, while MVP is a great and seemingly simple concept, many startups fail to execute it successfully.
There was a time not too long ago when startups regularly burned many millions of dollars in years of stealth mode, building massive projects that anticipated the use cases for all of their future customers. Back then, the concept of releasing anything that wasn’t robust was heresy. Ries’s ideas crystallized a combination of responses to these companies spectacularly imploding. Investors wanted companies to achieve validation faster, and the embrace of accepting failure while chanting the mantra “fail fast,” made the pendulum swing the other way. The result: an explosion of MVPs.
The most common criticism of MVP is that too often it is actually Mvp, where minimal is emphasized and viable is highly subjective but leans towards not really viable. It’s not that MVP is a bad concept, it’s simply difficult in practice. As a result, others have looked to redefine MVP – Jason Cohen proposed the SLC (Simple, Lovable and Complete), and Laurence McCahill proposed the MLP (Minimum Loveable Product), both emphasizing the importance of delighting customers to being “viable”, and reducing the opportunity to simply ship a broken experience to customers using “learning” as an excuse.
Rather than create another TLA, I’m offering guidance to make the implementation of MVPs more effective:
- The MVP Must Deliver Your Value Proposition
- The MVP Must Be a Functional Product
- The MVP Must Provide Validation or Valuable, Intentional Learning
Let’s dig into each of these a little more…
The MVP Delivers Your Value Proposition
The MVP must deliver the customer value proposition for a subset of customers that will be early adopters. Delivering on your value proposition may seem obvious, but in the interest of trying to achieve the minimum investment, it can be overlooked.
Core to my company IMVU’s value proposition was connecting people through expressive avatars, which was initially delivered via a 3D client on the PC. IMVU had an early mobile product that connected customers by enabling messaging from their phone, and while we called it a mobile MVP, it wasn’t. Specifically, the messaging was text-based, so it didn’t deliver on avatars or expressive communication. Since it didn’t include avatars, it also didn’t test the business model, which involved selling items to stylize an avatar. Many existing customers liked the functionality provided, enabling them to perform some basic functions while not at a PC, but nobody would become a new customer on this product – is was simply a helpful add-on.
Later IMVU built a real mobile MVP, starting with the very basic set of functionality that enabled expression via your avatar, and the ability to purchase items for customization (also important to expression). Knowing the PC offering, the mobile MVP felt pretty bare bones, didn’t include 3D (something we knew customers wanted), but the customized avatar was present, enabling self-expression. We gained new customers that only knew of IMVU as a mobile experience, and we validated that the business model worked. Eventually full 3D was added with a lot of other features that did an even better job at reinforcing the value proposition, but it was a pretty humble beginning.
The MVP is a Functional Product
The need to be minimal yet completely functional is where great product design comes in, recognizing that the best products are fully functional without being complex – simplicity delights customers.
The test I’m proposing is, without adding additional functionality, does your MVP continue to deliver value to your early adopters? Asking another way, can you imagine walking away from the MVP and seeing your early adopters still using it in 24 months?
When it comes to applying MVP to new product functionality for an established product, this simple but complete requirement is even more critical. I witnessed many MVP projects that shipped in half-done limbo as some customers liked it sort of, but it was broken, but not valuable enough to finish… the result is many rough edges and missed opportunities to delight customers.
The MVP Provides Validation or Valuable, Intentional Learning
One of the most disappointing results to hear from a failed MVP is, “we learned it didn’t work.” Aside from the obvious desire for projects to be successful and delight customers, this result represents a failure to intentionally learn. A great indicator this is happening is a product manager presenting data harvested after the fact, hand picking metrics that were not identified before the product was built, creating learning theater.
The MVP should reduce uncertainty, either by validating previous decisions or providing information necessary to make specific future decisions.
When building the MVP, there should be a clear hypothesis, identification of the metrics that will be used to gauge progress, the ability to capture those metrics, and an understanding of the critical decisions that will be influenced by the results. In addition to creating a discipline around honest assessment of progress, these requirements guide the team’s product development decisions.
