The Three Buckets
Paul Graham and Michael Seibel have said this repeatedly: the fastest way to fail is solving the wrong problem at the wrong scale.
Features, products, and companies exist on a spectrum. But the boundaries matter.
A feature is a tool solving 15 minutes of a user's day. SMS notifications. Expense splitting. API rate limiting. It's valuable. But it's part of someone else's product.
A product stands alone. Users open it to accomplish a complete job. Slack isn't a notification feature—it's a workplace operating system. Razorpay isn't a payment button—it's payments infrastructure for Indian businesses.
A company owns an entire category or unlocks a new one. Netflix didn't just stream videos; it rewrote entertainment. Jio didn't just offer connectivity; it created India's internet.
YC's Sizing Framework
YC uses a brutal test. Ask yourself:
1. Is the problem worth $100M+ in revenue annually?
If your TAM doesn't reach this, you're fighting for features. Togal (schedule-sharing platform) had nice TAM. But it capped at $50M. It's a feature for calendar apps. Contrast: Stripe's payment problem = infinite TAM (every business needs payments).
Indian founders often underestimate this. They see 500M internet users and assume massive markets. Wrong. You need to find the valuable subset.
2. Can 10% of your addressable market sustain a business?
This is the acid test. If you're building a CRM for veterinary clinics in India (5,000 clinics × $500/year = $2.5M), that's a feature. No amount of optimization reaches $100M.
But if you're building a CRM for SMEs (2M+ businesses × $2,000/year = $4B+), that's a product. If you add accounting, invoicing, and payments? That's a company.
3. Does the problem exist independent of your specific solution?
This filters out features masquerading as products. "We built a WhatsApp bot for food delivery" is a solution looking for a problem. The underlying job: "I want food delivered." That's solved by Swiggy. Your bot is a feature inside Swiggy's product.
Contrast: "Restaurants can't manage orders across platforms." This exists independently. An aggregation product solves it. This is a real product.
The Messy Middle Insight
Scott Belsky warns founders against validating small ideas thoroughly. Spending three months validating a feature is a waste. You'll find signal ("100 restaurants use our bot!") that feels like validation but isn't.
The real question: Will this idea still matter in three years? A feature solves today's workflow. A product anticipates tomorrow's. A company creates the future.
Indian founders often get stuck here. They validate features brilliantly (500 initial users) but can't scale because the underlying problem is too small.
Three Examples: India Edition
Razorpay's Evolution:
- Feature era: Payment buttons for Indian websites (2014). Solvable but tiny.
- Product era: Complete payment infrastructure for all of India (2016). $100M TAM.
- Company era: Financial services for SMEs (2022). Infinite TAM with Razorpay X, fintech stack.
They grew from feature → product → company by constantly expanding the problem they solved.
Cred's Question:
- Problem: Credit card debt.
- Feature or product? Initially looked like a feature (credit card payment app). But Kunal Shah saw it as a gateway to India's credit layer (a massive product). Still evolving.
Typical Mistake (Anonymous Bangalore Startup):
- Problem: "Doctors need appointment reminders."
- Solution: SMS reminder service.
- Reality: This is a feature. Hospitals use Zoho CRM. Clinics use HealthifyMe. Your SMS is a feature inside their product.
- Why it matters: VC sees $10M TAM (500K clinics × $200/year). They pass. You can't raise Series A.
How to Reframe
If you've validated a feature, you have two options:
Option 1: Expand the problem. Reminders → Full clinic management system → AI diagnostics assistant. Expand until you own a category.
Option 2: Find the right acquirer. Remind.md would be worth $30M to Zoho. You exit. Nothing wrong with that.
Most Indian founders default to Option 1 (founder ambition is high). But that requires a different TAM, different team, different funding.
The Non-Obvious Insight
YC rejects features faster than ideas with no traction. Because features are validatable. You get 500 users easily. But you'll never get 50,000. The curve flattens.
Companies have a different curve: slow then explosive. This is hard to see early. But size your problem correctly, and you'll know which curve you're on.
Your Checklist
Before you pitch:
- [ ] Does your TAM exceed $100M annually?
- [ ] Can 10% of that segment alone sustain a business?
- [ ] Does the problem exist without your solution?
- [ ] In three years, will solving this create a new category or strengthen one?
- [ ] Can you defend against 5 well-funded competitors?
If you answer "no" to three or more: You've found a feature. Nothing wrong with that. But know what you're building.
Actionable Takeaway
Spend one week on TAM sizing before building. Not three months validating a feature.
Write down: "In 2027, the market for _____ will be worth $_____, and we'll own _____." If you can't complete this sentence with conviction, you're solving a feature.
Indian founders have a structural advantage: you see problems at scale. Use it. But distinguish between problems you can own and problems you can only contribute to.