Many faces of Minimum Viable Product. Which type of MVP is best for you?

Minimum Viable Product has become one of the ‘should-know’ terms in the startup and product development community. Moreover, it is becoming more and more popular among not only so-called “garage startups” but also among large enterprise organizations, which adapt and use various ideas from the agile and lean movement. Interestingly, despite the fact that “everyone” is familiar with the term, the understanding of MVP varies from person to person. In this post I would like to explain these differences and create a brief introduction to this subject.

Minimum Viable Product is all about learning

The most famous definition of MVP comes from Eric Ries; in his blog (and later in his book) he describes the MVP as:

[…] version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort. […]

The concept of validated learning is an entirely different subject, but, in short, Ries defines MVP as something which helps you to learn the most about your potential customers, and to begin validate your business assumptions with the least possible effort. Recently I heard a quick and funny explanation of the topic from Ángel Medinilla (a.k.a. The Crazy Spaniard), who said that: “You don’t need to buy a chocolate factory and tens of hectares of cucumber fields to learn that people don’t like pickles in chocolate. Just prepare ten pickles with chocolate, go to the local market and ask people if they like your product”.

But, as always, the devil’s in the details. The original definition evolved into: the smallest thing that would help you to start “build/measure/learn” loop. This means that MVP could potentially be anything, a post on a blog, a landing page, an explanatory video, a customer interview… Then the question arises: is “a customer interview” really a product?

Minimum Viable Product is all about value

Oversimplifying things can very often lead to some misunderstandings. One of the most powerful stories in The Lean Startup book was the story of Dropbox. In short: before launching the ‘polished’ version of Dropbox, Drew Houston - founder of the service, released a self-made explanatory video and gained traction which eventually helped him to attract users and build one of the largest cloud storage solutions. As a result, many entrepreneurs understood this as a simple one-step solution: don’t build anything, just create a fancy video and see what happens.

But when you look at the original video, that was created by Houston you can perceive things a bit differently. On the video, you can see that at that time, the Dropbox team already had a prototype which worked. Maybe it didn’t have all the current features, or even wasn’t ready to be released to a wider audience, but it did exist. When you analyze the evolution of Dropbox, it seems that making this video was a natural step; a service like this needed a reliable infrastructure and clients on different operating systems. Building all of this without prior validation would be a great waste of time, money and effort!

Nevertheless, they didn’t start only with the video. Before the video they built a prototype - something that felt real to the end-users who watched the video. Can you offer the same experience to potential early-adopters only with a customer interview, or a hazy vision of the product?

Ash Maurya, author of the book Running Lean sees MVP differently:

A Minimum Viable Product is the smallest thing you can build that delivers a customer value (and as a bonus captures some of that value back).

According to Maurya’s definition, Minimum Viable Product is actually… a product. Landing pages, customer interviews or live demos are ways that help you to define the scope of your MVP, but they are not Minimum Viable Product themselves. But even with this definition, MVP is definitely NOT a dream product; it doesn’t have all the features you might imagine, but offers customers some defined value; and has a real shape, which can be metaphorically ‘grasped’ by the customer.

Minimum Viable Product is not (only) a minimal product

Regardless of the definition, the key to properly understanding MVP lies somewhere else. Steve Blank, author of the book Four Steps To The Epiphany (which was one of Ries’ inspirations) writes on his blog, that:

Most startups following Customer Development and a Lean Startup methodology understand the idea of a minimal viable product. But they get it wrong in thinking that’s the point. It’s not.

MVP should not be ‘just minimal’. For a small company the scope of MVP might contain only a few features, but for a large enterprise product MVP will probably contain dozens of features. The key is to understand that MVP should give the customers value, and at the same time it should give its creators the amount of knowledge necessary to build the next versions of a product. Roman Pichler describes MVP concept perfectly:

The MVP is called minimum, as you should spend as little time and effort to create it. But this does not means that it has to be quick and dirty. How long it takes to create an MVP and how feature-rich it should be, depends on your product and market. But try to keep the feature set as small as possible to accelerate learning, and to avoid wasting time and money – your idea may turn out to be wrong!

So, whether you consider a customer interview to be an MVP, or that an MVP should be something tangible, learning is a key concept here. When you eventually choose to build a product, there is one question which is particularly important… How can you define this ‘small set of features’ which will have a high value for your customer when everything is important? This question is valid, no matter whether you are creating a small product or a large system. Luckily, there are techniques which make this task much easier. We will introduce one of them in one of our next posts.

Stay tuned!