Skip to content

Minimum Viable Solution

Definition

Patton rejects the common reading of MVP as "the product that your users could use, but only in the simplest of circumstances, and only if they had a high threshold for pain." His definition instead borrows "viable" from biology: an organism that can survive on its own without dying. "The minimum viable product is the smallest product release that successfully achieves its desired outcomes" — and because most real work is a feature or improvement rather than a whole new product, he prefers "minimum viable solution." Minimum is inherently relative to specific customers and users and what they need, not to what the team wants to build; naming that group precisely is what makes the definition usable rather than a slogan.

In the Book

The mechanism the book pairs with the definition is physical slicing: after mapping the full breadth and depth of a product idea, teams stretch a line of blue painter's tape horizontally across the map and move cards above or below it — above the line is the release, below is deferred. Globo.com's teams did this to carve their election-focused release out of a much larger content-management map; Gary from Mad Mimi did it independently, eventually narrowing his sprawling original vision (band managers, fans, venue managers, production musicians) down to just band manager, fan, and an internal administrator — which became the actual email-promotion platform Mad Mimi shipped. Patton is explicit that this slicing is a guess, not a measurement: "we don't really know if it is" viable until it's out in the world, because outcomes "you can't really observe... until things come out." Guessing too small fails to be minimal; guessing too large (the common hedge) burns time and money that may not exist. He notes the "crappiest possible" definition persists precisely because it's the one interpretation that doesn't require anyone to guess.

Why It Matters

Reframing "minimum" around a named outcome for named people, rather than around technical simplicity, turns an argument about taste ("is this good enough to ship") into a testable claim ("will this specific group actually get the specific benefit"). It also makes explicit that any first release is a hypothesis about what's sufficient, not a proven floor — which matters anywhere a team is tempted to either under-scope out of haste or over-scope to hedge against being wrong, from a product launch to a pilot program to a first draft of a policy.