MVP is Always More Minimal Than You Think

The M in MVP stands for Minimum, not Maximum. If your idea of MVP incorporates every potential use case, every potential mix of audience, all facets of available functionality, and creates a backlog that would take a development team longer than 90 days to complete, you don't have Minimum Viable Product. On the contrary, you have a different beast altogether that all too many times bring teams to their knees causing unnecessary rework, lost cycles, lost revenue, and all the other dysfunctional misery that comes with working on a product that isn't well defined and validated with its users.

In written context, the idea of defining MVP seems simple; the challenges surface when teams try to outline and define what minimal means in terms of their initial product release. "How Minimal is Minimal?", "Can I have multiple core functions?", "Are all my use cases covered and accounted for?", and "Can I have more than 12 buttons on a screen?" All these and many other questions make it difficult to know whether our proposed MVP is truly minimal and viable.

This guide is designed to act as a benchmarking tool, and will help ensure that you have successfully defined and validated an MVP that's ready for market release.

We're going to cover the following topics:

• What is MVP?
• How to define your MVP
• Fail fast/validate everything
• Iterate and evolve your MVP - from viable to lovable