Pranav Lende

@gtalumni | sf
Welcome to my brain dump where I share random things I notice as I chase PMF

[Pranav Lende @pranavinno]

Interested in AI, Startups, Networking?

Over the next 30 days, I'll be writing 30 Atomic Essays.

Follow my Social Blog on @typeshare_co: https://t.co/2HtGcvYjF2

[Pranav Lende @pranavinno]

the guys on the new season of Love Is Blind are so chopped and holy they have hella ego where tf did that come from

[Pranav Lende @pranavinno]

@ycombinator @aidan__pratt this is so awesome congrats on the launch @aidan_pratt

[Pranav Lende @pranavinno]

AI doesn’t have a model problem. It has a context problem.

After talking with senior engineers (L5+) the pattern was painfully consistent:

Teams don’t lose code.

They lose the why behind the code.

The real knowledge lives outside the IDE:
•decisions buried in docs
•architecture scattered across browser tabs
•diagrams sitting in Preview
•“tribal knowledge” trapped in one person’s head

And that creates a silent killer every engineer recognized instantly:

knowledge rot.

Even teams 10x’ing code output with AI are still terrified of one thing:
when the one engineer who holds the mental model leaves, the company rebuilds it from scratch.

That’s the current version of my YC idea.

Aginno is a central context engine for engineering teams.

The wedge is an OS-level desktop overlay that captures “reasoning-in-flight” as engineers work.

The goal is bigger:

Turn fragmented intent across the IDE, browser, and terminal into a persistent, project-scoped “brain” that both:
•junior developers can query to understand legacy systems
•AI coding agents can query to act reliably inside a real project

Not a better editor.

A better memory.

Most tools today assume “the project” lives in the IDE.

But the most important context rarely does.

That’s why IDE copilots feel powerful in demos, then fall apart in real teams.

They generate code.

They don’t preserve understanding.

Where we are

I have a functional OS-level MVP (Electron/React) with persistent memory across projects, plus MCP tool actions.

It’s currently in a high-fidelity alpha with design partners, with early users already active (and a small paid signal).

What’s the most painful “context loss” moment you’ve had on a team, onboarding, debugging, or inheriting a codebase?

[Pranav Lende @pranavinno]

Most people don’t fail at building because they’re untalented.

They fail because they can’t survive the “invisible phase.”

Here’s what the first 30 days of building actually look like:

1. No feedback
2. No visible progress
3. No external validation

And here’s the mistake:

They interpret silence as a signal to quit.

But in reality, silence is the filter.

Every meaningful skill follows the same pattern:

Reps --> Identity --> Recognition --> Results

Not the other way around.

If you’re in a quiet phase right now, don’t pivot.

Track reps, not applause.

That’s how you earn being undeniable.

[Pranav Lende @pranavinno]

Most “bad writing” isn’t bad writing.

It’s a bad trade.

Readers pay with attention, time, and mental energy, and your first line never tells them what they get back.

Fix it with one habit:

Topic + Audience + Outcome in the first sentence.

Example:
“User interviews for first-time founders, so you stop building the wrong thing with high confidence.”
Clear trade = fewer scrolls.

What are you writing right now, and who is it for?

[Pranav Lende @pranavinno]

there are a ton of podcasts on startups, product, PMF, etc.

and ngl, most of them blur together after a while.

but the one i keep coming back to is lenny’s podcast (lenny rachitsky).

if you’re new to user interviews and finding pmf, i’d honestly block 1 hour a week for it. here’s why:

reason #1: it upgrades your questions
most founders don’t fail because they can’t build.
they fail because they ask the wrong questions, then build the wrong thing with confidence.

reason #2: you get real reps without paying for them
every guest has scar tissue.
you learn what actually happened, not the polished “and then we found pmf” story.

reason #3: it’s tactical, not just vibes
frameworks, examples, scripts, decision-making.
stuff you can try the same day in your next interview.

if you’re in the “i have an idea but idk what users actually want” phase, this is the best weekly input i’ve found.

what’s the one podcast you always come back to?

[Mark Worrall @infinitehumanai]

AI doesn't shrink the software problem, it expands it. More capability means more ambition means more novel problems. It's demand-side, not supply-side.

Claiming we can "solve software" misunderstands what software is. Software encodes human knowledge and intent into systems that interact with reality.

You can't "solve" it anymore than you can write the last encyclopedia entry: every answer generates new questions, and each generation of questions lives in a higher-dimensional space than the last.

AI will make us radically faster at writing software. But it will also explode the frontier of what's worth building.

The problem space grows faster than the solution space. This isn't a bug - it's epistemology.

[Pranav Lende @pranavinno]

I thought the hardest part of being a software engineer was writing good code.
I was wrong.

The real bottleneck is understanding what the system actually does.

At large companies, no one ever fully “onboards.”
You slowly accumulate context by fixing bugs, asking teammates, and memorizing quirks that aren’t written down anywhere.

Microservices were supposed to reduce coordination.
Instead, they often hide complexity behind unclear interfaces.

APIs exist, but no one knows:
- what they actually do
- which parameters matter
- what the SLA is
- or who owns them when things break

When incidents happen, tickets bounce between teams not because people are lazy, but because the system itself is illegible.

Even with AI coding agents, engineers still have to babysit them.
Not because the models are dumb, but because the context they need is scattered across repos, infra, and tribal knowledge.

Speed isn’t the problem.
Talent isn’t the problem.
Legibility is.

If you can’t see how a system works, you can’t safely change it.

And no amount of faster code generation fixes that.

[Pranav Lende @pranavinno]

An Easy Framework For Learning How To Run User Interviews

I have been practicing user interviews for the past few weeks.

Along the way, I have done all sorts of things to try to get better:
- Read The Mom Test
- Watched founder interviews and breakdowns
- Asked other builders how they run their calls
- Ran interviews that felt good, but led to bad decisions

And all of these things helped me a ton.

But if I had to start all over again (as a beginner), this is the simple framework I wish I had for learning how to run user interviews:

Step 1: Remove the pitch
If users think you are selling, they stop being honest and start being polite.

Step 2: Ask about real past behavior
People are bad at predicting what they would do, but very good at explaining what they already did.

Step 3: End with what they will do next
Urgency and pain show up in actions, not opinions.

When you’re first starting out, this is all that matters.

[Pranav Lende @pranavinno]

The Fastest Way to Know If Your Startup Idea Is Bad (Before You Build Anything)

Most bad startup ideas don’t fail in code.
They fail in conversations.

Here’s the simple test I’m using right now:

Talk to 10 people who already feel the problem.

Not hypothetically.
Not “would you use this?”
But people who solved it last week.

In those calls, listen for 3 signals:

1) They complain without being prompted
2) They describe workarounds in detail
3) They’ve already spent time or money trying to fix it

If you don’t hear those things, the idea isn’t “early.”

It’s imaginary.

This saves weeks of building.
It sharpens your MVP instantly.
And it replaces guessing with evidence.

Code is cheap.
Clarity is expensive.

What’s the last problem you personally paid to solve?

[Pranav Lende @pranavinno]

User interviews don’t just find startup ideas.

They save you weeks of coding.
They sharpen your copy.
They kill bad features early.
They give you confidence to cut scope.
They turn “I think” into “I know.”

Most founders treat interviews like validation.
They’re not.

They’re a compression algorithm for clarity.

If your MVP feels bloated, vague, or hard to explain,
you’re not under-building.

You’re under-listening.

What surprised you most in your last interview?

[Pranav Lende @pranavinno]

User Interviews for Dev-Tool Founders, So You Can Find Real Pain in 7 Days

Most founders don’t fail because they can’t build.
They fail because they build the wrong thing really well.

After running interviews, here’s what I've realized actually works:

1) Don���t ask “Would you use this?”
Ask “What did you struggle with last time you did this?”

2) Pain lives in workarounds.
Spreadsheets, scripts, Slack messages, duct tape = gold.

3) Frequency beats intensity.
A small annoyance that happens daily > a huge pain that happens yearly.

4) Write down exact quotes.
Your landing page copy is already in their words.

5) Stop when patterns repeat.
The 6th interview rarely adds insight, it adds confidence.

Your job isn’t to convince users.
It’s to listen until the problem becomes obvious.

What workflow are you interviewing for this week?

[Pranav Lende @pranavinno]

User interviews for first-time founders: 7 lessons I learned the hard way

I thought user interviews were about validating ideas.

They’re not.

They’re about deleting bad assumptions as fast as possible.

After doing dozens of interviews, here are the lessons that actually mattered.

1) Your users won’t describe the problem the way you do
They don’t say “workflow inefficiency” or “context switching.”
They say things like, “This is annoying” or “I hate this part.”
Your job is to translate emotion into product.

2) Hypotheticals are useless
“Would you use this?” gets you polite lies.
“What did you do the last time this happened?” gets you truth.

3) The real pain shows up in the pauses
When someone stops mid-sentence or says “uh…”, that’s signal.
That’s where the problem actually lives.

4) Everyone says they want features. They really want relief
No one wants dashboards.
They want fewer steps, fewer decisions, fewer tabs open at once.

5) The best interviews feel boring
If the conversation sounds dramatic, you’re probably leading it.
Good interviews feel slow, literal, and oddly unexciting.

6) Patterns matter more than intensity
One angry user doesn’t mean much.
Five calm users describing the same workaround means everything.

7) The interview isn’t done when the call ends
The insight comes after, when you rewrite everything in your own words.
If you can’t explain the pain simply, you didn’t understand it yet.

User interviews don’t give you startup ideas.

They take ideas away until only the real one is left.

If you’re a first-time founder doing interviews right now, what’s the hardest part for you to hear without getting defensive?

[Pranav Lende @pranavinno]

The One Habit All Successful Builders Share

Most successful people share a handful of things in common.

They’re disciplined with their time.
They know how to stay focused on one goal at a time.
They surround themselves with mentors and peers who challenge them.
They’ve mastered at least one valuable skill.

But in the world of builders and startup founders specifically, I’ve noticed one habit that shows up again and again.

They obsess over the constraint.

Not motivation.
Not hustle.
Not vibes.

Constraints.

[Pranav Lende @pranavinno]

Eric Ries didn’t start The Lean Startup by telling founders to build companies.

He told them to run experiments.

Small.
Cheap.
Fast.
The goal was never the product.
The goal was validated learning.

Most creators ignore this and do the opposite.

They start with a course, a newsletter, a startup idea, or a personal brand strategy before they have proof anyone wants it.

That’s not ambition.

That’s risk disguised as confidence.

Ryan Holiday became the Stoicism guy the same way.

Not by declaring a niche.
Not by launching a brand.
Not by building a course.

He wrote one post explaining Meditations.

People cared.
So he wrote another.
Then another.

The niche revealed itself.

Writing works the same way startups do.

A tweet is an MVP.
An atomic essay is a validated feature.
A guide is a scaled version of demand that already exists.

Anything bigger than that without data is just guessing louder.

The mistake most people make is trying to decide their niche upfront.

Lean thinking flips this.

You ship.
You observe.
You double down on what works.
Your niche is not a choice.
It’s an outcome.

If you want to build something real, ask the lean question.

What’s the smallest thing I can publish to test this idea?

Start there.

Let the market earn the right for you to go bigger.

[Pranav Lende @pranavinno]

Why better engineers often ship worse AI startups

Paul Graham has said that startups fail when founders build what’s impressive instead of what’s needed.

AI made this problem worse.

1) Engineers optimize for correctness. They chase better models, cleaner abstractions, and edge cases, but users just want the problem gone.

2) AI lowers build cost but not decision cost. You can ship features faster than ever, but deciding what not to build is still the hard part.

3) Early AI products don’t fail technically. They fail because no one cares enough to return. That’s not a model issue. It’s a relevance issue.

4) The best AI MVPs feel unfinished by design. They test one painful job, not ten cool capabilities. Speed creates signal. Polish hides it.

The paradox:
The more capable you are technically, the easier it is to avoid the market.

The fix isn’t dumber engineering. It’s tighter feedback loops.

Ship something narrow.
Let users tell you what matters.
Then earn the right to optimize.

That’s how real AI companies get built.

[Pranav Lende @pranavinno]

Day 5: This is the best book I’ve read on talking to users

There are a lot of books about startups.

But the best book I’ve found on customer discovery is The Mom Test by Rob Fitzpatrick.

For a few reasons:
1) It shows why “Do you like this idea?” is a trap (people lie to be nice).
2) It teaches how to ask questions that uncover real pain, not compliments.
3) It gives simple examples of good vs bad questions you can copy.
4) It pushes you toward evidence, commitments, timelines, budgets.
5) It’s short, practical, and re-readable before every user interview.

If you’re building anything and you’re not sure what users actually want, start here.

If you���ve read it, do you agree? What’s your #1 book for early founders?

[Pranav Lende @pranavinno]

Clarity isn’t found before action.
It’s created because of action.

Build first.
Let reality decide.

[Pranav Lende @pranavinno]

A mental model every builder should know:
one-way vs two-way door decisions

It’s how Jeff Bezos avoided analysis paralysis at Amazon:

[Pranav Lende @pranavinno]

If you’re stuck choosing between ideas, ask this:

“Is this a one-way door or a two-way door?”

If it’s two-way, stop thinking.
Ship it.