MVPs that survive contact with users
·2 min read ·Product · Mindset · Startup
MVP gets misunderstood constantly. People use it as a synonym for 'prototype' or 'thing we shipped before it was ready.' That's not what it is, and the misunderstanding leads to products that embarrass you and frustrate users.
A minimum viable product is complete within a deliberately narrow scope. It's not missing features—it's choosing not to have them yet.
The Difference
A prototype answers: 'can we build this?' An MVP answers: 'does anyone want this?' These are different questions. A prototype can be broken, inconsistent, and held together with duct tape. An MVP has to work reliably for the thing it claims to do.
What to Cut
- Advanced filtering and sorting
- Email templates with perfect design
- Admin dashboards
- Analytics beyond basic counters
- Multi-language support
- Dark mode
- Settings pages with 20 options
All of this can come later. None of it tests your core hypothesis.
What You Can't Cut
- The core action: whatever the product fundamentally does, it must do it correctly
- Error states: what happens when something goes wrong
- Basic security: auth, input validation, HTTPS
- The feedback loop: some way for users to tell you what's wrong
Shipping an MVP that loses data, exposes other users' information, or fails silently is not shipping an MVP. It's shipping a liability.
The Real Discipline
Building an MVP is mostly an exercise in saying no. The temptation to add 'just one more feature' before launch is constant. Every addition delays learning. Every addition is something you might have to throw away when users tell you what they actually need.
Ship the narrow thing completely. Learn. Expand.