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.
Further reading
The Lean Startup by Eric Ries
Related quotes
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.
The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.
The lesson of the MVP is that any additional work beyond what was required to start learning is waste, no matter how important it might have seemed at the time.
The only way to win is to learn faster than anyone else.
The MVP has just those features considered sufficient for it to be of value to customers and allow for it to be shipped or sold to early adopters. Customer feedback will inform future development of the product.