The original definition of an MVP was to test a new product in the market to see if it’s viable. The product was either successful and you learned how to improve it or the product was a failure and learned why and what to pivot to.

MVP was supposed to be only at the beginning of a product. It is often misused within other contexts, such as a new feature rollout or even a redesign of an existing product. It’s meaning has been perverted to be the path of least resistance to release a product or feature. Even worse, in agile environments, an MVP is considered something that must be completed in a single sprint.

Problems It Causes

1. It’s easy to deprioritize anything other than function often resulting in a product that doesn’t actually accomplish user needs because it’s either too difficult to use or not useful enough.
2. The assumptions of testing a hypothesis are for early adopters. If you’re releasing a feature to existing users beyond early adopters, you risk giving mainstream users a half-baked solution that they will not accept as willingly as early adopters.
3. Product decisions are based solely on speed.
4. A sprint is an arbitrary unit of time and should have no influence over a product’s release or not. While you should certainly make product decisions based on time to execute, you should understand that work beyond a sprint is certainly acceptable.
5. It’s an excuse to not do discovery research. Arguments are made to put anything out there rather than learning beforehand.
6. It makes everyone believe an MVP must be a releasable product. In fact, MVPs work best as small tests and iterations follow to improve before releasing.
7. Related to #6, MVP becomes the de facto way to experiment. That is not an effective way to experiment. You should be experimenting at every stage of your product development lifecycle.

Redefining MVP

As the diagram above demonstrates, an MVP should be a complete product, at least to the user. While you could be doing everything manually behind the scenes, the important aspect of the MVP is that the user isn’t aware of it.

“The second hardest thing about Minimum Viable Products is that while you decide what’s minimum, the customer determines if it is Viable.”
– David J Bland

What to Do

• Be aware of your target users and what their core needs and expectations are. For example, if you’re targeting beyond early adopters a minimal product will likely not fair well.
• Design for the majority of users — eliminate or cut back effort for edge cases.
• Break down a complex feature into different building blocks to test smaller pieces, even seemingly unrelated blocks.
• Explore multiple prototypes to avoid tunnel vision.
• Test MVPs before release.
• Don’t release MVPs. If an MVP is released, there should be no expectation that it will be the foundation for future iterations.

“Remember that the goal of the MVP isn’t to scale or generate revenue, it’s to learn in the market by generating qualitative & quantitative data.”
– David J Bland

Check Other’s Attempts to Redefine the MVP

• MUD: Minimal Usable Design (reference)
• EVP: Exceptional Viable Product (reference)
• MDP: Minimum Delightful Product (reference)
• MVP: Minimum Valuable Product (reference)
• MLP: Minimum Learnable Product (reference)
• MSP: Minimum Saleable Product (reference)

References

• https://medium.com/precoil/7-things-i-ve-learned-about-lean-startup-c6323d9ef19c
• https://medium.com/@maxdunn/when-the-minimum-viable-product-is-not-enough-308d8f009b13
• http://thenextweb.com/dd/2014/10/22/maximizing-minimum-viable-product-get-high-results-without-releasing-minimal-product/
• http://www.webstock.org.nz/talks/scaling-lean-principles-process/