An MVP is not a small product
The most misused word in startups. An MVP isn't a cheaper, smaller version of the real thing — it's the smallest serious version that proves the most important assumption. The difference matters.
"MVP" might be the most misunderstood phrase in startups. Most people hear minimum and build something small and cheap — a stripped-down version of the eventual product, with the corners rounded off and the polish removed. Then it lands with a thud, and they conclude the idea was bad. Usually the idea was fine. The MVP just wasn't built to prove anything.
The word doing the work is "viable," not "minimum"
A minimum viable product has to actually be viable — good enough at its one job that a real person's response to it means something. A half-built, apologetic version isn't a smaller test of your idea; it's a test of your ability to ship something bad, and it produces exactly the misleading signal you'd expect. People don't reject it because the concept is wrong. They reject it because it's not good yet, and you learn nothing about the concept.
An MVP is an experiment with a hypothesis
The reframe that fixes this: an MVP isn't a small product, it's an experiment. And an experiment needs a hypothesis. Before I scope one, I make the question explicit — what is the single most important thing we don't yet know, that would sink this product if we're wrong? The MVP is then whatever it takes to answer that one question convincingly. Nothing more, because the rest is noise. Nothing less, because a weak answer to the key question is worse than no answer — it gives you false confidence in either direction.
Minimum in scope, serious in quality
This is the balance people miss. An MVP should be ruthlessly minimal in scope — one loop, one job, one question — and genuinely serious in quality within that narrow slice. Take a note app: the MVP shouldn't have folders, tags, sharing, and sync all built halfway. It should do one thing — capture a thought and let you find it again — and do that one thing well enough that people actually rely on it. Narrow surface, real depth. That's what makes the result trustworthy as evidence.
Small thinking is the real risk
The failure isn't building too little. It's thinking too little — treating the MVP as a budget exercise ("what's the cheapest thing we can ship?") instead of a learning exercise ("what's the smallest thing that would teach us the truth?"). Those two questions produce very different products. The first gives you a weak version of everything. The second gives you a strong version of the one thing that matters, and a clear signal you can actually act on.
So when someone tells me they're building an MVP, my first question is never "how small is it?" It's "what will it prove?" If they can answer that cleanly, the scope tends to sort itself out.
If you're scoping an MVP and want to make sure it's built to prove something — not just to be cheap — let's talk it through.
Written by
Entrepreneur, product strategist & experience designer
I build, advise, and invest in digital products — founder-first product strategy, AI-native experiences, and UX across industries. I run Zenith Studio, my AI-native product studio, from Kathmandu, working with founders globally.
Keep reading
Clarity is the real product work
Most products aren't confusing because the idea is bad — they're confusing because the thinking behind them was never made clear. Here's how I treat clarity as the actual work, not the polish at the end.
Read →Playbook · 7 minHow I pressure-test an idea before building it
Before I write a line of code or design a single screen, I try to kill the idea cheaply. Here's the sequence I use to find the assumption that would sink a product — while it's still free to be wrong.
Read →Turn the idea into a product.
If this maps to what you're building, let's talk it through.