MVP is the most misused term in startup land. Here's a definition you can actually ship against — and a checklist to know when you're done.
Minimum Viable Product is the most overloaded term in startup vocabulary. Founders use it to mean "v1." Investors use it to mean "proof of traction." Designers use it to mean "the un-polished version." Engineers use it to mean "whatever we can ship by the deadline." Everyone agrees it matters. Almost no one agrees what it is.
Here is a working definition that actually helps you ship: an MVP is the smallest version of your product that lets you learn whether your core hypothesis is true. Not the smallest version of your dream product. Not the most polished thing you can ship by Q3. The smallest learning instrument.
The three words, decoded
Minimum
Minimum means uncomfortably small. If the scope feels generous, you're not building an MVP — you're building a v1. Minimum is measured against the hypothesis, not against the dream.
Viable
Viable means it actually works end-to-end for one real user, doing the one thing you care about. Viable is not "functional in demo." Viable is "a stranger can complete the core action without you in the room."
Product
Product means it has a beginning, a middle, and an end for the user. Not a prototype. Not a clickable mock. Something a human can use to solve a real problem, however narrowly scoped.
The hypothesis test
If you can't write your MVP's hypothesis in one sentence, you don't have an MVP — you have a wishlist.
The format I use with clients:
If we give [specific user] the ability to [specific action], they will [observable behavior] because [underlying motivation].
Example: "If we give freelance bookkeepers the ability to import a client's Shopify transactions in one click, they will pay $49/month because manual reconciliation is the most-hated part of their week."
Notice what that sentence does. It names the user. It names the action. It names the behavior you're testing for. It names the why. Every feature in the MVP either supports that sentence or gets cut.
What an MVP is not
- It is not v1 with the rough edges sanded off. v1 ships after the MVP teaches you what to build.
- It is not a prototype. Prototypes can't be used by real users to do real work.
- It is not "the cheap version." Cheap is a budget constraint. Minimum is a learning constraint. They sometimes overlap, but they're not the same thing.
- It is not a landing page. Landing pages test interest, not behavior. They're great validation tools, but they don't replace a product.
- It is not every feature your competitors have. Parity is a v2 problem.
The "done" checklist
You are done scoping your MVP when all five of these are true:
- The hypothesis fits in one sentence.
- Every feature in scope directly supports testing that hypothesis.
- A user can complete the core action end-to-end without your help.
- You know what signal counts as "hypothesis confirmed" and what counts as "hypothesis refuted."
- You can describe the out-of-scope list out loud without flinching.
If any of those is shaky, you're scoping a v1, not an MVP. That's fine — but call it what it is, and budget accordingly.
Good MVPs feel uncomfortably small
The discomfort is the point. Every founder I've worked with has had a moment, mid-scoping, where they say something like "but if we ship without [feature], people will think we're not serious." That moment is the most important signal in the entire process.
What you're feeling is the gap between your dream and your hypothesis. The dream wants polish, scope, and reassurance. The hypothesis just wants signal. If you fund the dream, you'll spend $120K to learn something you could have learned for $40K. If you fund the hypothesis, you'll learn fast, cheap, and with enough runway left to act on what you learned.
Validation beats polish. Every time. At this stage only.
Where this fits in your roadmap
Think of your first 12 months as three distinct artifacts, not one product:
- The MVP: proves the hypothesis. Tiny scope, real users, clear signal.
- The v1: built on what the MVP taught you. Broader scope, paying users, real onboarding.
- The v2: the polished, defensible version. Built on what v1 revenue tells you.
Founders who collapse all three into one build are the ones who run out of money in month seven.
What to do next
Write your hypothesis sentence today. Show it to three people who aren't you. If they can repeat it back without paraphrasing, you have something to scope against. If they can't, the sentence isn't tight enough yet.
If you want help pressure-testing it before you scope a single feature, that's exactly the work of a Founder Clarity Session.