Minimum Viable Product (MVP)

A Minimum Viable Product (aka MVP) is the smallest, value-adding feature-set a release should have to provide sufficient feedback to validate an idea. The concept was popularized in The Lean Startup by Eric Ries which outlined a methodology to shorten the learning & validation cycles in product development. Defining a MVP requires a hypothesis that requires validation but rather than basing each iteration of experimentation on hunches and intuition, this methodology relies on gathering customer feedback to gauge success.

The minimum part of a Minimum Viable Product reminds those deciding what will and won’t be included in a release to consider what functionality is just enough to validate a concept. It’s tempting for product teams to allow scope-creep (more functionality than is required to validate an idea) to make their way into a release. This is especially true in organizations that release infrequently. An infrequent release cadence (aka Waterfall) causes teams to attempt to cram in as much functionality into a release as possible or else (ironically) it’ll be a long time before any opportunities for changes will occur in the future. This approach becomes a self-fulfilling prophecy and positive-feedback-loop, causing each release cycle to get wider and wider apart over time.

The viable part of a Minimum Viable Product reminds those deciding what will and won’t be included in a release to consider what functionality actually provides value to customers. In attempts to beat deadlines or over focusing on the minimum at the expense of the viable, some product teams will cut corners and deliver functionality that is half-baked, not valuable or of low quality. Though perfection isn’t required. Perfectionism is often a mental barrier to a MVP mindset as it can paralyze product teams from releasing products that don’t have all possible benefits that it could have. What constitutes a Minimal Viable Product vs what is just a Minimal Product is illustrated well by Henrik Kniberg (author of the book Lean from the Trenches) with the following example:

In order for teams to know if they are on the right track with what they’re releasing, they need to deliver value in each iteration. If a customer’s problem is that they need to get somewhere safely and quickly, providing them with just a wheel isn’t going to solve that problem. Likewise, providing a car without a steering wheel isn’t going to be viable. Jumping to an end-solution that customers want (without delivering iterative value) will be costly to the product’s brand and will incur opportunity costs (since no value was being exchanged along the way). When releases are so minimal that they aren’t viable, it’s unlikely to eventually deliver solutions customers want since there aren’t any signals from customers that the product is evolving in the right direction. Alternatively, delivering the metaphoric skateboard in an initial release is both minimal and viable. It will attract early adopters who will signal the usefulness and desired upgrades to the future product. Each iteration along the way can provide value, solve problems and make existing users happy as well as attract more customers.

MVP vs MMP

A minimum viable product (MVP) is different from a minimum marketable product (MMP). An MVP is the threshold at which the smallest form of a product is thought to validate whether a concept is valuable to a customer.

It is often validated through a prototype or a closed beta where a limited number of users can test the product or feature before the broader market has access to it. In an MMP, the threshold is more stringent. It comes after the MVP has been validated and the business (marketing, sales, product, UX, development, and support) is ready to fully sell, market, and support the new functionality.

For example, a team developing a video game app might not know what features customers are willing to pay for so they might release an MVP version as a closed beta to a few hundred users. Then, after several cycles of adjusting their product according to customer feedback, they will discover a threshold at which the MMP is clear. Once the MMP is built and the beta group is responding positively, then it is ready to be released to the broader market.

Some questions to ask when determining where to draw the line between MVP and MMP.

MVP:

• What minimal functionality can we deliver to customers that is still valuable on its own?
• Will early adopters think we’re wasting their time if they try to use this product?
• What is the smallest experiment we can perform that we believe will validate our hypothesis?
• What features are we intentionally leaving out for the first iteration because we believe customers can still find value in the product without those features?

MMP:

• At what point do we feel comfortable selling this functionality to the broader market?
• Which features need to be released before we believe the product will sell?
• At what point do we think we’re ready to fully support this new product as a business (development, customer success, and so on)?
• At what point do we think this functionality is noise-worthy with the broader market?
• At what point will we feel proud to show this to market influencers?
• If we release this as is, will customers be excited or will we be damaging our brand?

While the objectives of MVP and MMP are different, a key similarity is that the business is attempting to define a minimum threshold at which both business goals and customer needs are being met. Neither the MVP nor the MMP should include every feature the product could possibly have. Delivering minimal, incremental value requires discipline. When done right, this approach ensures that resources are efficiently allocated and that future objectives don’t delay time-to-value.

Further reading

The Lean Startup by Eric Ries

Related quotes