What Most Founders Get Wrong About MVPs
You've heard "build an MVP." You probably think it means shipping a lean product with core features. Wrong.
An MVP is not a product. It's a hypothesis-testing machine. Specifically: a tool to answer your riskiest assumption in the shortest time possible.
Paul Graham calls this "doing things that don't scale." Michael Seibel at YC is blunter: "Your MVP should be embarrassing to show investors. If it isn't, you waited too long."
Here's the gap: founders optimize for a polished launch. Investors and YC optimize for learning velocity.
The Cost of Overthinking
A Bangalore-based fintech founder spent 5 months building a "minimal" loan eligibility platform. They shipped with Aadhaar verification, KYC automation, and a sleek dashboard.
First week of real users: nobody understood why they needed it instead of their bank.
They'd built 80% of the solution. They'd learned 0% about whether the problem mattered.
Compare this to a founder in the same space who spent 2 weeks building a Google Form + WhatsApp chatbot. In week 1, she got 50 qualified inquiries. In week 3, she had her first paying customer.
The form taught her more in 3 weeks than the polished app did in 3 months.
What To Cut (And Why)
Build your MVP by asking: "What can I strip away and still answer my core question?"
Core question example: "Do SMEs care about automated invoice tracking?"
Cut these:
- Beautiful UI. Use forms, spreadsheets, manual processes.
- Scalability. Serve 10 customers by hand if needed.
- Integrations. Do manual data entry first.
- Mobile apps. Desktop web or a Telegram bot works.
- Fancy analytics. Talk to users directly instead.
Keep these:
- The actual user workflow. How they use the thing.
- Friction points. Where do they get stuck?
- Willingness to pay. Does this problem hurt enough?
- Competitive alternatives. Why wouldn't they use X instead?
Scott Belsky's framework from The Messy Middle: "You need just enough structure to move, not enough structure to impress."
The Measurement Trap
Most founders measure wrong. They track:
- Downloads
- Signups
- Daily active users
- Time spent in app
These are vanity metrics for an MVP. They feel good but teach nothing.
Measure this instead:
- How many users repeat the core action in week 2? (Retention of engaged users)
- What's their strongest objection to paying?
- Do they refer a friend unprompted?
- What feature request did everyone make?
- At what price point does demand collapse?
Example: A B2B SaaS founder's MVP had 200 signups. Only 3 completed the main workflow. Most quit at the second step. That one metric—drop-off location—taught them more than the signup count ever could.
They fixed that one step. Next launch: 40% completed. That's learning.
The 10 User Principle
YC companies often find product-market fit with fewer than 100 active users. How?
They obsess over 10 power users. Not 1,000 casual ones.
Power users tell you:
- What they'd pay for
- What they'd build themselves if you didn't exist
- What they'd quit their job to use
Casual users tell you nothing.
Get 10 people who have your problem acutely. Put your MVP in their hands. Watch them use it. Listen to their unsolicited feedback.
That's your curriculum for the next 2-week cycle.
The Build-Measure-Learn Loop
Michael Seibel's advice: 2-week sprints.
Week 1-2: Build the MVP.
Week 3: Get 10 users, watch them, record feedback.
Week 4: Build the next thing based on what you learned.
Repeat.
This is relentless. It's also how YC companies find product-market fit in 8-12 weeks instead of 12-24 months.
Indian founders often lose pace here. Cultural factors: perfectionism, risk aversion, family expectations. You build once, launch with pomp, then optimize.
Faster founders in India (Khatabook, Cashfree, Postman) did the opposite. Launch, iterate, launch, iterate.
The Non-Obvious Insight
Your MVP will feel incomplete to you. That's the signal you're doing it right.
If you're not uncomfortable shipping it, you overbuilt. Founders underestimate how much users will forgive in exchange for solving their actual problem.
Example: Early Slack. Launched without file search. Launched without custom emojis. Users didn't care. They cared about not losing messages in Skype.
What To Do Now
1. Write your riskiest assumption in one sentence. ("SMEs care about invoice automation")
2. Define the single metric that proves/disproves it. ("10% of power users are willing to pay Rs 500/month")
3. Design an MVP that answers only that metric. Everything else is waste.
4. Ship in 2 weeks. Not perfect. Fast.
5. Get 10 power users. Don't recruit casuals.
6. Build the next cycle based on what you learned.
Your MVP is not your product. It's your fastest route to knowing whether your idea has legs.