YC OS · Chapter 03

Write Code, Talk to Users

The two activities that actually move a pre-PMF startup forward. Everything else is a distraction dressed up as work.

After this lesson

Run a user conversation that produces a decision, not just a nice chat
Alternate between building and talking on a weekly rhythm
Recognize the questions that lead witnesses instead of learning something

The two things that count

Pre-product-market-fit, almost everything that matters reduces to two activities: write code and talk to users. Fundraising, conferences, corp-dev calls, and elaborate competitive decks are all easier and more comfortable than these two — which is exactly why they're tempting distractions.

A user conversation that works

Ask how they do the task today, in detail, before mentioning your product
Ask what's hardest about it, and why — dig past the first answer
Ask how often the problem happens and why it matters for their job
Ask what they've already tried, including spreadsheets and workarounds
Resist pitching until you've earned the right to ask whether they'd use this

Mistakes that ruin the signal

Leading the witness: describing your solution before hearing their problem
Asking hypotheticals ('would you pay for X') instead of about past behavior
Only talking to people who already like you — friends, warm fans
Treating polite interest as validation instead of digging for real urgency

A weekly rhythm

Book 3-5 user conversations for the week, no matter what else is happening
Ship the smallest code change the last conversation surfaced
Write down what changed in your understanding after each call
If a week produces zero conversations, treat it as a red flag, not a fluke

Case

Case: the founder who couldn't stop coding

A technical founder spent six weeks heads-down improving an engine nobody outside the company had touched yet, certain that quality would speak for itself at launch.

Takeaway: Code without users is theory. The fix wasn't more discipline — it was blocking three calls on the calendar before opening the editor each morning.

The user asked for a feature. Now what?

Users reliably have good problems and bad solutions — treat requests as clues, not specs.

Read the original

How to Talk to Users

Watch for the 'good problems, bad solutions' idea in the middle — the Gmail split-inbox and Airbnb phone-number requests show exactly why you shouldn't build what users literally ask for.

This chapter is a working summary. When the idea matters, read the source once — then come back and do the practice.