Agile Glossary

Minimum Viable Product (MVP)

What is Minimum Viable Product (MVP)?

A minimum viable product (MVP) is a concept from Lean Startup that stresses the impact of learning in new product development. Eric Ries defined an MVP as that version of a new product that allows a team to collect the maximum amount of validated learning about customers with the least effort. This validated learning comes in the form of whether your customers will actually purchase your product.

A key premise behind the idea of MVP is that you produce an actual product (which may be no more than a landing page, or a service with an appearance of automation, but which is fully manual behind the scenes) that you can offer to customers and observe their actual behavior with the product or service. Seeing what people actually do with respect to a product is much more reliable than asking people what they would do.


Expected Benefits

The primary benefit of an MVP is you can gain an understanding of your customer’s interest in your product without fully developing the product. The sooner you can find out whether your product will appeal to customers, the less effort and expense you spend on a product that will not succeed in the market.


Common Pitfalls

Teams use the term MVP, but don’t fully understand its intended use or meaning. Often this lack of understanding manifests in believing that an MVP is the smallest amount of functionality they can deliver, without the additional criteria of being sufficient to learn about the business viability of the product.

Teams may also confuse an MVP–which has a focus on learning–for a Minimum Marketable Feature (MMF) or Minimum Marketable Product (MMP)–which has a focus on earning. There’s not too much harm in this unless the team becomes too focused on delivering something without considering whether it is the right something that satisfies the customer’s needs.

Teams stress the minimum part of MVP to the exclusion of the viable part. The product delivered is not of sufficient quality to provide an accurate assessment of whether customers will use the product.

Teams deliver what they consider an MVP, and then do not do any further changes to that product, regardless of feedback they receive about it.


Potential Costs

Proper use of an MVP means that a team may dramatically change a product that they deliver to their customers or abandon the product together based on feedback they receive from their customers. The minimum aspect of MVP encourages teams to do the least amount of work possible to useful feedback (Eric Ries refers to this as validated learning) which helps them avoid working on a product that no one wants.


Origins

2009: The concept of MVP gained popularity after Eric Ries described it in his book The Lean Startup


Signs of Use

A team effectively uses MVP as the core piece of a strategy of experimentation. They hypothesize that their customers have a need and that the product the team is working on satisfies that need. The team then delivers something to those customers in order to find out if in fact, the customers will use the product to satisfy those needs. Based on the information gained from this experiment, the team continues, changes, or cancels work on the product.


Further Reading

The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses by Eric Ries

Add to Bookmarks Remove Bookmark
Add to Bookmarks Remove from Bookmarks
Add to Bookmarks Remove from Bookmarks

Thank you to our Annual Partners​

Join us today!

Agile Alliance offers many online and in-person events and workshops for our members. If you’re not currently a member, you can join now to take advantage of our many members-only resources and programs.

Get the latest Agile news!

  • This field is for validation purposes and should be left unchanged.

By subscribing, you acknowledge the Agile Alliance Privacy Policy, and agree to receive our emails.

Additional Agile Glossary Terms

An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios.
Test-driven development (TDD) is a style of programming where coding, testing, and design are tightly interwoven. Benefits include reduction in defect rates.
The team meets regularly to reflect on the most significant events that occurred since the previous such meeting, and identify opportunities for improvement.
A product backlog is a list of the new features, changes to existing features, bug fixes, infrastructure changes or other activities that a team may deliver in order to achieve a specific outcome.
An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios.
Test-driven development (TDD) is a style of programming where coding, testing, and design are tightly interwoven. Benefits include reduction in defect rates.
The team meets regularly to reflect on the most significant events that occurred since the previous such meeting, and identify opportunities for improvement.

Help us keep the definitions updated

Discover the many benefits of membership

Your membership enables Agile Alliance to offer a wealth of first-rate resources, present renowned international events, support global community groups, and more — all geared toward helping Agile practitioners reach their full potential and deliver innovative, Agile solutions.

Privacy Preference Center

Not yet a member? Sign up now