YC Startup School India was a reminder of something simple. Most founders spend time on the wrong things for the wrong reasons.
People expect tactics. What actually sticks are the basics. Not new ideas, just the ones that only make sense once you try to build.
These are the lessons that stayed with me.
1. Don’t scale before proof
Think of cooking something new and making it for thirty people without tasting it first.
That’s what most startups do.
They hire early. Run ads early. Build infra early. But the product hasn’t really worked yet.
Start small. Build something that clearly works. Not “kind of works.” Something that someone uses and gets real value from.
Everything else comes after.
2. Start with the problem, not the company
There’s a difference between:
“I want to start a company”
and
“I keep seeing this problem and nobody has solved it well.”
The first looks for ideas. The second already has one.
If you start with the problem, your conversations change. You stop asking for validation and start learning.
Most companies don’t fail because they couldn’t build. They fail because they built the wrong thing well.
3. Talk to users beyond the surface
Most user interviews are too polite to be useful.
You ask, “would you use this?” They say yes. Nothing useful happens.
Instead, ask about real behavior:
- Tell me about the last time you faced this
- What did you actually do
- What happened
The goal is diagnosis, not validation.
Also, what users say and what they do are different.
Interview them to understand their real self, not their aspirational self.
4. Understand what actually drives them
People don’t buy products. They buy outcomes.
At a basic level, most decisions come down to:
- Speed
- Quality
- Selection
- Price
Most products try to win on all four and end up average.
Pick one. Go deep on it.
5. Optimise for love, not adoption
High adoption with low love doesn’t mean much.
Lots of users, low retention. Lots of installs, no habit.
100 people who love your product matter more than 1000 who just use it.
Love shows up in behavior. They come back. They tell others. They care if you shut down.
Build for that first.
6. Design the extreme experience first
Most teams start with constraints.
Instead, start with the ideal.
If you had no limits, what would the perfect experience look like?
Then work backwards.
If you don’t know what “great” looks like, you can’t make good trade-offs.
7. PMF is not a number
You can’t fully measure product-market fit in dashboards.
It shows up in behavior.
People come back without reminders. They prefer your product. They talk about it.
It’s more like a feeling than a metric.
And it shows up later than you expect. Not week one. More like month three or six.
8. Stay close to users
Data is useful. But it’s not enough.
Dashboards tell you what happened. Not why.
You only get that by talking to users.
Watching them use your product. Hearing their frustrations. Seeing what actually matters to them.
That’s where real conviction comes from.
9. AI lowers the barrier, not the bar
It’s easier than ever to build.
But that doesn’t mean what you build is good.
The advantage is no longer building. It’s judgment.
Taste matters more now. Knowing what to build, what to ignore, and what actually feels right.
AI can write code. It can’t understand people.
10. Aim for 10x, not 10%
A slightly better product is not enough.
Users don’t change behavior for small gains.
10x makes the decision obvious.
The middle is dangerous. It doesn’t stand for anything.
Ask yourself:
Why would someone switch to this?
If the answer is weak, the product is weak.
The simple takeaway
Good products come from three things:
Clarity.
Speed.
And actually caring about users.
Clarity is knowing who you're building for and what they really need.
Speed is learning fast, not just shipping fast.
And caring means staying close to the problem, even when it’s uncomfortable.
Most people know this.
Very few actually operate this way.
If you liked this, check out these related posts:
- What Happens When AI Writes Most of the Code? — How AI is changing what developers do
- Building in Public: Why I'm Starting This Blog — On sharing knowledge openly
- What I Learned as a Developer Advocate — Lessons from the DevRel world
Thanks for reading.