Lean Product Management

<< Strategic Planning and Lean Portfolio Management     ToC     The importance of having an intake process >>

Executive overview

A critical aspect of the focus on achieving business agility includes identifying what is of value to build and then manifesting it in an efficient manner.

In general, there are five different types of work to be done:

  1. Creating new products in new markets for early adopters
  2. Enhancing existing products either to improve functionality or expand markets
  3. Creating new products for existing customers whose needs are reasonably known
  4. Replacing existing software
  5. Maintenance issues (such as bug fixes)

Each of these types of work is done in a different fashion; therefore, it is important to pay attention what type it is.

Minimum Viable Products (MVPs) are a hot topic in the Lean Startup community. They have a different purpose than most of the work done by established companies. Even mid-size companies must attend to enhancing existing products that have an established marketplace. As companies mature, they usually spend a significant amount of effort rewriting software.

The MVP does not cover all of these well. This chapter defines two new types of artifacts to be built. The Minimum Business Increment (MBI) is used when developing an enhancement to a new product or a new product to an existing customer market. The Minimum Viable Replacement (MVR) can be used for updating existing systems in increments.

Thinking incrementally – MVPs, MBIs and MVRs

This chapter looks at the challenge of correctly defining the increments to be realized. There are three concepts to help address this: The Minimum Viable Product for new products, the Minimum Business Increment for enhancing existing products and the Minimum Viable Replacement for replacing existing systems in increments.

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 enough 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. Here is how MVPs are described in Lean Startup.

  • 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​

This is very useful; however, MVPs are not universally applicable.

The question is, what do you do in these situations when:

  • You are an established company.
  • You are building enhancements to an existing product/service.
  • You are in IT and implementing known operating processes
  • The teams required to build it are not aligned and don’t work together well.

Of course, in most cases, the details of functionality are rarely known well in advance. But what about the value of a product or service? In times of innovation and new products, value is not yet known. It is not clear if the product or service is even viable in the marketplace. This is where the techniques of the MVP are most helpful.

But in more established companies, there should already be a good idea about the viability of the product or service and the value of an advance. You do not need the experimental approach of the MVP. This is what the Minimum Business Increment (MBI) addresses.

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. Here are some features of the MBI.

  • 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
  • Contains all of the pieces that are required for value realization. This includes any work required by documentation, ops and marketing.

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

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 more quickly which offers you the opportunity to pivot.

This business value should be based on what represents value for the business and its customers.

Value for the business may involve paying down technical debt, achieving steps in a Lean-Agile Transformations, improving platforms for a product or anything else that the business considers to be of value. It is up to the business to identify value.

Since MBIs are focused on the realization of value and not merely on deploying a feature, they must also describe all that is needed for full value delivery. This includes what would be required for ops, marketing, support and anything else.

Finally, any adverse effect 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.

Click here to see examples of how to create MBIs.

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.

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.

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.

The purposes of MBIs

Here are some of the purposes of an MBI.

  • Provide an early descoping 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 the Theory of Constraints, once said, “Often reducing batch size is all it takes to bring a system back into control.” Smaller pieces can be delivered more quickly. And, by focusing on the high-value pieces first, descoping early helps you avoid spending time on items of lesser value.
  • Ensure completeness to realize value. MBIs contain all 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.
  • 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.
  • 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.
  • MBIs ensure that at all levels, scope is always constrained by a focus on faster realization of value. Of course, when MBIs are initially defined, they represent the minimum chunks of business value that can be realized. But then, as the MBIs are decomposed into features and stories, the scopes of the features and stories are limited to that of the MBI. And this means building only build is needed to realize value. This contrasts markedly with most Agile methods of decomposition which start with epics and then pull 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.
  • MBIs help to manage WIP. WIP is often thought of as the amount of work actually being worked on. But if a feature is started, then that entire feature is work in process. Same for an epic. MBIs have an influence on the amount of WIP because teams know they need to focus on finishing all of the stories in a feature and all of the features in an MBI. Plus, the features and stories are smaller since they are just implementing the part of the feature needed for the MBI. MBIs therefore minimize WIP by being smaller to begin with, having smaller pieces be decomposed from them (features and stories) and providing a higher view of what to finish.

Finally, MBIs can be for internal clients, not just customers. They can focus on 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.

MBIs and MVPs represent the bridge between the business and the development group. These are descriptions of the value to actually realize. This relationship is shown in the next two figures – first as they fit into the hierarchy of artifacts with the second showing where they fit in the value stream.

Figure 2: MBIs in the hierarchy of artifacts.

The Minimum Viable Replacement (MVR)

We have already discussed using MVPs for new products and MBIs for enhancing existing products. Kevin Mireles has suggested another concept that is very helpful: The Minimum Viable Replacement, the “MVR.” This covers the situation faced by many large companies who spend a significant amount of their time replacing existing software. MVRs are for the increments used to replace an existing system in segments.

This does seem like a lot of terms. But it is important to avoid overloaded or ambiguous concepts. In a nutshell, MVPs focus on early adopters, MBIs focus on new functionality to a market that already exists or is somewhat known, and MVRs focus on how to control what is released. This is shown in Figure 3.

Figure 3: How mVPs, MBIs an MVRs, relate to each other.
Kevin, who coined the term “MVR,” suggests another use of the MVR. If you are using a framework such as SAFe® that uses the MVP concept as the term for the smallest chunk of value to build and you do not want to adopt the “MBI” term, you can use “MVR” as a container for MVPs when doing a replacement.

Comparing MVPs, MBIs, and MVRs

Although there are many similarities to MVPs and MBIs, it is worth noting their differences.

In the 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
  • MVR: you are not expanding the market at all. you might even be dropping some markets where the cost of maintaining certain functionality is not worth the investment

How to create the Mxxs:

  • MVP: you start the smallest you can to help discover if you have a product
  • MBI: you look at the product/service you want to build and find the smallest part you can deliver and realize value for first
  • MVR: you look for the part of the existing system that is needed for initial replacement

Looking at the impact to existing offerings:

  • MVP: since it is new is should not impact any existing products
  • MBI: almost certainly likely to impact existing products
  • MVR: attempting to lay the base for new offerings

Looking at risk:

  • MVP: product not desirable to new market
  • MBI: upsetting existing code base and thereby other offerings
  • MVR: upsetting existing code base dependent upon existing system and not recognizing dependencies when being replaced

An important aspect inherent in MVPs, MBIs and MVRs

Even though MBIs are intended to be used when there is something already known about the market, it does not mean that you can assume what you are attempting to build with them is known up-front. It is still important to validate the MBI by working in small vertical slices. Consider Figure 2.

Figure 4: Vertical slices are important to achieve quick feedback and value

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. If you are going to use MVPs and MBIs, you are somewhat forced to write thin vertical slices of functionality. T his is a good thing. The difference is in how we go about deciding what functionality to write. With MVPs, you are more likely in a discovery mode, whereas with MBIs, the focus is more about value realized.

Using MVPs, MBIs and MVRs together

Here is what to do. Use MVPs when you are trying to discover if something is of value. MVPs are therefore used for innovation type products. MBIs are increments of value to be realized. You should have a good sense of what this value is before even starting the MBI. If you don’t, start with an MVP and then move to MBIs. MVRs are intended when you are replacing an existing system.

Note how the distinction of MVP and MBI brings clarity by avoiding overloading the terms. In some frameworks, MVP can sometimes mean the first one is for discovery and then after that, “MVP” is no longer for discovery. This is confusing. Starting with MVP and then going to MBI is much clearer.

The method of development will necessarily be different for these three types of increments. MVPs require short cycles and, probably, small teams. MBIs can work well at all scales. MVRs can work in a manner like MBIs but are driven by an existing customer market.

There is a difference in how these are funded.

  • By definition, an MVP should be funded for the value of discovery. After it is built the decision to continue, pivot or stop should be made. It is also possible that an MVP is not intended for a full release but to a limited audience to determine its viability.
  • MBIs need to be fully funded. Remember that an MBI is the minimum business increment so this may not be much funding.
  • MVRs are funded based on the existing customer base you want to continue to support.

(Thanks to Steve Edwards for comments that led to this section).

The importance of MBIs

The importance of MBIs cannot be overstated. The most effective way to lower cost of delay is to manifest value in small chunks. This also increases the efficiency of the development group. Consider the case where a team has three enhancements, each taking the same amount of time and each having the same importance. The quickest way to achieve value is if they work on one enhancement at a time, complete it, and then go on to the next. But they will very often be forced to start on all three. Figure 3 compares two scenarios of when work is done and when value is realized.

Figure 5: Working on items in a serial or parallel manner.

The interesting thing is that even if the Product Owners for A, B, and C know that A is more important than C, it is likely they won’t have the team do them in the optimal order. But let’s say A, B, and C can be sub-divided into MBIs. This enables the team to work on smaller enhancements and increase value manifestation even more. It also makes it easier to get the Product Owners to agree to the work being done serially. This is shown in Figure 4.

Figure 6: Illustrating Serial and Parallel work with MBIs

These results are even better than before. Of course, the decomposition into MBIs is insufficient. They need to be built by taking vertical, end-to-end slices in order to achieve quick feedback as described earlier.

What happened to Epics?

Notice that business increments, MBI, and MVPs have taken the place of epics. Epics, as previously defined are not useful because they are such vague containers, and as mentioned in an earlier chapter, are not good candidates to use WSJF on. MVPs are included because they should be used when new products are being developed. However, you can see in the diagram that epics can be what we call business increments if desired.

See the chapter How Epics Are Used in FLEX  for more information.

The Minimum Business Increment Template

While I describe MBIs as the smallest amount of value that can be implemented and realized there is another, just as important aspect to MBIs. They also have to contain all aspects of what it takes to realize this value, such as marketing and support issues. In other words, MBIs are as small as they can be while still containing everything needed to realize value.

If it’s bigger than necessary, you will make flow harder to achieve. If it is insufficient, the product may be built but it won’t be effectively realized. An MBI must contain:

Requirements

  • Who it is for
  • Use cases to describe the value
  • Meet the organization’s definition of done

What’s needed to develop it

  • Development teams involved in creating it
  • Architectural issues
  • Other capacities needed (e.g., UX, shared services)

What’s needed for release / realization

  • Documentation
  • Marketing
  • Support
  • Ops

It’s hard to argue that our value shouldn’t be defined this way, yet most frameworks don’t specify this. This is another reason that MBIs should be used for extensions to existing software and not MVPs.

Summary of an MBI

An MBI is the minimum amount of business value for which value can be realized from a business perspective. It also details all of the steps required for its release and realization. An MBI is not the same as an MVP because:

  1. it is created by taking initiatives and seeing what can be delivered sooner
  2. it is not necessarily a product
  3. it is for extending an existing product so marketing and support is already in place
  4. it is a container for all the actions that must be taken for realization of value
  5. we are not so much trying to validate whether a product is viable as it is that we have the extension we want correctly defined

If is similar to an MVP in that:

  1. it must always be built in small, vertical slices, with each slice being validated

Template For an MBI

Who are you building this MBI for?

Do they have another customer this is for?

Is there any subset of the MBI that can be delivered sooner? Consider: geography, market segments, language, anything else you can think of.

Are you meeting the definition of done?

What development teams will be involved in creating the MBI?

Are there any system or application architectural issues to be explored?

Are their any business architecture issues to be explored?

What will Ops’ involvement be for this MBI?

How many weeks prior to ready for deployment will Ops be required to get involved?

What other groups will be needed? (UX, shared services, …)

What’s needed for realization of value? Documentation, Marketing, Support, Ops


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

 

<< Strategic Planning and Lean Portfolio Management     ToC     The importance of having an intake process >>

 


Note

Two online FLEX courses are now being offered – FLEX for SAFe, and Adopting FLEX (the first course in becoming a FLEX trainer).

If you want to learn about how to adopt FLEX in your organization please contact the author, Al Shalloway.