Bizelo Blog

The Minimum Viable Product (MVP) is a cornerstone of the Customer Development approach championed by Steve Blank and a core part of the Lean Startup methodology championed by Eric Ries. The basic idea is that you need to validate your core assumptions and hypotheses in front of real customers on a continuous, iterative basis in order to maximize value, minimize mistakes, and eliminate waste. The idea makes a lot of sense, and is music to the ears of developers like us that prefer to build as little as possible while delivering maximum value.

But what exactly is the MVP? What does “minimum” mean in this context? How about “viable”? What about even “product”? It seems that many others have spent a lot of time trying to figure this out, and we’d like to offer our take on this as well. In particular, we are concerned more with value and less with simply viability. That is to say, it might be viable, but it must also be valuable. Yet, perhaps the idea of value is inherent in the idea of viability.

An authoritative guide to the multitude of blog posts and writing on MVP

The best way to frame all this is to get an understanding of the current thinking around the MVP. Eric Ries himself kicks off the MVP discussion with a blog post from his Lessons Learned blog back in March 2009. He defines the MVP as such:

…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…

He explains this in greater detail in a slide show and discussion with Venture Hacks. The key thinking here is as follows, my emphasis added:

…[the] vision is to build a product that solves this core problem for customers, these kind of general feature areas, and we think that for the people who are early adopters for that kind of solution, they will be the most forgiving. And they will fill in their minds the features that aren’t quite there if we give them the core, tent-pole features that point the direction of where we’re trying to go. The minimum viable product is that product which has just those features and no more that allows you to ship a product that early adopters see and, at least some of whom resonate with, pay you money for, and start to gave you feedback on…

So what exactly does this MVP need to look like? Is it actually a fully functional product? According to Eric Ries, not really. In fact, he claims, the MVP is just “the minimum features that are required to learn what customers want”. If the MVP is intended to solicit feedback and inspire early innovators, then an MVP can actually be:

• A landing page that identifies whether or not there is potential demand, even if there’s no actual app behind it.
• A dialog box asking about a new feature or function (“Would you like this thing?”)
• Google or Facebook ads that lead to a page to tally interest
• A presentation
• A split test providing the new feature as an alternative
• A link on a page to the potential feature
• “Notify me when you release X” forms
• Screen shots
• Paper prototypes
• A survey with a PayPal link
• Removing features from existing products
• Others listed here

The MVP needs to make an offer, and in fact, it really just has to be the offer. An MVP is really just a test to see if people want the thing that you are considering delivering. In the above presentation, a good analogy is made with entertainment in which the MVP is just a script. If the script gets approval, only then are pilots or shows actually produced.

Getting to the MVP: What if the customer doesn’t know what they want, or if you can’t figure out how to determine their interest?

In the above interview, Eric Ries agrees with the statement that “you charge from day one, so basically every experiment you run is an experiment to make more money”. This means that you’re not just testing hypotheticals about what customers might purchase, but rather you’re testing their desire to actually purchase those things. This then brings in quite a few questions of how minimum the minimum must be to get an accurate read on that.

Steve Blank in his Perfection by Subtraction post provides some illumination on just how small the minimum amount of functionality is really needed in this first test:

…one approach to defining the minimum features set is to ask, “What is the smallest or least complicated problem that the customer will pay us to solve?”…

If you are intending to deliver a product that will require your end-user to also be your paying customer than the approach above is a good one. If your user is not your actual buyer, then you might have to think of different tests to get the end-user involved as well as prove value to the actual economic buyer — something more complicated.

The Key to the MVP: Small Batches

Venture Hacks puts it nicely when they state that an MVP encourages work in small batches.

“A minimum viable product is simply the smallest batch that will teach you something. What can you release in one day?”

Of course, this is somewhat at odds with the first definition in which Eric states it’s the product that allows the maximum amount of validated learning with the least effort. If you’re building a product that will one day generate revenue then you need to devise the smallest possible tests that will teach you whether or not you have something of value. And from this perspective, we see the MVP as an exercise in determining the Minimum Valuable Product that is viable to deliver at economics that make sense for everyone.

As such, Eric expands on his MVP definition in a video and slide presentation delivered in mid-2009. He clarifies that the MVP is not just a version of “release early, release often” since the goal is to only get the feedback necessary to validate a specific point, rather than accumulate a large set of feedback on disparate topics. This makes it very challenging — how do you determine the minimum feature set necessary to validate a specific item?

The Wikipedia entry on MVP clarifies that the MVP is not actually a product. Rather, it is:

…a strategy and process directed toward making and selling a product to customers. It is an iterative process of idea generation, prototyping, presentation, data collection, analysis and learning. One seeks to minimize the total time spent on an iteration. The process is iterated until a desirable product-market fit is obtained, or until the product is deemed to be non-viable…

From this perspective, we see that we’re trying to solve the #1 reason why companies fail: lack of product/market fit. That’s it. It’s not just that you can build something minimal, but rather that minimal thing is a fit with a specific market — which means that the specific market is willing to pay you for that minimal thing, or for your vision that you will expand that minimal thing to meet their needs.

In the second part of the slide / video presentation discussed above, Eric Ries emphasizes for companies looking to test product/market fit with a product they plan to charge for on day one to:

…change your goal from, “How do we get the maximum number of customers,” to, “How do we get the minimally sufficient number of customers to learn what we need to learn…

His general approach was to run a $5 a day AdWords campaign targeting low cost-per-click (CPC) keywords with the objective of maximizing the number of people running through the site. This would allow a test of the economic value proposition and the minimum features necessary to get conversions from visitors to some indication of interest in purchasing.

Amir Khella tells a very compelling story of how it took him just 3 hours to create an MVP that actually generated significant revenue. This was truly a minimally valuable product in that it provided real value to customers, and it could have more features or charge a greater price. Not bad for just 3 hours of putting the product together, and from someone who had never sold a product before!

Ash Maurya also writes about his MVP process where he used customer interviews as the MVP itself. His MVP process was to continue the conversations and iterate on the topics of discussion until the responses started to become consistent. However, it seems that Ash is describing Phases II and III of the Customer Discover portion of the Customer Discovery process. Steve Blank differentiates the MVP from Customer Discovery, so it’s clear that the MVP is something that’s used as a tool in conjunction with the conversations. It’s not entirely clear that the conversations can be done instead of / in place of the MVP. In essence, the MVP is something that customers can use to express their value implicitly or explicitly. It’s a test. Customer conversations aren’t tests but rather ways to determine things to test. In essence, you can use conversations to derive MVPs or MVPs as a way of deriving conversations. But they are not the same thing.

Indeed, Ash describes the primary outcome of his conversations as the development of usable product that he could offer, which he then presented to potential customers again for a product presentation with a call-to-action. This was the MVP — because the conversations themselves weren’t the product – they were the means to derive the MVP. While this might seem like splitting hairs, we’re talking about multiple different processes to get to the same ends – determining what customers want with the minimum amount of waste as possible. In this view, MVPs can drive customer conversations if you don’t have a good list of prospective customers to talk to. But if you do have prospective customers to talk to, have those conversations first and use those iterative conversations to generate an MVP that you can use to test against these same customers. The latter is better if you don’t know what to produce.

Iterating on the MVP idea: MDPs, MFPs, MVP Curves, MVPPs, and more…

Tor Grønsund expands more on the MVP concept with the idea that there’s an optimal point along a conceptual curve of functionality mapped to “resonance with early adopters”. On this curve, there’s a maximum point where no further resonance will be realized with more features, and fewer features will result in less “resonance”. As such, he explains that we should focus the MVP on this optimal point.

However, the MVP Curve concept is problematic. The challenge with this is that it assumes that the MVP is indeed a product, rather than a process as described in the Wikipedia entry above. If the idea of the MVP is to maximize learning with minimal effort, then the idea of focusing an MVP on a theoretical optimal point along a curve is not consistent with the MVP vision. Rather, this optimal point on his so-called MVP is more accurately the point of ideal product/market fit, where the MVP is the process for discovering this ideal point, at a specific point in time, assuming that customer needs and the market is not continuously changing (which it is). Indeed, many of the comments on the above post point out the problems with this MVP Curve and emphasize confusion of product and time optimization with the MVP process.

MVP = Process to Maximize Learning with Minimal Effort About Viability (Where Viability=Customer Value)

Andrew Chen further iterates on the MVP idea with his Minimally Desirable Product (MDP) blog post. In his post, he explains that a Minimally Viable Product aims to solve a business question: “what’s the minimum product I have to build in order to figure out whether or not I have a business.” (which jibes with our vision that viability implies customer value). However, he steps things up a notch by stating that an MDP’s primary objective is to determine “the simplest experience necessary to prove out a high-value, satisfying product experience for users”. So, an MDP really is a few steps past the business-oriented MVP where experience is a core element of the user value.

From our perspective, we care most about the business-oriented MVP because what good is an awesome user experience if users don’t care? It’s not a matter of form vs. function, but rather there is a minimal amount of form and function for the customer to derive value. Better form or more function won’t necessarily create more value.

But there’s some good learning here. Once you have an MVP, it might pay to focus on MDP if you want to solve problems of user churn, customer retention, and competitive advantage against other products with similar value propositions. That being said, if you’re just starting a new business or a product expansion strategy, you’re better to start with MVP since an MDP process won’t address the viability issue.

He also explores the idea of Minimum Feasible Product (MFP) which doesn’t explore business viability or customer desirability, but rather whether it is even technically feasible to produce the desired product of value. An MFP is really a proof-of-concept. That is, it doesn’t prove anything of value to customers, but rather the current state of the art of the technology. Simply put, if a proof-of-concept can’t be built for a given scenario, then as much as you can build an MVP or MDP, you won’t ever be able to realize the solution. From this perspective, you should start with the MVP to determine if there’s a business opportunity worth capitalizing on, then an MFP to determine whether the product can even be built and then an MDP to determine the minimum desirability for such a product.

Phineas Barnes further iterates on the MVP idea by adding an extra “P”. His Minimum Viable Product Purchase (MVPP) concept is basically the same as the MVP, with the emphasis that it should be the smallest unit that a customer is willing to buy. If they are willing to buy something else in addition to that MVP, it should be another MVP. As Phineas puts it, you can “grow the total opportunity by offering less.” Imagine that.

This is very consistent with Yobiz’ vision of mini-apps. Each mini-app should really solve one problem. If it solves two problems, it really should be two separate products. This is consistent with the MVP vision, and perhaps MVPP=MVP in the case that you’re trying to discover what the minimum truly is.

Dropping the Product – Minimum Marketable Feature or Minimum Informative / Learning Element?

Soon after I first wrote this post, I was pointed to Paul Dyson’s post on Minimum and Viable. In that post, he discusses how the concept of “product” really hung him up as he sought to bring something to market. I think he’s onto something, or rather, I think there’s a few people on to something here. James Shore writes about Minimum Marketable Features in a blog post from 2004. He describes the MMF as follows:

A minimum marketable feature is the smallest possible set of functionality that, by itself, has value in the marketplace. You could release your software with just one of these features and you would see some benefit.

This sounds a lot like the MVP, although it uses the term “feature” instead of “product” and “marketable” instead of “viable”. While this does shift the focus away from product, it focuses it on features, which might not be the right place to focus. We want to focus on the viability of a concept and determine if it provides value to a customer. Marketability implies that there is a value proposition delivery, which is consistent with viability, but there are things that can be marketable and still not viable — after all, we can market many things that end up as duds. So, I think MMF as a concept might still leave us wanting as the core concept. But the shift away from “product” as the core concept is not a bad idea.

In Paul’s same post, he quotes a few tweets from Kent Beck and Karl Scotland which shift the emphasis away from product and towards the end goal: information and learning. I think this is heading in the right direction. The “product” is really the learning outcome as the goal is to produce the maximum amount of learning with the least amount of effort. This could be just a link or survey, and these surely would qualify as informative/learning elements. As long as they prove viability and value, then this has the right intent.

A Word of Caution: The Minimum Viable Product is not the product!

Both Eric Ries and Steve Blank caution that you should not confuse the goals of the MVP with the goals of building a product. In Steve’s words:

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… You’re selling the vision and delivering the minimum feature set to visionaries not everyone… Most customers will not want a product with a minimal feature set. In fact, the majority of customers will hate it. So why do it? Because you are selling the first version of your product to Earlyvangelists.

I think this really puts it all together. To paraphrase Steve, the MVP is merely a test that provides info to the right people at the right time to guide you in the right direction. It is not a destination, but merely a stepping stone on the path to Epiphany. Use the MVP to eliminate wasted time and expense and get something in front of early visionary customers as soon as possible so you can build the thing that they will really want.

But even more so, it’s not about accumulating a large set of features as is most readibly accomplished through a “release early, release often” approach. Rather, it’s about distilling it down to the most basic, common functionality that nets you the largest customer group. Steve puts it well:

This rigor of “no new features until you’ve exhausted the search for a business model” counters a natural tendency of people who talk to customers – you tend to collect a list of features that if added, will get one additional customer to buy. Soon you have a ten page feature list just to sell ten customers. Your true goal is to have a feature list that’s just a single paragraph long that you can sell to thousands of customers. Your mantra becomes “Less is more.”

Parsing Minimum. Viable. Product.

I think this somewhat-thorough research helps put a comprehensive understanding on what MVP means. Minimum means a minimum, single test to determine what customers would want – less is more. Viable means something that provides value to a customer in a way that is feasible for the business. If it doesn’t provide value, it’s not viable. If it provides value to the customer, but not in a way that is feasible for the business, then you have a problem. If you have both customer and company value and feasibility, then you have a business. Ironically, the product is the least important part of the MVP process. The product here is really just a test. It could be just a link or a survey — not truly product in the way you would think of it, but it has to be something actionable so you can test to see if customers really see it as valuable so it can be viable as a business. This means you’re testing the value proposition more so than the capabilities or functionality of a system.

Agree? Disagree? Did we miss something? Like the boat? Let us know what you think of this super-long post below!