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.
The Lean Startup by Eric Ries