Minimum Viable Product vs. Minimum Marketable Product

Why is this a relevant topic for a blog about Agile software development?  Because it’s an argument you are going to have to have with you product owners sooner or later we might as well talk about it now.  A core concept in Agile is the concept of the minimum viable product, but the reality is that what a development team defines as a minimum viable product is not necessarily what a marketing or sales  or product team defines as the minimum product that they can utilize.  So let’s start with some definitions. 

What is Minimum Viable Product (MVP)?  As it is traditionally defined MVP is:

“MVP has just those features that allow the product to be deployed, and no more.  The product is typically deployed to a subset of possible customers, such as early adopters that are thought to be more forgiving, more likely to give feedback, and able to grasp a product vision from an early prototype or marketing information.” wikipedia.com

” A minimum viable product (MVP) is a development technique in which a new product or website is developed with sufficient features to satisfy early adopters. The final, complete set of features is only designed and developed after considering feedback from the product’s initial users.” techopedia.com

“The first step is figuring out the problem that needs to be solved and then developing a minimum viable product (MVP) to begin the process of learning as quickly as possible.” Lean Startup Methodology

What is Minimum Marketable Product (MMP)?  MMP is the smallest set of functionality that provides value to your market, whether that market is internal users or external customers. MMPs may provide value in many ways, such as competitive differentiation, revenue generation, and cost savings.  Also might be stated as Minimum Sellable Product.

So how do we reconcile these two different definitions of what “minimum” means?  How do we get from MVP to MMP?

So how do we get from MVP to MMP?  Think of it as math:

MVP1 + MVP2 + MVP3 + MVPn = MMP

The advantages of this approach:

• After each MVP we get to refine our approach.  As opposed to going directly to MMP without having had the opportunity for feedback and refinement
• When MMP is reached the big announcement can still be made so no need to alter communication schedules
• Each MVP is an opportunity to:
  •  get customer feedback along the way
  • engender a sense of ownership and participation from anyone asked to evaluate an MVP on the way to the MMP
  • each MVP is a potential reason to reach out to a client
  • helps with customer retention when users can see steady improvement in the products that they are already using

Ultimately what all of this does is it creates trust between the development team and the business teams. And trust is the biggest factor to success in all of the things we do.  The business team know for a fact that what you are working on is real and will be delivered as promised.  It gives the sales team a sense of confidence when selling what you are building.  And it lets the senior management team know that your team is very, very good at their job.  Because you actually deliver on what you promise. 

So for you the, Agile practitioner in the trenches, it means that you need to start thinking in terms of MMP when you talk about MVP.  Always think about the end product you are creating, not just the bit you are working on this sprint, and always communicate to the business and product teams about MVP in the context of MMP.