In your organization, what term do you use to refer to the smallest set of features that would constitute a viable release to your users? In other words, how do you refer to the smallest set of must-have features you could possibly release to your users that they would actually pay you for or—if deployed internally—use?
In this posting I explain why I believe MVP and MMF are not good choices for the smallest set of must-have features that would constitute a release, and why I use the term MRF (Minimum Releasable Features).
If you have taken one of my classes or read my Essential Scrum book then you know how important I think it is for people who collaborate to share a common vocabulary of terms (see this blog post). When teams don’t take the time to purposefully define their terms, you end up with two people on the same team having a conversation using the same term but talking right past each other! Worse yet, they actually think they are in agreement!
And, even people who don’t collaborate on the same effort still need a common vocabulary to communicate effectively. I recently attended a conference where I listened to a conversation between two very knowledgeable agile practitioners. It soon became apparent to me that each was using the term MVP completely differently, which was causing both of them quite a bit of confusion. Their exchange actually prompted me to write this posting!
MVP (Minimum Viable Product)
Let’s start with MVP or Minimum Viable Product. This term has a lot of baggage associated with it and is commonly used in at least two different ways.
Some people use MVP to mean the most pared down version of a product that can still be released. You know, the smallest, cheapest, most basic version of your final product that you want to get into the marketplace quickly. The primary implication being that the MVP has enough value that at least some people are willing to buy it and use it. It is also hoped that the MVP will be useful for acquiring knowledge that can be used to guide future development. In other words, you put the pared-down version into the marketplace to better understand your customer needs before you invest in building the full-featured, gold-plated version of the product.
Other people use MVP to mean the simplest experiment you can run to validate the current most-important customer hypothesis. Or as the Lean Startup community says, the simplest thing you can do, with the least effort, to collect the maximum amount of validated learning about the customer. Notice that the focus of this usage is on the learning, and not whether you actually delivered a product to customers that they could use. For example, an MVP could be a landing page that you use to validate your value proposition and even your pricing. You wouldn’t call your landing page your product, or even a bare-bones version of your product. Instead, the landing-page MVP is a quick and inexpensive way to validate important assumptions you are making about your customer.
So, to summarize, some people use MVP to mean the minimum feature set that they can deliver of their product, with a secondary focus on learning from that product before larger investments are made. Others use MVP to refer to a knowledge-acquisition technique, and whether the MVP itself is actually usable by the customer is of secondary interest (interesting to the extent that the MVP might need to be usable by the customer in order to acquire validated learning).
Because of these two common established usages, I have personally avoided using MVP to mean the minimum set of releasable features that a customer would actually pay to use since a meaningful subset of people would be confused by this usage.
MMF (Minimum Marketable Feature)
So what about using MMF (Minimum Marketable Feature) to mean the smallest releasable set of features? MMF is a term that was coined by Mark Denne and Jane Cleland-Huang in their 2003 book Software by Numbers. Their definition of MMF is a chunk of functionality that delivers a subset of the customer’s requirements, and that is capable of returning value to the customer when released as an independent entity.
One way to think about an MMF is that it represents the must-have subset of a larger customer feature. In other words it is the minimum part of a larger feature that would be useful / valuable to a customer without the nice-to-have parts of the same feature.
For example, if you were developing a product that allowed customers to pay with gift certificates, the MMF of paying with a gift certificate might only allow the customer to use one gift certificate per purchase. Later on you might implement the nice-to-have part of the pay-with-a-gift-certificate feature by letting the customer pay for one order with multiple gift certificates.
An important observation is that just building the MMF for paying with a gift certificate would not, on its own, constitute a releasable product. We would also need to have the MMF for searching for the product you want to buy (e.g., there might be 50 ways of searching for a product and we can go to market with just the single most popular way), the MMF for carting the product (assuming we were implementing a shopping cart), as well as the MMF for paying with a gift certificate.
So in many cases, a single MMF is not actually the minimum set of features we can include in a release. Typically a release is made up of a collection of MMFs that must be delivered together in order for the users to get any value.
Conclusion – Use MRF (Minimum Releasable Features)
Given the two established and somewhat contradictory uses of MVP and the fact that often a single MMF is not a sufficient release, I prefer to use another term that I have labeled: MRF (Minimum Releasable Features). I feel that this term more clearly reflects the intent of delivering the absolute minimum set of must-have features that can be released to our users and still be usable.
Have the various meanings of MMF, MVP, or MRF caused you and your team any difficulties? I’d love to hear what you have done to ensure you are all talking about the same thing.