Agile software development is an evolving discipline.  The authors of the “Agile Manifesto” and its associated “12 Principles of Agile Software” distilled commonalities across a number of Agile approaches into a simple, complete, and cohesive set of values and principles.  Defining Agile as a set of values and principles to align to, rather than as a methodology to follow, encouraged creation of new software development approaches and best practices.  As long as new approaches and practices align with the Agile Manifesto and 12 Principles, we can consider them Agile.  This decentralized approach to Agile adoption democratized Agile, allowing us to adopt existing approaches, tailor them, reject them, or create our own.

Agile theory and practice are firmly rooted in empiricism.  Agile shares this characteristic with Lean management and product development.  As a result, many Agilists (knowingly or not) have incorporated Lean and product development concepts into Agile approaches. 

One of the better known product development influences on current Agile thinking and practice is the concept of the Minimum Valuable Product (MVP).  MVPs dovetail nicely with Agile empiricism and value delivery.  However, competing definitions of MVPs, as well as popularization of other product development concepts such as Minimum Marketable Features (MMFs) and Minimum Marketable Products (MMPs), have caused confusion across Agile software development efforts.  This article explains the definitions of each of these concepts and how they align with Agile software development.

Rationale Behind MVPs

Product development is the process by which product teams bring products to market, from original idea to market release and beyond.  Successful products solve problems important to customers in target markets, in ways that satisfy their needs and desires, and at the right price. 

An MVP is a simple and quickly produced version of a product that allows product developers to validate their assumptions.  MVPs help determine market fit and provide useful feedback that further informs product development.

MVPs are ultimately about lowering risk.  The biggest risk in any development effort is building the wrong thing.  In the commercial space, this translates into creating something the target market is unwilling to pay for.  In organizational IT this risk manifests as system implementations that do not meet the needs of the Stakeholder Community (i.e., sponsors, stakeholders, customers, and end users).  Building the wrong thing negates all of the time, effort, and expense spent developing the product.

Agile Software Development and MVPs Align

Continual product validation is baked into Agile approaches such as Scrum.  Agile teams continually validate that they are building the right things while verifying (through continuous testing) that they are building them the right way.  They also deliver valuable software functionality iteratively and incrementally.  Doing so affords development teams multiple opportunities to validate solutions with relevant Stakeholder Community members throughout development.  Stakeholder input and lessons learned inform ongoing adaptive planning, requirements definition, design and implementation approaches, and development practices.  Use of MVPs to validate solutions aligns with this empirical approach to software development.

Confusion over MVPs

The main source of confusion around MVPs has to do with whether an MVP is the first version of a marketable product or a vehicle for validating product assumptions and learning about target markets and customer needs.  The first definition seems to align with the word “product” in MVP while the second makes MVPs sound more like prototypes.  The root of the problem is that both definitions are correct depending on the type of product and market the product team targets.

Frank Robinson’s MVP Definition

Many attribute the coining of the term MVP to Eric Ries.  Ries is the author of the 2011 book, “The Lean Startup.”  That book popularized the term MVP.  However, Ries did not invent the term.  That credit goes to Frank Robinson, cofounder and president of Syncdev, a product and marketing development company.  He coined the term in 2001 and his company published a white paper in 2008 that defined an MVP as:

The right-sized product for your company and your customer. It is big enough to cause adoption, satisfaction and sales, but not so big as to be bloated and risky. Technically, it is the product with maximum ROI divided by risk. The MVP is determined by revenue-weighting major features across your most relevant customers, not aggregating all requests for all features from all customers.

https://web.archive.org/web/20090105160002/http://www.productdevelopment.com/howitworks/mvp.html, accessed 7/17/2022

Syncdev’s product development approach started with identifying a technically and financially “feasible” product idea.  The product team executed product development and marketing strategy in tandem.  The high-level product development journey looked like this:

It is important to emphasize that, under Syncdev’s approach, an MVP was the first version of the product.  It was the smallest version of a product customers were willing to pay for.  This approach was best aligned with selling business-to-business (B2B) or internal IT software systems to specific prospects.  It was not conceived for selling commercial products to larger market segments.  Those markets were better served by Eric Ries’ definition of the MVP.

Eric Ries’ MVP Definition

Eric Ries defined an MVP as, “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”[1]  This type of MVP is primarily focused on finding out what customers need and want based on a set of features most likely to attract paying customers.  In this case, an MVP could be a prototype, a mock up, landing page, or “minimal” version of the product.  As Ries stated:

As you consider building your own minimum viable product, let this simple rule suffice: remove any feature, process, or effort that does not contribute directly to the learning you seek.

https://libquotes.com/eric-ries/quote/lbq3c8m, accessed 7/17/2022

The objective here is not to develop a product to sell immediately but instead to learn more about customers and their markets while validating customer and product assumptions.  As product teams gain knowledge and understanding, they may develop additional MVPs of increasing complexity to test out additional ideas.  While an MVP may turn into a sellable product, that is not the focus of this type of MVP.

SAFe’s MVP Definition

The Scaled Agile Framework (SAFe) includes a definition of MVP that reads like a hybrid of Robinson’s and Ries’s definitions.  It supports validated learning as well as development of a potentially releasable software capability. 

As opposed to story boards, prototypes, mockups, wire frames and other exploratory techniques, SAFe’s version of the MVP is an actual product that can be used by real customers to generate validated learning.

https://www.scaledagileframework.com/epic/, accessed 7/17/2022

In the context of SAFe, an MVP is an early and minimal version of a new product or business solution used to prove or disprove an “epic hypothesis.”  Every SAFe epic attempts to validate a set of core assumptions that support its formulation.  As depicted in the diagram below:

1. Every epic proposes an MVP
2. The organization determines whether the software functionality developed under the epic proved the epic hypothesis
3. If the associated software capability proves the epic hypothesis, then the MVP becomes the first released version of that product, solution, system, sub-system, etc. We may continue developing the epic or consider the epic done.
4. If the functionality fails to prove the epic hypothesis, then we have the following options:
   1. Pivot away from the current MVP and formulate a new epic and associated MVP
   2. Cease further development of the epic or abandon it and its MVP all together

The SAFe Lean Startup Cycle treats epics as potentially releasable capabilities and aligns budget considerations with MVP development while incorporating validated learning.

Minimum Marketable Feature (MMF)

Adding to the confusion over MVPs is the concept of MMFs.  Mark Denne and Dr. Jane Cleland-Huang introduced this concept in their 2004 book, “Software by Numbers: Low-Risk High Return Development.”  They defined an MMF as, “A small, self-contained feature that allows companies to develop the product quickly while still delivering significant value to customers.”[2]

The value of MMFs is that they ensure that development teams deliver value as features.  Features are cohesive and complete slices of system functionality capable of performing useful work from the perspective of customers and end users.  This contrasts with traditional software systems development which is organized around developing and integrating components.  A feature does not need to be user-facing.  For example, client systems that communicate with a backend service are that service’s customers.  Incrementally developing, updating, and delivering software systems as features aligns with Agile’s iterative and incremental value delivery.  You can learn more about the benefits of feature-based development here and here.

An MMF differs from an MVP in that it is a way of delivering value to customers and end users, not a validated learning technique.  It is the smallest amount of value we can market to customers and end users.  Nevertheless, delivering capabilities as features provides multiple opportunities to validate the product as it is built, deployed, and released, thus supporting Agile empiricism.

Minimum Marketable Product (MMP)

Many people use the term MMP interchangeably with MMF.  Some describe MMFs as individual features that collectively make up an MMP.  Regardless, the idea behind MMPs is to build and release the smallest feature or set of features we can market to customers and end users.

Another school of thought considers an MMP to be the smallest or simplest marketable version of a product resulting from the application of lessons learned from one or more previous MVPs.[3]  In other words, after validating product ideas via one or more MVPs, the product team develops a simple marketable version of the product based on previous validated learning.

Conclusion

Every validated learning approach explained in this article emphasizes validating our assumptions about markets, customers, users, and products as quickly and frequently as possible.  We do not know how good our product idea is until actual customers and end users get their hands on it.  Until then, our assumptions and plans are just guesses / hypotheses in need of validation.

---

[1] https://leanstartup.co/what-is-an-mvp/, accessed 7/17/2022

[2] https://www.agilealliance.org/glossary/mmf/#q=~(infinite~false~filters~(postType~(~’post~’aa_book~’aa_event_session~’aa_experience_report~’aa_glossary~’aa_research_paper~’aa_video)~tags~(~’mmf))~searchTerm~’~sort~false~sortDirection~’asc~page~1), accessed 7/17/2022

[3] https://www.xdesign.com/blog/minimum-viable-product-vs-minimum-marketable-product-whats-the-difference/, accessed 7/18/2022

Last Updated on July 19, 2022