Why does Minimum Viable Product (MVP) matter?
The term is widely misread as "version one, but worse," which produces a shrunken product that tests nothing in particular. The useful definition starts from the question: what belief, if wrong, kills this company? Then build only what is needed to test that. Framed properly an MVP is sometimes not software at all, and recognizing that can save months.
What does Minimum Viable Product (MVP) look like in practice?
If the risky belief is that practices will let software touch their bookings, the MVP might be handling scheduling manually for three practices behind a simple interface — no automation, real answer. If the risky belief is technical, the MVP is a prototype nobody uses. Same company, entirely different builds, because the question differs.
What are the common mistakes with Minimum Viable Product (MVP)?
- Building a small version of the full product instead of a test of the riskiest assumption.
- Not naming the assumption first, which makes it impossible to say what the MVP is for.
- Shipping something so minimal it tests only whether people tolerate a bad experience.
- Treating the MVP as a launch. It is an experiment; launching is a separate decision.
Related concepts
- Problem Validation vs. Solution ValidationTwo separate tests: whether the problem is real and painful enough that people already do something about it, and whether your particular solution is one they would use and pay for.
- Design PartnerAn early customer who commits to working closely with you while you build — giving real feedback and real usage in exchange for influence over the product and usually favorable terms.
- Product-Market FitThe point at which a product satisfies a real need for a specific market well enough that demand begins to pull the company along rather than the company pushing the product.