Most product projects I see fail don't die of a technical problem. They die of scope. Everyone wants to build everything at once: the dashboard, the notifications, the subscriptions, the mobile app. Six months later, nothing is live, the budget is gone, and nobody has checked whether anyone actually wants the product.
The MVP exists precisely to prevent that. But the term has been so overused that it needs redefining before we can use it.
An MVP is not a cut-rate version
MVP means minimum viable product: the smallest product that lets you test your core hypothesis. The important word isn't "minimum". It's "test".
An MVP is not your final product with less polish. It's a measuring instrument. Its success isn't judged by how pretty it is or how many features it has, but by a single question: did it teach you something decisive about your users?
In practice, that changes everything. If your hypothesis is "tradespeople would pay for a simplified quoting tool", the MVP doesn't need team management, accounting exports, or dark mode. It needs a way to create a quote, send it, and see whether tradespeople come back the next day.
Cutting scope: the hard part
Cutting scope is the most uncomfortable part of the job, because every feature you drop feels essential. My method comes down to three questions, asked for every feature on the wishlist:
Can the core hypothesis be tested without it? If yes, it's out of the MVP. No negotiation. Maybe it makes the V1, but not this.
Can a human replace it temporarily? Many things people want to automate can be done by hand at first. Sending the emails yourself, approving sign-ups manually, generating documents one at a time. It's uncomfortable, but it saves weeks of development on a product that hasn't yet proven anyone wants it.
Does its absence drive users away on first try? Careful here: some things are non-negotiable even in an MVP. A product that loses data, crashes, or is unusable on mobile when your audience is mobile doesn't test anything at all — except people's patience.
The traps I see most often
The first trap is the phantom MVP: you say "MVP" but build the full V1, reassuring yourself with vocabulary. The telltale sign: the feature list never shrinks, it grows.
The second is the opposite: an MVP so stripped down it no longer tests anything. A landing page with a "Coming soon" button measures curiosity, not usage. That's sometimes enough to gauge interest, but don't confuse the two levels of proof.
The third is the MVP with no success criteria defined up front. If you don't know, before launch, what would make you say "it works" or "it doesn't", you'll always find a reason to keep going. Set the threshold beforehand: how many active users, how much feedback, how many come back in week two.
Moving to V1
If the MVP validated the hypothesis, the V1 is not "the MVP but prettier". It's when you pay back the shortcuts you took deliberately: replace manual processes with automation where the volume justifies it, consolidate the technical foundation, refine the interface on the journeys users actually take — you know them now, which was the whole point.
It's also the moment to decide what to drop. The MVP often reveals that some planned features interest nobody. Removing them from the plan is a win, not a failure.
Technically, I argue for continuity: if the MVP is built cleanly — however small — the V1 extends it instead of starting over. A throwaway MVP costs twice: once to build, once to replace. Small scope doesn't mean careless code.
Where to start
If you're carrying a product idea, the most profitable exercise costs nothing: write your core hypothesis in one sentence, then list the bare minimum needed to test it. If the list has more than ten items, it isn't short enough yet.
That's exactly the kind of framing I do at the start of a project, before writing a single line of code. Carrying an idea and not sure where to grab it? Let's talk — that's what the first conversation is for.