The term minimum viable product (MVP) has achieved buzzword status in recent times and I’m now hearing people throwing around the term MVP almost on a daily basis. Sometimes they’re using it correctly but many times they aren’t. Frankly it’s driving me nuts.
The issue is that it’s common for people to say MVP when they are actually talking about a a minimum business increment (MBI), a minimum marketable feature (MMF), a minimum marketable release (MMR). There are several reasons why there is significant confusion in the marketplace:
- These are closely related concepts with very similar names.
- Various authors over the years have used these terms in different ways, thereby muddying the waters.
- Few people go back to the original source of a concept and instead choose to read derivatory work (such as this article). In effect suffer from the whisper game – you heard the term MVP from one person, who heard it from someone else, who heard it from someone else, and so on.
To clear things up, we address the following topics:
Figure 1 below overviews how the following terms relate to one another:
- Minimum Viable Product (MVP). An MVP is a version of a new product that is created with the least effort possible to be used for validated learning about customers. MVPs are used to run experiments to explore a hypothesis about what your customers really want. They are much closer to prototypes than they are to the “real” running version of your end product. A development team typically deploys an MVP to a subset of your (potential) customers to test a new idea, to collect data about it, and thereby learn from it. MVPs are created to help you to find the features that customers are actually interested in. Note that the term MVP was originally coined by Frank Robinson although was popularized by Eric Ries.
- Minimum business increment (MBI). An MBI is the smallest piece of functionality that can be realized by a customer (internal or external) that is consistent with the strategy of the business and makes sense to deliver when transaction costs are considered. An MBI adds value for your customers and provides valuable feedback to the product team that the right functionality is being built and is being built in the right way. An MBI provides functionality that can be delivered and which can also be validated as being useful and it enhances the ability of the organization to deliver value in the future. An MBI is a solution that contains all of the pieces that are required for value realization. An MBI, when it is done right, is both an MMF and an MMR.
- Minimum Marketable Feature (MMF). An MMF is the smallest piece of functionality that can be delivered that has value to both the organization delivering it and the people using it. An MMF is a part of an MMR. The term MMF was first proposed by Denne and Cleland-Huang.
- Minimum Marketable Release (MMR). Successful products are deployed incrementally into the marketplace over time, each “major” deployment being referred to as a release. An MMR is the release of a product that has the smallest possible feature set that addresses the current needs of your customers. MMRs are used to reduce the time-to-market between releases by reducing the coherent feature set of each release to the smallest increment that offers new value to customers/end users. An MMR is one or more MBIs.
Figure 1. The relationship between MVP, MBI, MMR, and MMF.
It is important that the term “marketable” doesn’t mean marketing in the sense of a product, but rather, making people aware of the value of what is being released. This can be as it related to a product or service and applies whether it is external or internal. In other words “something that is useful to the customer (internal or external) that can be demonstrated to be of value.
We often get asked several common questions around this topic:
- Is it minimum or minimal?
- Why differentiate between MBI and MMR?
- Don't we just need the concepts of MVP and MBI?
Is it Minimum or Minimal?
Given that I’m being picky about terminology, I realized that there isn’t agreement as to whether we should use the term MINIMUM viable product or MINIMAL viable product (and similarly for MBI, MMR, and MMF). Once again, the words are very close:
- Minimum. The refers to the least quantity or lowest possible amount.
- Minimal. This refers to barely adequate or sufficient (similar to the agile concept of just barely good enough (JBGE)). Minimal is an adjective derived from the word minimum.
As you can see, very nuanced. For better or worse, the industry has settled on the term minimum so that's what we're sticking with.
Why Differentiate Between MBI and MMR?
We wish we didn't have to. Ideally an MMR is a single MBI - your team wants to do just enough work to develop the minimum functionality that provides your customers with value and release it as quickly as you can. That's an MBI. Practically though you're sometimes forced to release more than a single MBI in a release. Perhaps you've decided to have a regular quarterly release cadence. Perhaps your customers prefer large releases (this still occurs in practice, although is becoming less common as your customers become more savvy with regards to incremental releases). These challenges can all be addressed in time, and they should be, but you may not be there yet.
Don't We Just Need The Concepts of MVP and MBI?
That's correct. When you've streamlined your way of working (WoW) you will find that an MBI is an MMF that you release to your customers, so it is also an MMR. The concepts of MMF and MMR are stepping stones towards what you are really aiming for, MBIs. But you might not be there yet, and you may be working with people who are more familiar with older terminology such as MMF and MMR - as a result we recognize in DA that these older terms exist but we avoid them where we can.
Now let’s work through an example of the development of a fictional product using the concept of MVPs and MBIs. One day while shopping in the local mall my phone ran out of power. This proved to be a problem for me because I had a conference call that I had to be on, forcing me to cut my shopping trip short to go home and take the call there. This experience made me realize that there’s a potentially untapped market need as I would have been very willing to pay to charge my phone while at the mall. Note: I am fully aware that products such as Safecharge and Brightbox exist, but let’s pretend they don’t for the sake of this example.
Just because I’m willing to pay for this doesn’t mean that others will. To determine whether this could be a profitable endeavour I decide to follow Disciplined Agile’s Exploratory Lifecycle (see Figure 2), which is based on Lean Startup’s hypothesis-driven approach. My plan is to iteratively build a series of MVPs to explore this product idea.
Figure 2. The Exploratory Lifecycle.
Over a several week period I work through a series of minimum viable products (MVPs):
- MVP #1: A power bar on a table. I start with a very simple approach: I talk the mall manager into allowing me to put a table against a wall for a one week period to run an experiment. I plug a power bar into a nearby outlet and put it on the table. On the wall I have a sign that indicates this is a phone charging station. Throughout the week I stand by the table telling people about the service and tell them I’ll keep an eye on their phone if they want to go shopping while it charges (I quickly discovered that nobody is willing to actually do that, or at least they’re not willing to trust me, hmmm….). For anyone willing, I have them take a short survey asking them what they think about the service.
- MVP #2: I add several common power cords. On the first day several people indicated that they would use the service but unfortunately didn’t have their charging cable with them. So at the end of the first day I bought several power adapters from an electronics store in the mall. Sure enough, over the next few days I had more people willing to charge their phones at my table. By the end of the week I had gathered a fair bit of data that showed there was general interest in the idea but that a major problem was the inability to safely leave a device to charge while they go off to shop.
- MVP #3: I move to a cafe. The following week I run a similar experiment in a cafe a few blocks away from where I live. Interestingly, I have several people ask to borrow a power cable from me so that they could power their phone while sitting at their own table. The cafe already has power sockets for people to charge devices and it’s fairly common for people to camp out in the cafe for several hours with a laptop or table plugged into the wall. After several days it becomes clear to me that a cafe isn’t a good option for a charging station.
- MVP #4: I add lockable cubby holes. Over the next week I decide to build out a more sophisticated solution, a wood cabinet that has 16 cubby holes for charging devices. Each cubbyhole has a specific type of charge cable, so if you want to change a phone you need to use a cubby with the right type of cable. Each cubby has a door with a physical key lock. I go back to the mall, in the same location as I’d been in previously, and instead of a survey I interview people to discover what they they think, how they would make it better, and what they’d be willing to pay for such a service.
This series of experiments led me to identify a collection of minimal marketable features (MMFs) that this product should offer:
- Lockable cubby holes. People will only leave their phones and other devices if they’re safe. Each cubby hole needs to be locked in such a way that only the person who left their phone in the cubby can get access to it. This could be an electronic locks where people can type in a private code or a physical key-based system.
- Common phone power cords. We need to be able to support charging a range of devices. Each cubby should have several common power cord/cables as well as a normal power plug.
- Easily accessible location that doesn’t offer charging alternatives. Malls and restaurants are good options, but public areas that already support device charging (like cafes) are not.
- Payment processing. We want to support credit card and possibly blue-tooth payment strategies such as Apple Pay. Payment options need to be investigated still.
Over the next two months we built a minimum business increment (MBI). The MBI was a large box which had 16 cubby holes for small devices such as phones. We the each box from folded sheet metal with clear, thick plastic doors so that people can see their devices. For security and payment processing we built a device that used a small touch screen (it was actually a large smart phone) as an input device attached to a card swipe for capturing both credit and debit card payments. Over several weeks we built five of them, placing three boxes in the mall where we had run our initial experiments and two boxes in another smaller mall on the other side of the city.
Then we continued to evolve the product via a series of MVPs. We ran some experiments in a public library where we discovered that library patrons wanted to charge large devices such as tablets and laptops as well as smaller devices. So we developed a new MBI, a “Library Charging Station” that had eight small device cubbies and six large device cubbies. We also hired a designer to develop a sleeker looking box when one mall management change told us that they loved the concept but wouldn’t allow our boxes into their more upscale locations until our boxes where more attractive.
Al Shalloway says it best: An MVP is an investment in learning, and an MBI is an investment in value.
Here's the key difference between the two: With an MVP you are in entrepreneurial mode and need to explore what your customers actually need. But this can only be done by a strongly cohesive and aligned team due to the uncertain, exploratory nature of the work. MBIs are for when you have a product or service and have a good idea for how to extend it. The biggest challenge is often coordinating the parts of your organization that is going to build, release, and support it.
My hope is that this article has helped to clear up some of this confusion.