The MVP Trap: Why Minimum Viable Products Often Aren't
The Myth of the MVP
The MVP concept — build the minimum thing that lets you learn — is one of the most misapplied frameworks in startup product development. Teams invoke MVP to justify building fast, but then spend three months building something that's neither minimum nor designed to validate anything meaningful.
The result: expensive products that don't answer the questions they should have answered before they were built.
How MVPs Go Wrong
Too much minimum, wrong things. Teams cut features to ship faster, but they cut the features that would have revealed whether users actually want what's being built. The remaining features are the technically easy ones, not the value-proving ones.
No success criteria defined in advance. What would make this MVP a success? What user behaviour would tell you the core hypothesis is validated? If you can't answer this before you build, you can't evaluate it after. Most MVPs launch without these answers.
Stakeholder scope creep. "Just one more thing" is the most dangerous phrase in product development. MVPs expand as internal stakeholders add requirements, and the minimum viable product becomes the maximum justifiable product.
Building for demo, not for learning. An MVP should be designed to test a hypothesis, not to impress investors. These are often different products.
What a Real MVP Looks Like
A real MVP is the smallest thing that puts the core value proposition in front of real users and generates meaningful data about whether that value proposition works. That's it.
For some products, the real MVP isn't a product at all — it's a landing page with a waitlist. Or a manual concierge service that mimics what the automated product would do. Or a Figma prototype tested with 20 users. The cheapest test of a hypothesis is usually not code.
The Questions That Should Precede the MVP
Before scoping an MVP, answer these:
- What is the specific hypothesis this MVP is testing?
- What user behaviour would validate that hypothesis?
- What is the minimum set of functionality to generate that behaviour?
- How many users do we need to test this with to be confident in the result?
- What would we do differently if the hypothesis is wrong?
If you can't answer all five, you're not ready to build the MVP yet.
The Restructuring Moment
The most expensive version of the MVP trap is when teams build, launch, get ambiguous results, and then start restructuring the product — adding features, changing the core flow, pivoting the value proposition — while maintaining the original codebase.
Restructuring without a clear hypothesis is expensive. Restructuring without the story — the clear problem you're solving and who you're solving it for — is how products get stuck in permanent iteration without ever finding traction.
Get the story right before you build anything. The MVP exists to test the story, not to tell it.
