What Is an MVP — and Why Your First Version Should Disappoint You a Little
MVP is one of the most misunderstood terms in building. Most people build too much. Here's what a real minimum viable product looks like and how to find yours.
MVP is one of the most abused terms in the building world.
Ask ten people what it means and half of them will describe a product that’s been built for six months. “It’s the minimum we need before we can launch.” Then they list fourteen features.
That’s not an MVP. That’s a product with a shorter name.
A real minimum viable product is the smallest thing that solves the core problem for the right person. Not the smallest thing that makes you comfortable launching. Not the smallest thing that covers every edge case. The smallest thing that actually works for the problem you wrote down in your PRD.
Here’s how to find it — and why getting this right is the difference between shipping in eight weeks and shipping never.
What MVP Actually Means
The original definition, from Eric Ries in The Lean Startup, is: the version of a product that allows you to collect the maximum amount of validated learning with the least amount of effort.
In practice for builders: the MVP is the version where every feature solves the core problem and nothing else is included.
The test for any feature: If I remove this, does the product still solve the core problem? If yes, it’s not in the MVP.
That test is harder to apply than it sounds because our brains treat the features we’ve imagined as necessary. We confuse “I want this to be in the product” with “the product requires this to work.” They are not the same thing.
Why Builders Overbuild
There are two reasons most first products are too big.
Fear. If users find a gap — something missing, something not handled — they might not come back. So we fill every gap we can imagine before anyone sees it. This feels responsible. It is actually delay disguised as diligence.
Excitement. We’re solving a problem we care about. Every idea that comes up during the build is a good idea. The feature list grows because we’re engaged, not because users need it. This is scope creep in its most innocent and damaging form.
Both lead to the same outcome: a product that takes three times as long to build, that nobody has validated, and that often misses the actual problem because the signal got buried under the features.
How to Find Your MVP
Step 1: Identify the core loop
Every product has a core loop — the single sequence of events that creates value. For SendJob, the core loop was: job created → customer gets a confirmation text. Everything else — the dispatch alert, the enroute notification, the payment link — was built on top of that. But that one loop was the thing that had to work.
Ask yourself: what is the one thing my product does that makes someone’s life better? That’s the loop. Build the loop first.
Step 2: Apply the MoSCoW method
Take everything on your feature list and categorize it:
- Must Have — the product doesn’t work without this
- Should Have — adds significant value but the core loop works without it
- Could Have — nice to have, low cost to add later
- Won’t Have (now) — explicitly out of scope for this version
Your MVP is the Must Have list, nothing more. Everything else goes on a future list. Not deleted — deferred.
Step 3: Write the “someone can use this to do X” sentence
Your MVP is complete when you can finish this sentence with one specific, honest statement:
“Someone can use this to [do the specific thing] without needing anything else from me.”
If the sentence requires caveats — “as long as they also…” or “as long as the edge case doesn’t…” — the MVP isn’t done yet, or you’re trying to scope it too wide.
For SendJob:
“A field service business can use this to automatically send a confirmation text to every customer the moment a job is created, without any manual step from the dispatcher.”
That’s a real MVP. Not glamorous. Completely shippable.
What Your MVP Is Not
It’s not broken. MVP doesn’t mean buggy or unfinished. It means focused, not sloppy. The things it does, it does well. It just doesn’t do everything.
It’s not embarrassing. If you’re cringing because it’s missing features, that’s scope anxiety, not quality judgment. The question isn’t “does this impress me?” — it’s “does this solve the problem?”
It’s not permanent. Everything in your Should Have and Could Have lists becomes version 1.1, 1.2, 2.0. Nothing is gone forever. Deferred is not deleted.
The Cost of Getting This Wrong
Every week you spend building features that aren’t in the core loop is a week of feedback you didn’t get from real users.
Real users will tell you things that make your feature list look completely different. Some features you were sure were essential will turn out to be irrelevant. Some things you hadn’t thought of will turn out to be urgent. You cannot learn any of this until someone is using the product.
The MVP gets you to that learning as fast as possible. Everything after that is iteration on real data instead of imagination.
The Honest Version
When I defined SendJob’s MVP, I left out a customer portal, a reporting dashboard, a technician mobile app, and a re-booking flow. Those were all real ideas that would add real value.
They’re also not in the product yet. Because the core loop — job in, notification out — needed to work first, and it didn’t need any of those to work.
That’s the discipline. Not cutting corners. Cutting scope.
This is Part 2 of a 4-part series on building and launching your first product. Part 1: Start With a PRD | Next: How Scope Creep Kills Products — and the Framework to Stop It
Subscribe below to get each part as it drops.