Category Archives: Terminology

Defining MVP, MMF, MMP, and MMR

Dictionary

The term minimal 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 minimal marketable feature (MMF), a minimal marketable product (MMP), or even a minimal marketable release (MMR).  As you can see, these terms are very similar to one another so we shouldn’t be surprised that there’s a bit of confusion around them.  So let’s try to clear things up.

 

First, Some Definitions

Figure 1 below overviews how these following terms relate to one another:

  • Minimal 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.
  • Minimal 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 or MMP.
  • Minimal 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.
  • Minimal Marketable Product (MMP). An MMP is the first deployment of a Minimal Marketable Release (MMR).  Having said that, the terms MMP and MMR are often used interchangeably.  An MMP is aimed at your initial users, typically innovators and early adopters. The key is develop and MMP for the few, not the many, and thereby focus on the key features that will delight this core group of people.  An MMP is a tool to reduce the initial time to market because it can be developed faster than a feature-rich product.

Figure 1. The relationship between MVP, MMF, MMR, and MMP.

MVP terminology

 

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 MMR, MMP 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 our purposes the term minimal is more appropriate than minimum because it brings in the idea that it must be sufficient to fulfill the needs of our product’s customers.  Or more precisely, what we believe to be the current pressing needs of our stakeholders.

 

Example: Developing a New Product

Now let’s work through an example of the development of a fictional product.  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.DAD Exploratory LIfecycle

Over a several week period I work through a series of minimal viable products (MVPs):

  1. 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.
  2. 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.
  3. 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.
  4. 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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 minimal marketable product (MMP).  The MMP was five large boxes, each of which had 16 cubby holes for small devices such as phones.  We wanted five boxes so that we could place 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.  We made 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 time we continued to evolve the product via a series of minimal marketable releases (MMRs).  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.  We developed 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.

 

Why The Confusion?

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.

My hope is that this article, and the supporting poster that is now available on the Disciplined Agile Consortium site, has helped to clear up some of this confusion.

 

Related Resources

What is a Process Blade?

Sheathed Katana

A process blade encompasses a cohesive collection of process options, such as practices and strategies, that should be chosen and then applied in a context sensitive manner.  Each process blade addresses a specific capability, such as Data Management, Continuous Delivery, or Portfolio Management.

 

The Disciplined Agile Process Blades

We’ve organized the process blades into three categories, each of which builds on the previous category:

  1. Disciplined Agile Delivery (DAD).  This category supports the four delivery lifecycles – Continuous DeliveryExploratory/Lean StartupLean/Kanban, and Agile/Scrum – as process blades as well as Program Management (the coordination of a large delivery team).
  2. Disciplined DevOps.  This category expands on Disciplined Agile Delivery to add five process blades: Non-Agile/Lean Lifecycles (which are recognized by, but not supported by, the DA framework),  Release Management, Operations, Support, and Data Management.
  3. Disciplined Agile IT. This category expands on Disciplined DevOps to add the following process blades: People ManagementProduct ManagementPortfolio Management, Enterprise ArchitectureReuse EngineeringIT Governance , and Continuous Improvement.

 

Why Create a New Term?

Given our philosophies around terminology, in particular our preference for existing terminology, it is admittedly strange that we created a new term such as this.  Our thinking was that we wanted to get across the idea that a blade could be updated or even replaced, just like a server blade in your operational infrastructure.  As the situation that a team faces evolves, it should be possible for the team to update their configuration of a process blade, or even replace it entirely, with little or no impact to the teams around them.  Hence, a process blade is the process equivalent of a server blade.

Disciplined Agile Terminology

Argument

This brief article explains our thinking around our terminology choices in the Disciplined Agile (DA) framework. It overviews the terminology principles that we follow, discusses why Scrum terminology isn’t appropriate, and maps common Scrum terms to DA terms.

 

Our Principles Around Terminology

The following three principles drive our terminology decisions:

  1. Terms must be clear. If you need to explain the term, it likely isn’t the best. For example, how many times have you had to explain what a Scrum meeting is? Call it a coordination meeting instead, and people have a much better idea of what’s going on.
  2. Terms must be method neutral. Every team is unique and owns its own process. Part of owning your process is choosing the overall method, or lifecycle, that you’re following. Because the DA framework is a hybrid that leverages a variety of methods, were we to adopt one method’s terminology over another it would only make sense for people following that lifecycle. For example, Scrum terminology makes sense if you’re following the Scrum-based Agile/Basic lifecycle but not the Lean Continuous Delivery lifecycle.
  3. Terms should already be in use elsewhere. We are not in the business of creating new terms when existing ones are perfectly fine.

 

The Problem with Scrum Terminology

Many people ask us why we don’t simply use Scrum terminology. We originally wanted to, because that would be the easy thing to do, but we quickly realized that Scrum terminology just doesn’t get the job done for three reasons:

  1. It doesn’t apply in all situations. For example, the term “sprint retrospective” doesn’t really make sense when you’re following a lean lifecycle that doesn’t have the concept of sprints/iterations. Furthermore, it breaks principle #3 above in that the Scrum folks tacked “sprint “onto the front of the existing term “retrospective” to brand it with Scrum marketing.
  2. It was motivated by marketing reasons. The Scrum originators purposely chose unusual terms such as sprint, Scrum Master (later concatenated to ScrumMaster), and Scrum meeting to signal to people that Scrum was different. Well, in DA we’re purposely choosing pragmatic terminology to signal to people that it’s time to up our game as software professionals.
  3. It reflects 1990s thinking. There’s nothing wrong with that per se, other than the fact that we have learned a lot the following decades that we can apply.

 

Mapping Scrum to Disciplined Agile Terms

The following table maps common Scrum terms to the terms that we prefer in DA. As you can see, the mapping is very straightforward.

 

Scrum Term DA Term DA Source Observations
Backlog refinement/grooming Look-ahead modeling
  • “Modeling” is common IT terminology.
  • “Look-ahead modeling” is an existing Agile Modeling practice
  • Not all teams have backlogs.
  • The term isn’t clear (one reason why it evolved from backlog grooming to backlog refinement a few years ago)
Mapping Modeling
  • Common IT terminology
  • Agilists really need to get over their cultural issues around modeling and documentation
  • There is a wealth of material about effective modeling strategies that many agilists are unaware of because they search on terms such as mapping or grooming instead of modeling
Scrum Master Team Lead
  • Common IT terminology
  • Only Scrum teams have Scrum Masters
  • The term “Scrum Master” isn’t descriptive of what someone in that role does
  • The responsibilities of a Team Lead are a bit more robust than those of a Scrum Master, so this mapping isn’t perfect
Scrum meeting Coordination meeting
  • Common terminology
  • Coordination meeting is a much clearer term
Sprint Iteration
  • Iteration is used as a term in XP, Agile Modeling, Unified Process and many others
  • The term sprint is ok, but it doesn’t reflect the agile principle of maintaining a steady pace (you don’t sprint through a long race)
Sprint demo Demo
  • Common IT terminology
  • You can hold a demo at any time, not just at the end of a sprint
Sprint Retrospective Retrospective
  • Original term for the technique
  • You can hold a retrospective at any time, not just at the end of a sprint

 

Parting Thoughts

There is no standard terminology in the agile world, nor will their ever be. Your team, as part of owning your process, will need to decide which terms they prefer to use. We’ve seen many DA teams choose to use Scrum terminology (e.g. sprint instead of iteration) because they originally started with Scrum and that’s what they’re familiar with. That’s their decision and as always our advice is for a team to do what they believe to be right for the situation that they find themselves in.