What is an MVP? (And what it isn't)

The definition that actually works

MVP = minimum viable product = the smallest working product that tests your core assumption and gets feedback from real users.

The key phrase: "working product." Not a demo, not a pitch deck, not a Figma mockup. Something users can actually use and give feedback on.

The key phrase: "real users." Not your friends. Not people you pay to test. Real potential customers who found your product organically.

Example: you think "developers will pay $100/month for a tool that automatically optimizes their database queries." Your MVP: a web app where developers paste slow SQL, press "optimize," and see suggestions. No login, no payment, no UI polish.

The three things an MVP must have

First: one core feature. Not 10 features. One. The single thing you're betting on.

Second: real users trying it. 50+ people minimum. Ideally strangers who found your product without pressure from you. If you had to beg your mom to use it, that's a sign your positioning is weak.

Third: measurable feedback. Did they use it? How often? What did they ask about? What features are missing? You need data, not "it's great." Set up Mixpanel or PostHog. Track usage.

Without these three, you don't have an MVP. You have a prototype.

What an MVP is not

An MVP is not: a beautiful product. An MVP can have gray buttons and no animations. If it converts, it works.

An MVP is not: a complete product. It has 3–5 features, not 50. You'll add more after learning from users.

An MVP is not: a marketing event. "We launched on Product Hunt" is nice, but it's not validation. Validation is: users came back. Users asked about pricing. Users invited their friends.

The cost of waiting vs. shipping

Scenario one: you spend 6 months building the "perfect" product before launch. You spend $80,000 and launch with 50 features. You get 100 sign-ups, but only 5 stick around. You've wasted $80,000 and 6 months learning what users actually want.

Scenario two: you spend 4 weeks and $15,000 building an MVP with 3 features. You launch to 100 trial users. 20 stick around. You learn that users want feature X (which wasn't in your original plan). You pivot, build X in week 5, and 40 users stick around.

Scenario two is 10x smarter because you learn from users, not from your imagination.

How to know your MVP is complete

An MVP is complete when: users can accomplish the core action (sign up, create something, see a result). You can show it to strangers without 10 minutes of context. You've gotten feedback from 50+ users. You hear the same feedback twice (diminishing returns).

An MVP is not complete when: the database schema is perfect. The code is beautiful. The UI is polished. The marketing site is done. Those are nice-to-haves after validation.

Launching an incomplete MVP beats a perfect product that never ships.

From MVP to product

Once you've validated the core (users want it, they'll pay for it), you enter the product phase. Now: build more features based on user feedback. Scale the infrastructure. Hire a team. Create a go-to-market strategy.

This is different from an MVP. You're building to scale, not to learn.

But it all starts with an MVP. If you skip the MVP and jump to "product," you'll build what you think users want, not what they actually want.