What really is an MVP?

 Posted by on Nov 24, 2014  Add comments
Nov 242014
 
MVP

In his highly influential book, The Lean Startup, Eric Ries introduced term “minimal viable product” (MVP). As Ries rightly points out, firms putting out new products typically spend too much time and money on features that miss the mark somehow in meeting customer needs or are simply unnecessary. The result is a delayed over-expensive product that is more likely than not an economic failure. Reese proposes a better alternative: put out the least function (minimal) product that you can that might meet customer needs or at least will draw customer attention (viable). This way the team can test the market with different feature sets, get customer feedback, and commit development resources to the expensive activity of hardening the product for general availability. This is called “pivoting”.

As far as this goes, it makes good sense. If you are indeed running a startup that’s putting out your first product, getting early feedback on what would work, and only investing the big bucks when you are sure is clearly the way to go. The same reasoning expends to adding features to an existing product, even if you are not a startup.

However, it is not so easy. Carrying out a MVP program is really carrying out a kind of market research (much like test-marketing a new version of a consumer product in a limited market). The MVP program consists of series of market experiments. To carry out the experiments, a clear statement of what you are trying to learn from each experiment (ideally stated as a hypothesis), and a product that provides a test of the hypotheses (the MVP), a means of gathering data from the market and an analysis technique that uses the data to confirm or reject the hypotheses is necessary.

Note the benefit of the MVP is not the revenue from shipping a product; the value lies in the information gained from learning from the market.

However, I have seen many managers latch onto the term MVP as an excuse to spend less and simply put out an incomplete product early, hoping for early revenue.

In brief, a MVP program is a technique used to actively manage the economics of your development program. The product should have a business case projecting the future costs and benefits resulting from shipping a product or deploying a new feature. The business case turns positive when the future benefits sufficiently outweigh the future costs. These in turn are uncertain, and so must be captured as probabilities with uncertainties. The MVP program, properly carried out, provides the evidence needed to reduce the uncertainty of obtaining the future benefits.

 

Original image by Wikirishiaacharya (Own work) [CC-BY-SA-3.0], via Wikimedia Commons
avatar

Murray Cantor

Murray Cantor is a Cutter Consortium Senior Consultant. He has been applying leading-edge ideas in software and systems development for more than 30 years. Until recently, Dr. Cantor was an IBM Distinguished Engineer, a member of the Rational CTO Council, and the Rational Lead for Analytics and Optimization for Software and Systems.

Discussion

  2 Responses to “What really is an MVP?”

  1. […] have found there is some confusion on this topic. I recently posted a blog to address the confusion on my Cutter […]

  2. Thanks for the comment Keith. You make valid poitns My thoughts on charging customers early stems from a couple of different areas: I’ve seen (and worked for) companies that have conducted traditional Beta programs, get testers engaged, only to flip the switch to Launch and no one buys. I experienced this first hand a few years ago; the company burned through $10M building the product and conducting a successful free beta, only to kill the product after no one bought it once we started charging. The second perspective is that I’m working with more companies who are developing their products using Agile methods such as Scrum. They are engaging early customers who have a serious enough pain that they are willing to pay for a minimal product (of course, minimal doesn’t mean low quality or unfinished). My general thought is that simply getting a lot of people to use a Beta product to provide feedback isn’t enough and doesn’t prove the business model. Companies need to determine whether customer pain is substantial enough to warrant paying for a product. This goes beyond the traditional beta goals of testing features and uncovering bugs.I agree with you that there are some cases where customers won’t use a beta product in a live environment, especially if it’s a mission-critical business application. But if the market is real and the customer pain is substantial enough, it’s possible to get early paying customers, even before traditional market launch.

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(required)

(required)