Minimum Business Increments (MBIs)

Minimum Viable Product (MVP[1])

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:

• Used for developing products for early adopters by focusing on learning what they want
• Geared toward startups
• Designed for the first time a product/service is released
• Usually built by a small team that can already pivot

MVPs are not universally applicable

The question is, what do you do when:

• You are an established company?
• You are building enhancements to an existing product/service?
• The teams required to build it are not aligned and don’t work together well?

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:

• Adds value for the customers of the business
• Provides valuable feedback that the right functionality is being built
• Provides valuable feedback that the functionality is being built the right way
• Provides functionality that can be verified as an increment that can be delivered
• Enhances the ability of the organization to deliver value in the future

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:

• Customer market:
• MVP: you are creating a new product for early adopters
• MBI: you are extending an existing product to a new market segment or extending the product to an existing market segment
• Impact to existing offerings:
• MVP: since it is new is should not impact any existing products
• MBI: almost certainly likely to impact existing products
• Risk:
• MVP: product not desirable to new market
• MBI: upsetting existing codebase and thereby other offerings

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.

1. Provide an early de-scoping to high value. By doing this the organization can focus on manifesting the most important value. Smaller pieces are easier to manage. It is as Eli Goldratt, the creator of Theory of Constraints, once said, “Often reducing batch size is all it takes to bring a system back into control.” Smaller pieces also can be delivered quicker. In addition, by focusing on the high value pieces first, by de-scoping early you avoid having spent time on items of lesser value.
2. Ensure completeness to realize value. MBIs contain all of the work that is required to realize value. The scope of the MBI includes non-development aspects of value realization such as user documentation, market support, ops and others. MBIs create the visibility throughout the entire value stream and provide clarity for DevOps as well.
3. Enable the ability to sequence the list of work to be done while attending to shared services that are likely constraints. This also enables avoiding starting work until you have the capacity to complete it.
4. Provide clarity of what to align around. All parts of the organization should be working towards defining, implementing, deploying and allowing for the realization of the most value as defined by the business stakeholders.

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

“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.

[1] 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).