1What is an MVP?
An MVP is the smallest thing you can build to test your core hypothesis. It's not a crappy version of your product—it's a focused version.
The goal isn't to launch a product. The goal is to learn whether your assumption about the problem and solution is correct.
Reid Hoffman: 'If you're not embarrassed by the first version of your product, you've launched too late.'
2Defining Your Core Hypothesis
Before building anything, articulate what you're testing: 'We believe [target customer] has [problem] and will [take action] to solve it.'
Your MVP should test the riskiest assumption first. What's the thing that, if wrong, means the whole business fails?
Be specific. 'People will pay for this' is too vague. 'Freelance designers will pay $50/month for client management' is testable.
- Write down your assumptions before building
- Rank assumptions by risk and test the riskiest first
- Define what 'validated' looks like before you start
3MVP Approaches
Landing Page MVP: A page explaining your product with an email signup. Tests demand.
Wizard of Oz: Looks automated but you do it manually behind the scenes. Tests if people want the outcome.
Concierge MVP: Deliver the service manually to a few customers. Learn exactly what they need before automating.
Single-Feature MVP: Build one feature excellently instead of many features poorly.
4Building Lean
Use no-code tools where possible: Webflow, Bubble, Airtable, Zapier. Speed of learning beats perfection.
Set a time constraint. Most MVPs should take 2-4 weeks, not months.
Launch to a small group first. Get feedback, iterate, then expand.
- Every feature you add delays learning—cut ruthlessly
- If you can fake it with a human, do that first
- Track the one metric that proves your hypothesis