PM Articles > Kent McDonald > The Minimum Viable Column

The Minimum Viable Column

by Kent McDonald

I'm in the process of putting the final touches on the book I've been working on for three years and I thought I would share an excerpt from that book that discusses a couple of concepts that are very helpful for any scope minded project managers out there, Minimum Viable Product and Minimum Marketable Feature.

Following is an excerpt from the forthcoming book, Beyond Requirements from Addison-Wesley, ISBN 9780321834553, publishing in September 2015. Available wherever fine technical books are sold (InformIT or to name a couple of places).

Minimum Viable Product

Eric Ries introduced the concept of minimum viable product in his writings on Lean Startup. This is the most straightforward description he provides (The Lean Startup, Chapter 6):

"A minimum viable product (MVP) helps entrepreneurs start the process of learning as quickly as possible. It is not necessarily the smallest product imaginable, though; it is simply the fastest way to get through the Build-Measure-Learn feed-back loop with the minimum amount of effort."

Contrary to traditional product development, which usually involves a long, thoughtful incubation period and strives for product perfection, the goal of the MVP is to begin the process of learning, not end it. Unlike a prototype or concept test, an MVP is designed not just to answer product design or technical questions. Its goal is to test fundamental business hypotheses.

The main purpose of MVPs as defined by Ries is learning what customers find valuable, not necessarily delivering value to customers. Additionally, learning is trying to figure out business as well as product design and technical questions, and in the early stages it is most likely focused on the business questions.

MVPs are a technique that your team can use to carry your discovery activities forward through your delivery process. It's a key component of the Build-Measure-Learn loop because it's the thing that teams build in order to gather feedback and learn from it.

That's all stated from the startup context. What value can the MVP concept bring to IT projects? Primarily, the MVP can be used when testing solutions. We may find that we get a lot of information from our stakeholders about what they believe their needs are, and we may even pull some data from a variety of sources that tells us how our stakeholders behave, but at the end of the day the most effective way we may find to see if our solution is really going to satisfy our stakeholders' needs is to build it, try it, and see what happens.

The idea of the MVP, even in the IT project context, means that the purpose of an iteration is to either learn or earn. Initially your team is trying to learn about the problem and solution by doing things to validate assumptions, address risks, or make progress toward your desired outcome. Your team produces some output that while not a complete solution does provide information for the purpose of testing your hypothesis. In effect, you're saying, "We think this is going to work, but we won't know until we try it, so let's see what happens."

Your team may be able to provide something for stakeholders at the end of an iteration, get feedback, and have a pretty good idea of whether it will work or not. The benefit of this approach is that you can get feedback sooner because you don't have to build a solution that's conceptually complete, just enough that you can get feedback on it.

When the intent of a sprint is learning, it's important that you have a specific question in mind that you are trying to answer. This can be stated as your sprint goal so that it's clear to your entire team.

What does an MVP useful for feedback in an iteration setting look like? I worked with a team recently that was building new analytic capabilities for an organization that traded securities. The team was working on an effort to incorporate a new source of data into an existing data warehouse, and one of the first things they needed to do was verify that they could successfully merge data from the new source into an existing source. They selected a view of the data that represented a simple listing of securities but contained attributes from multiple sources. Instead of worrying about creating a pristine report or moving the data through all the various architectural layers, they chose to start by associating data from the new source into the existing data and generating a query using Excel. They were able to show the data they expected to see in the final report without spending a lot of time designing the report or building all of the background infrastructure perceived as necessary to automatically integrate the data in the long run. They had to determine whether they could combine data from the disparate sources correctly.

Doing it in this manner let them immediately identify where they had some logic corrections to make, and they were able to find that out in a couple of weeks. Had they taken the typical approach to building up a data warehouse, they might not have uncovered the issues they found until months down the road, because they wouldn't have been able to isolate where the problem occurred. In addition, they were able to quickly get meaningful feedback from their stakeholders about which attributes were really needed and specific rules on how to match data from the disparate systems.

On the other hand, your team may figure out that the only way to truly know whether an MVP will work is to let stakeholders use it in actual day-to-day business. In this case, the MVP may represent a more complete change than the version that was demoed at the end of a sprint.

In the preceding analytics example, this type of MVP happened when the team released one full-fledged report to its stakeholders. Here, they were trying to find out if the reporting interface was helpful to the stakeholders and if the organization of the reports made sense. This one report would still be useful, but real value would be generated when multiple reports were available. How-ever, by delivering this one report first, the team learned a great deal about the stakeholders' needs, and the stakeholders gained a better understanding of their needs and the reporting capabilities.

Either way, understanding the MVP idea keeps teams from feeling compelled to define too much information up front and encourages them to see delivery as a way to validate assumptions and test hypotheses.

The other important aspect of the MVP concept is the implied focus on speed. You seek the minimum viable product (or change to an asset) because it means you can get it done sooner, get it in front of stakeholders sooner, and get feedback sooner. All of that means that you aren't wasting time heading down a road that leads nowhere; and if you are, you aren't wasting nearly as much time on that dead end.

Minimum Marketable Features

Minimum marketable feature (MMF) is a similar concept that came out a few years before the idea of MVP. While the ideas are similar, there are some significant differences.

Given our focus on delivering value, we may find it helpful to organize our work based on how much value we're providing. In 2004, Mark Denne and Dr. Jane Cleland-Huang came up with a way to do that called the minimum marketable feature (MMF):

  • Minimum -- the smallest possible group of features that deliver significant value to the user
  • Marketable -- provides significant value to the customer
  • Feature -- something that is observable to the user

Their ideal MMF is a small, self-contained feature that can be developed quickly and that delivers significant value to the user. Denne and Cleland-Huang define MMF in the context of a software product (again, externally focused) where the concept of marketability makes sense. Since I am examining internally focused efforts here, our definition of MMF needs a slight adjustment. In this case, "marketable" means "provides significant value to the stakeholder," where value is measured as progress toward a specific objective. We still want to group the work we're doing in terms of MMF for our stakeholders to sequence, though we may not necessarily use the rigorous analysis suggested by Denne and Cleland-Huang to do so. When I talk about features and user stories later, I expect the features to have the characteristics of MMFs. I chose not to label them that way because I am not talking about the context of building a product for sale.

Another good tidbit of information from Denne and Cleland-Huang is that MMFs make the best unit of planning for releases. Since this is the concept of when we are deploying to our stakeholders, we want what we are deploying to be a conceptual whole, but we may build up parts of those features in separate iterations and deliver those to our customers for the purpose of getting feedback. Features are the main planning unit for releases, and user stories are the main planning unit for iterations.

Context is a final important difference between MMF and MVP. MMF grew up in the world of established organizations that were building large products or maintaining existing ones. In this book, I am extending MMF to IT projects. MVP meanwhile was created for use in the context of starting a new business. While many people (including me) would like to apply Lean Startup ideas to established enterprises—and there are places where that does work—it is often the underlying principles these ideas embody more than the direct application of the ideas themselves that are important to understand. So when deciding when to use MMF or MVP, consider your context and choose appropriately.

Some people tend to confuse minimum marketable feature with minimum viable product because they both happen to have "minimum" in their name. The MMF is the smallest set of functionality that provides significant value to a stakeholder, whereas MVP is the version of your product that lets your team complete the Build-Measure-Learn loop as quickly as possible with the least amount of effort. In other words, MMF is definitely about delivering value to stakeholders, whereas MVP is about learning more about the ultimate product. The MVP could range anywhere from not having any MMFs, to having a single MMF, to having several MMFs. They are not the same concepts, but both rein-force the idea that we should be seeking, in Alistair Cockburn's words, "barely sufficient" functionality.

Both concepts are also often misinterpreted to mean "crap." They don't.

Whatever functionality is deployed should work, should be supportable by the organization, and should be something that you would be proud to put your name on. It's just limited functionality that focuses on the core of what you are trying to accomplish, be that satisfying a particular need (MMF) or learning more about how you may be able to satisfy a particular need (MVP). Remember that the names are minimum marketable feature and minimum viable product for a reason.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.