Why Your Minimum Viable Product Might Be Missing the Point
The minimum viable product has become the defining concept of modern product development — and one of the most consistently misapplied ones. Organizations that believe they’re practicing MVP-based development often produce products that are neither minimum (they contain far more than required to test the hypothesis) nor viable (they fail to create enough user value to generate the learning they were designed to produce).
The MVP concept was designed by Eric Ries to be a specific tool for a specific purpose: the smallest possible product that enables learning about whether a fundamental business hypothesis is true. This precision gets lost in most applications of the concept.
The Most Common MVP Failures
The “minimum” gets defined by budget, not by hypothesis: Most MVP specifications are driven by what the team can build in a given sprint or budget cycle — not by what’s required to test the specific hypothesis the product is supposed to validate. The result is an MVP that contains whatever features fit within constraints rather than the specific elements needed to answer the strategic question.
The hypothesis isn’t defined: You can’t build a minimum viable product if you haven’t defined the business hypothesis you’re testing. Many MVPs are built without explicit hypotheses — they’re just small product launches rather than learning experiments. Without a hypothesis, there’s no definition of “viable” and therefore no way to know whether the MVP served its purpose.
Viable gets confused with releasable: The “viable” in MVP means “capable of generating the learning the hypothesis requires.” It’s often interpreted as “releasable to customers” — which means building for user experience quality rather than for hypothesis testing. This confusion produces MVPs that cost significantly more than necessary and take significantly longer than necessary to produce the learning they were meant to generate.
Shipping and moving on: The MVP concept requires learning from the product in the market and using that learning to inform the next iteration. Teams that build an MVP, launch it, and immediately move to the next initiative without extracting the learning are missing the point entirely. The MVP was the setup; the learning is the value.
What Genuine MVPs Look Like
A genuine MVP begins with a specific hypothesis: “We believe that users who experience X workflow will be willing to pay $Y for Z capability, because our research suggests that W is the primary motivation.” The MVP is then designed to test that specific hypothesis — no more, no less.
The MVP might be a landing page that describes the product without the product being built. It might be a manually-operated prototype that simulates automation. It might be a restricted beta with a specific user segment. The format is secondary to the specificity of the hypothesis and the validity of the test.
Key Takeaways
Most MVPs fail because the hypothesis they’re designed to test isn’t defined, because “minimum” gets defined by constraints rather than by what’s required for the test, and because teams ship and move on without extracting the learning the MVP was designed to produce. Genuine MVP practice begins with a specific, testable hypothesis and designs the smallest possible product to test it — creating learning rather than rushing product launches.
The Discovery Imperative
The most consequential implication of recognizing genuine MVP practice is the discovery imperative: the hypothesis you’re testing must be specific enough to be tested before a single line of code is written. The MVP is the test instrument; the hypothesis is what determines whether the test was worth running. Product teams that invest in defining specific, testable hypotheses before building consistently build products with better product-market fit than those that default to feature launches without explicit hypotheses.