YC Startup School India was a good reminder of something simple: most founders spend time on the wrong things for the wrong reasons.
Most went in expecting tactical advice. What stuck instead were the basics. Not new ideas, but the kind you think you understand until you actually try to build with them.
These are the ten lessons that stayed with me. Some will sound obvious. That’s fine. Knowing something isn’t the same as operating as you know it.
1. Don’t scale before proof
Think about making a new dish for the first time. You’re not sure if it’ll be good. But instead of tasting it first, you make enough for thirty people.
That’s what most startups do.
The pressure to grow is real. Investors talk about it. Twitter talks about it. So founders scale before they’ve actually confirmed that the thing they built works. They hire before they have retention. They run ads before they have product-market fit. They build infrastructure for a million users when they have two hundred.
Build something small that clearly works. Not “kind of works.” Not “works if you explain it.” Clearly works; meaning someone picks it up, uses it, and something genuinely good happens for them.
That’s the starting point. Everything else comes after.
2. Start with the problem, not the company
There’s a difference between someone who says “I want to start a company” and someone who says “I keep seeing people struggle with this specific thing and it seems like nobody’s actually fixed it.”
The first person is looking for a nail to hit. The second already knows where it hurts.
When you start with the problem, your conversations with users change. You’re not asking, “do you like my idea?” You’re asking, “tell me about this thing that frustrates you.” One is fishing for approval. The other is actually learning something.
The deepest version of this: most companies don’t fail because they couldn’t build what they planned. They fail because they built the wrong thing with great precision.
Problem-first founders build the right thing. Company-first founders often just build the thing right.
3. Talk to users beyond the surface
Most user interviews are polite. Too polite to be useful.
You ask, “do you like the product?” They say yes because they don’t want to hurt your feelings. You ask, “would you use this?” They say probably. You walk away feeling validated. Nothing useful happened.
A doctor doesn’t walk in and say, “I’ve been working on this treatment, does it sound helpful?” They ask where it hurts, how long it’s been hurting, what you’ve already tried, and what made it worse.
The goal is diagnosis. Not reassurance.
Good user research means asking questions that can’t be answered politely.
- “Tell me about the last time you tried to solve this.”
- “What did you actually do?”
- “What happened?”
- “If this problem disappeared tomorrow, what would change for you?”
Also worth noting: what users say and what users do are two different things. Someone might tell you they’d pay ₹500 a month for your product. Their actual behavior might show they’ve never paid for a single app.
Interview them to understand their real self, not their aspirational self.
4. Understand what actually drives them
Nobody buys a drill because they want a drill. They want a hole. And they don’t want a hole; they want to hang a picture. And they don’t want to hang a picture; they want the room to feel like home.
The point: go further than the surface request.
At Startup School, this was framed around four things that drive most user decisions: speed, quality, selection, and price.
- Speed: I need this now. Every extra step is a cost I didn’t sign up for.
- Quality: I need to trust this completely. I’d rather pay more if it means I know it’s right.
- Selection: I need options. Fear of picking the wrong thing matters more than the effort of choosing.
- Price: I need this to be worth the money. That’s the deciding factor, full stop.
The mistake most products make is trying to win on all four. They end up okay at everything and excellent at nothing. Okay at everything means forgettable.
Know which driver matters most to your users. Then build for that one thing ruthlessly.
5. Optimise for love, not adoption
High adoption with low love looks fine on a slide deck. It means almost nothing.
Lots of downloads, few daily actives. Lots of signups, thin retention. Lots of users who wouldn’t notice if you shut down tomorrow.
The framing from today: 100 users who love your product matter more than 1000 who just use it.
Love has specific behavior attached to it. A user who loves your product comes back without being prompted. They tell people about it in conversations where you’re not even there. They get genuinely upset if they hear you’re shutting down, because losing it would actually change something for them.
That last one is the honest test. If a user heard you were closing and felt nothing, they didn’t love it. They just used it.
Love also compounds in a way adoption doesn’t. A user who loves your product brings in other users likely to love it too. A casual user doesn’t share it. Why would they? “I kind of use this thing” isn’t a story worth telling.
Build for love first. Adoption follows.
6. Design the most extreme Customer Experience first, then work backwards
Most product teams jump straight to constraints. What can we ship in two weeks? What fits this sprint? What’s technically possible right now?
These are real questions. But they’re the wrong starting point.
Before constraints, ask: if we had unlimited time, unlimited resources, and could do anything, what would the perfect experience look like for a user?
Not the realistic version. The extreme version.
The reason to start here: if you don’t know what perfect looks like, you can’t tell whether your constraints are making good tradeoffs or just making the product worse. You’re cutting things without knowing what you’re cutting toward.
An architect doesn’t start by asking what’s cheapest to build. They start by asking what this building should be. Then they work with constraints to get as close to that as possible. The vision is the compass.
Without a compass, all you have is a series of practical decisions that add up to something nobody quite intended.
Work backwards from the extreme experience. Know what you’re a step toward, not just what you’re shipping this week.
7. PMF is not something you calculate
There’s a version of product-market fit that lives in spreadsheets, retention rates, NPS scores, and DAU/MAU. These matter. But they’re late signals of something that’s already happening before they show up in a dashboard.
The actual experience of PMF is closer to a feeling.
You know a song is good not because you calculated it, but because you’re still humming it the next morning without trying to. You know because you played it for someone and watched their face change. You know, because when it comes on unexpectedly, something in you lifts.
PMF has that same quality. Users come back without being pushed. They get annoyed at the idea of using alternatives. They bring it up in conversations that have nothing to do with you.
The dangerous thing is the early spike. Every product gets this. You launch, your friends are excited, you see growth, you think you’ve found it. Then, month three arrives, and the retention curve tells a different story.
Real PMF shows up in behavior at week twelve, not week one. At month six, when novelty has worn off, and people are still there.
You can’t calculate your way to it. But you can stay close enough to recognize it when it actually shows up.
8. Stay close to users. Real conviction doesn’t come from dashboards
Data is a map. Maps are useful. But a map is not the place itself.
If you’ve ever followed GPS through a neighborhood and missed the road that was closed for a festival, you know what happens when the map and the reality disagree. The map said one thing. The street said something else.
Your dashboard is the map. Your users are the street.
What gets lost when you manage purely from data is texture. The dashboard tells you engagement dropped 12% in week six. It doesn’t tell you why. It doesn’t tell you that three of your power users switched jobs and no longer have the problem your product solves. It doesn’t tell you that one churned user was a day away from converting until a bug in your onboarding flow lost them.
That texture is where real conviction comes from.
Founders who stay close to users know things no dashboard can tell them.
- Which users are using the product in unexpected ways?
- Which complaints are the same complaint in different clothes?
- Which features do people love but never mention because they take them for granted?
Practically, staying close means watching real users use your actual product. It means calls where you’re not pitching or updating — just listening. It means reading your own feedback, not after it’s been summarized by a tool.
There’s a specific kind of conviction that comes from watching someone struggle with something you built, then figure it out, then feel relief. No chart produces that. And that conviction is what carries you through the weeks when the metrics are ambiguous, and you’re not sure if what you’re building is real.
9. AI is lowering the barrier to building, but not the bar for taste
The tools are better than they’ve ever been. A solo founder today can build in a weekend what used to take a team months. That’s real, and it matters.
But here’s what’s easy to miss: when everyone can build, building is no longer the advantage.
The question that used to be “can we build this?” is now “should we build this, and does it actually serve the person using it in a way that’s honest and careful and right?”
That’s not a technical question. It’s a judgment question.
Taste, in product terms, is feeling the difference between something that technically works and something that’s actually right. It’s knowing the onboarding flow functions, but it feels cold. It’s sensing that the feature you shipped does what users asked for, but doesn’t solve what they actually needed. It’s the discomfort when something goes out, and it’s fine, but it’s not quite true.
AI doesn’t do any of this for you. It can write code. It can’t develop cultural understanding. It can generate interfaces. It can’t generate empathy.
If you’re building for India, this matters even more.
The Indian user has been underestimated by products built elsewhere and dropped here. Building well for India means understanding the actual diversity of experience in this country; different languages, different devices, different bandwidth, different ways trust gets built.
None of that is in a prompt.
The bar for taste, depth, and care hasn’t dropped. If anything, it’s higher now because the excuse of “it’s hard to build” is gone. What you ship now directly reflects how carefully you thought about your user.
10. Aim for 10x or 100x. Avoid the middle
Here’s something nobody loves hearing: it’s almost as hard to build something moderately successful as it is to build something great. The difference in effort between “decent” and “exceptional” is smaller than most people think. But the outcome difference is enormous.
The middle is dangerous for a simple reason: it doesn’t stand for anything.
A product that’s 10% better than what exists asks users to change their behavior for a marginal gain. Changing behavior is costly. People only do it when the difference is obvious enough to justify the switch; the learning curve, the friction, the psychological cost of “I used to do it this way.”
A product that’s 10x better makes that easy. The user doesn’t have to convince themselves. The value is clear.
“Why would someone use this instead of what they already have?” is the most honest test of any product idea.
And the answer needs to be more than “it’s a bit cheaper” or “the UI is cleaner.” Those aren’t reasons to switch. There are reasons to bookmark the tab and forget about it.
10x isn’t a feature list. It’s a rethink of how a problem gets solved. WhatsApp didn’t build a slightly better SMS. It made long-distance communication essentially free. CRED turned paying a credit card bill one of the most forgettable acts in modern life into something that felt worth doing.
Each of those is a fundamental reframe. Not an increment.
For anyone building in India right now, the opportunities for 10x are genuinely large. Many real problems are still being solved with duct-taped solutions. But you have to be willing to go all the way, which means accepting that “fine” isn’t done, and “mostly working” isn’t good enough.
Build for the extremes. The middle is where things go to quietly not matter.
The simple takeaway
I left with this: good products are not accidental. They come from clarity, speed, and genuinely caring about the user.
None of those three things is as simple as they sound.
Clarity is knowing who you’re building for, what problem they actually have (not just what they say at first), and what a good outcome looks like for them. And it’s not a one-time thing. You keep coming back to it, especially when things get hard, and it’s tempting to switch to something easier.
Speed isn’t about moving fast and breaking things. It’s about learning faster than you’re comfortable with. Shipping things that will teach you something, not things that will impress someone. Being okay with being wrong quickly so you can correct and keep going.
And caring about users. Genuinely, specifically, over time. Not as a principle you write in a deck. As a daily habit, getting on calls, reading feedback yourself, sitting with the discomfort of watching someone struggle with something you built, and letting that pull you back to make it better.
Most products aren’t great because of resources, timing, or luck.
They’re not great because building something great requires a kind of sustained, unglamorous attention that’s easy to intend and hard to keep doing.
It means choosing the slower path, talking to real users when shipping would be faster, building for one person’s love when optimising for a thousand people’s mild interest would be easier, and staying close to the problem when managing from a distance would feel more professional.
That’s not a motivational line. That’s the actual job.
If something here matched something you’ve been thinking about in your own product or named a mistake you’ve already made, I’d genuinely like to hear about it. The most useful conversations I have start with someone saying “we got that wrong too”.
Leave a Reply