The MVP is one of the most misunderstood concepts in software entrepreneurship. You start with a minimal scope, then requests pile up, features get added, and six months later nothing has been shipped. Staying focused is a discipline in its own right.
The Minimum Viable Product is a simple idea: ship as early as possible the most reduced version of the product that delivers real value to its first users. In theory, everyone agrees. In practice, the MVP is systematically contaminated by the fear of looking incomplete, stakeholder requests, and the temptation to prepare for 'what comes after'.
The enemies of the MVP
The first enemy is internal: perfectionism. An ugly, slow, or limited MVP is still an MVP — as long as it serves its learning objective. The second enemy is external: early customer requests. Before even validating the product's core hypothesis, prospects formulate specific needs. Each request seems reasonable. Together, they turn the MVP into an overengineered system. The third enemy is organisational: investor or management pressure that confuses feature richness with value.
What 'viable' actually means
Viable doesn't mean complete. It means the product answers a specific question: is someone willing to pay to solve this problem this way? Airbnb started with a static site and photos taken with an ordinary camera. Dropbox started with a demo video, without a working product. These MVPs were not incomplete — they were exactly sized to validate their hypothesis.
Techniques to stay focused
- Write the problem, not the solution: the problem statement must fit in one sentence. Any feature that doesn't directly serve that statement is out of MVP scope.
- MoSCoW applied to the MVP: Must have (essential to core value), Should have (important but not blocking), Could have (nice to have), Won't have (explicitly excluded). If your Must-have list exceeds five items, you're not building an MVP.
- Immovable timebox: set a non-negotiable delivery date. When time is limited, priorities become real.
- Say no with a backlog: every request excluded from the MVP is logged with a date. This allows you to say no without rejecting the idea — it just has its place after validation.
Un backlog court et priorisé est la marque d'un MVP discipliné.
An MVP never shipped learns nothing. An MVP shipped with three features and ten real users teaches you more than six months of specification.