Minimum Viable Product (MVP)
Although Eric Ries didn’t originate the term in his book Lean Startup, its meaning is now generally taken to mean Eric’s use of it. A Minimum Viable Product 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. In Lean Startup, MVPs are:
MVPs are not universally applicable
The question is, what do you do when:
While it must be acknowledged that the details of functionality are rarely known well in advance, whether something will be of value or not should be in established companies. In other words, there are times when innovation of new products/services must be explored, where the value is not known. But most of the time the value of an advancement should be reasonably well known.
Minimum Business Increment (MBI)
In the situations where the value of an enhancement or new product/service is reasonably known, the concept of an Minimum Business Increment (MBI) is more useful. It focuses on the realization of business value quickly. It is not a reason to deliver less; it is a reason to deliver sooner.
An MBI is the smallest piece of functionality that can be delivered that has value to the business in that it:
MBIs are created by first determining who your target audience is. This target audience may be external or internal. Then, decide on the scenarios for this market for the business objective in question. Focus on the minimum business increment for the scenarios in question – and that becomes your MBIs. Very often you will commit to a series of MBIs as the desired functional implementation you want to do for an epic. By building and delivering them incrementally you get both value and feedback quicker – providing you an opportunity to pivot. Note that this business value should be based on what represents value for the business and its customers
Net Objectives uses the concept of the MBI to be used when improving products that are already out there. While conceptually similar to MVPs, they are more about the quick realization of business value than the discovery of what will be of value (although one must always be attending to this).
Components of an MBI
Obviously MBIs must contain the value proposition for the client. But since they are about realization of value, not mere deployment, they must also contain what’s needed for full value delivery. This includes what would be required for ops, marketing, support and anything else needed. In addition, any adverse affect an MBI may have on existing functionality must be incorporated into the MBI about to be built and not thrown over the fence to those who built the affected code. Determining how one MBI affects another is usually the responsibility of the business architect.
Comparing MVPs to MBIs
Although there are many similarities to MVPs and MBIs, it is worth noting their differences:
An important aspect of MVPs inherent in MBIs
Even though MBIs are intended to be used when there is something already known about the market, it does not mean that we assume what we’re attempting to build with them is known up front. It is still important to validate the MBI by working in small vertical slices.
System evolution refers to when the software is being built from the system perspective, typically a layer at a time. Business evolution refers to when the software is being driven from the business perspective, that is, slices of demonstrable value.
MBIs are not just for the customer
MBIs can be for internal clients, not just customers. They can also be about improving internal processes and/or tools in the organization. In all cases, the idea of validating and delivering value as quickly as makes sense from a business perspective should be followed.
Value of MBIs
Here are the purposes of an MBI.
Examples of MBIs
Remember: these are Minimum Business Increments. The value realized may be for the business, not a customer. This does not just include paying down technical debt or Lean-Agile Transformations. In product companies that are based on platforms, it could be improvements to the platforms.
“MBI thinking” means to attend, at all levels of the organization, to how we can realize value faster. Where MBIs are first defined this means what are the minimum chunks of business value that can be realized. But then, as the MBIs are decomposed into features and stories, the features’ and stories’ scope is limited to that of the MBI. This means we only build what we need to realize value.
This markedly contrasts with most Agile decomposition methods of starting with epics and then pulling the most important features out of the epics. While this does limit scope, the features are often built fully scoped, instead of limiting them to a more focused target audience or purpose.
MBI thinking can also help manage WIP.
Note: If you are a premium content member you can get an example of this at the MBI Thinking Example.
Using MVPs and MBIs together
In a nutshell, we are suggesting to use MVPs when you are trying to discover if something is of value. MVPs are therefore used for innovation type products. MBIs, on the other hand, are increments of value to be realized. We should have a good sense of what this value is before even starting the MBI. If we don’t, we may want to start off with an MVP and then move to MBIs.
The bottom line of this difference should also be reflected in how MVPs and MBIs are funded. An MVP, by definition, should be funded for the value of discovery. After it is built the decision to continue, pivot or stop should be made. MBIs, however, need to be fully funded (remember an MBI is the minimum business increment) so this may not be much funding.
It’s also possible that an MVP is not intended for a full release but to a limited audience to determine its viability.
Another reason to make a distinction between MVPs and MBIs is to avoid the use of overloading the terms where MVP sometimes mean the first one for discovery with other ones not being MVPs by definition but still using the term. Overloading or using terms that aren’t natural causes confusion. In addition, the words viable & product in MVP do not apply everywhere.
 The term MVP has undergone several transformations. Originally it was coined by Frank Robinson. His original definition is fairly equivalent to our MBI and Denne and Cleland Huang’s MMF. Eric Ries usurped MVP for the Lean-Startup and SAFe has further redefined it by taking the Lean Startup’s perspective when they should have taken Mr. Robinson’s perspective.
(Thanks to Steve Edwards for comments that led to this section).