Founders love the MVP concept. It gives permission to ship. But shipped "MVPs" that should have been V1s cost more time and money than they save. Here's how to know which situation you're actually in.
What "MVP" actually means
The MVP concept was coined by Eric Ries: the smallest thing you can build that validates a core hypothesis. Not the crappiest version of the product you want to build.
The purpose of an MVP is learning, not shipping.
If you already know your users want the product (proven demand, existing customers, clear market), you don't need an MVP. You need a V1.
When to ship an MVP
Ship an MVP when:
- You're testing a new market
- You're testing a new business model
- You have limited capital and need to prove the idea before raising more
- Your addressable market is small enough that you can afford to burn goodwill with early users on a rough experience
MVPs are appropriate when the risk of building the wrong thing exceeds the risk of a poor first impression.
When to ship a V1
Ship a V1 when:
- Your market already exists and you know what customers want
- Your customers are enterprises or professionals who won't tolerate a rough experience
- You're competing against polished incumbents (a bad-looking MVP loses trust immediately)
- Your first impression is your ONLY impression (SaaS trials, marketplaces where users leave after one bad experience)
V1 is appropriate when the market has proven itself and you're differentiating on quality of execution.
The failure mode: MVP-shaped V1
The most common mistake we see: founders build what they call an MVP but ship it as their public product. Then they're surprised their conversion rate is terrible.
Symptoms:
- Signups but no activations
- Reviews that say "looks unfinished"
- High churn in the first week
- No word-of-mouth referrals
- Investors say "come back when it's more polished"
The fix isn't more features. It's more polish. Which is a V1 problem, not an MVP problem.
The other failure mode: over-scoped V1
The opposite mistake: spending 18 months building a "V1" that's really a V3, then discovering the market doesn't want it.
Symptoms:
- Missed timelines (usually by 6+ months)
- Scope has ballooned since kickoff
- Founder can't articulate what "done" looks like
- Runway pressure keeps pushing launch back
The fix is aggressive scope cutting. Ship the smallest version that solves ONE problem well, then iterate.
How to know which situation you're in
Ask yourself two questions:
- How much do I know about my users' needs?
- Very little → MVP - A lot → V1
- How high are the stakes of the first impression?
- Low (technical audience, enthusiasts, personal network) → MVP - High (enterprise buyers, mass-market consumers, replacing incumbents) → V1
If both answers point the same direction, you know your play. If they conflict, the higher-stakes answer usually wins.
Our recommendation
For most founders, our recommended path is:
- Weeks 1–4: Talk to 20 potential customers before writing any code. Understand the problem deeply.
- Weeks 5–12: Build a real V1 for a narrow segment. Not an MVP — a genuinely good product for one specific type of user.
- Post-launch: Iterate based on real usage data, not more customer interviews.
This approach avoids both failure modes. The upfront customer discovery replaces the "learn what to build" purpose of an MVP. The narrow scope keeps the V1 shippable.
What we help with
For founders building their first serious software product, we scope narrow V1s rather than sprawling MVPs. Our discovery week covers user interviews, scope definition, and go-to-market planning before we quote a build. If you'd like to see the process, book a consultation.