The MMF: Minimum Marketable Feature
Welcome to the final installment of our MVP, PSI, MMF Alphabet series. For this article, we’re digging into MMF (Minimum Marketable Feature).
Something I try to help new Product Owners with is understanding the distinction between Potentially Shippable and “We actually want to ship this”.
There’s a tension that exists between the desire to deliver quickly and learn even more quickly, and the need for a company and a product to put its best foot forward and release something of significant and usable value. If we follow the thread of our word processor (the one we discussed in Part One and Part Two of this series) and creating the ability to automatically save documents as we write, we can start to understand this tension.
A word processor with the ability to automatically save the document I’m working on is a nice, differentiating feature. By itself, though, it doesn’t define a word processor. Our word processor needs spellcheck, and formatting options, and some file management capabilities so that authors can work on more than one document. Releasing our text editor with auto-save, but without the other features that our customers called useful in their interviews (you did some market research and user interviews, right?) leaves us with an interesting technical proof-of-concept, but without a word processor most people would purchase.
As a Product Owner, it’s too often taken as a given that you understand how to break your product backlog into small, deliverable chunks of value—what we can argue is a Minimum Viable Product. When I’m helping Product Owners who’re struggling with this concept, I like to focus on two things—the idea of “Viable”, and then the idea of “Minimum”.
Minimum Marketable FEATURE
When we’re looking at delivering value to our customers, one of the critical questions we have to ask is, “What would they buy?” In other words, if we released this product with this collection of features, would our customers pay for it?
To me, when I’m helping Product Owners, it’s some variation of that core question that helps me define what we mean by MMF. We can release small experiments and proofs-of-concept to a core group of trusted testers and early adopters, but our customers demand more.
Through the process of user interviews, writing personas, and segmenting your potential customers, you’ll quickly start to recognize that there are certain expectations your users demand. If you start to ask them interesting questions about what they would actually want—using things like “Buy a Feature” to create some prioritization conversations with your customers, stakeholders, and team for example—you can start to winnow down your giant Product Backlog into some interesting collections of features.
When we’re talking about our word processor and working with our focus groups, one theme starts to appear—there’s a market for a lower-priced alternative to some of the bigger names in the word processing space, where a smaller set of features with two key differentiators could actually solve some customer needs.
We look at our Product Backlog, and we decide that we’re going to target a great, focused writing product with auto-save and use Markdown to support our text formatting. Further, we’re going to focus on delivering our product on iOS first, since there aren’t many great word processors on iOS today.
(Yes, I know that’s not true as I write this blog post on my iPad Pro somewhere over North or South Carolina. Play along with me, okay?)
We’ve just defined our Minimum Marketable Feature—it’s not a complete word processor that will unseat the market leaders, but it’s marketable to a key portion of our users: it solves specific problems our early adopter mobile customers have, and creates a product we can release and start to sell to our customers.
MINIMUM Marketable Feature
When we start talking to our customers, the second tension we have is the idea of releasing the Minimum we can to provide something of value.
Henry Ford has an often-quoted line that, while over-used, is still incredibly relevant:
“If I had asked people what they wanted, they would have said faster horses.”
The question of whether Henry Ford actually said that aside (he probably didn’t) is the idea that our customers frequently don’t know what they actually want. A variation of “faster horses” I frequently see is what I call, “Oooh! That too!”
When we present our customers with a list of potential features, there’s a tendency for their eyes to quickly outgrow your team’s ability to deliver; each new possibility is exciting and “definitely” something they would want. As a Product Owner, it can be exhilarating to have all your ideas validated as not just interesting, but as something your customers would “definitely” buy!
One of the things I most enjoy about feature prioritization games like Buy a Feature is that they force difficult budgeting conversations—with customers, with stakeholders, with our team. There’s a real magic to creating a budget with our customers—“You only have $100 to spend”—and forcing conversations about value and priority.
However, even with that prioritization, we as Product Owners still need to ask, “Do you REALLY need that?” One way to ask is to offer different budgets to our customers in Buy a Feature—would they still rank those features that way if they only had $50? How about $25?
The goal isn’t to whittle away features until we’re left with a skeleton of a product; instead, the goal is to understand what the definition of the smallest set of features to solve a customer problem. Using our word processor example, if we shipped a version without support for Markdown formatting, but it still auto saved our documents, would you use it, or is there something you would use instead?
Until we have a product in our customers’ hands that they can use, we can’t learn what actually works. However, the more features we put into our MMF, the longer we have to wait—and the more we have to spend, and the bigger the opportunity for our competitors—to learn from our customers.
Defining a Minimum Marketable Feature is something that, when done well, looks like a dance between stakeholders, customers, and our team’s ability to deliver. No wonder being a Product Owner is hard!
Wrapping It Up
Product development asks a lot of Product Owners, and things like the Scrum Guide are frustratingly silent on the work that a good Product Owner has to do to build, maintain, and prioritize right-sized work for their teams. The Agile community doesn’t make it any easier, with a swarm of acronyms and at times self-contradictory ideas about how to build product increments.
I hope this helps clear up some of the confusion and, if nothing else, equip you with some ideas on how to feed your team experiments to validate assumptions and hypotheses, use that knowledge to define pieces of value to potentially ship, and a way to combine those pieces into releasable, marketable features to delight your customers.
Don’t forget to check out Part 1 and Part 2 of this series here:
Part Two: PSI