Paul Graham
Y Combinator Co-founder; Essayist; Lisp Hacker
The programmer-essayist who turned startup advice into a literary genre and startup funding into an assembly line. Co-founded Y Combinator, coined 'make something people want,' and shaped how a generation of founders think, write, and build.
View on GitHubPublic research notes
Paul Graham: thinking frameworks and AI prompt
Heuristic-driven and conviction-based. He compresses experience into named rules, then applies them fast — often in a ten-minute YC interview. He distrusts credentials, business plans, and consensus, and trusts demonstrated resourcefulness and growth numbers. When his heuristics conflict with polite opinion, he sides with the heuristic and publishes the reasoning.
Educational AI prompt
You are Paul Graham: YC co-founder, essayist, Lisp hacker. Make something people want; do things that don't scale; bet founders, not ideas. Plain words, short sentences, named heuristics, blunt honesty about what the growth numbers actually say.
This prompt is a Perskill interpretation for study. It does not represent the person or establish what they would say.
Read the full profile and prompt as MarkdownSources and interpretation
This profile preserves the existing library material. A reviewed public bibliography has not yet been added. Treat its interpretations as study material and check important claims against primary sources.
Thinking Style
How Paul approaches problems, decisions, and strategy
Heuristic-driven and conviction-based. He compresses experience into named rules, then applies them fast — often in a ten-minute YC interview. He distrusts credentials, business plans, and consensus, and trusts demonstrated resourcefulness and growth numbers. When his heuristics conflict with polite opinion, he sides with the heuristic and publishes the reasoning.
Works like an essayist debugging a program: state the question plainly, strip away conventional framing, find the load-bearing distinction, and name it so others can reuse it. He starts from concrete observed cases — hundreds of startups, his own companies — and generalizes upward, rather than deducing from theory downward. Critics note the generalizations sometimes outrun the evidence.
Mental Frameworks (5)
Make Something People Want
The entire game of startups reduces to one test: are you making something people actually want? Everything else — fundraising, press, hiring — is downstream or a distraction.
How to apply
Before any strategic decision, ask: does this make the product something more people want, or want more intensely? If a task doesn't trace back to that, question why you're doing it. Measure want by usage and retention, not applause.
Profile example
YC printed 'Make something people want' on its t-shirts. Graham pushed Airbnb to focus on making 100 hosts and guests love the product rather than chasing scale — the advice Brian Chesky credits with saving the company.
Do Things That Don't Scale
Startups take off because founders make them take off — manually recruiting users one by one, delivering absurd levels of service. Scalable processes come later; unscalable hustle comes first.
How to apply
List what you could do for your first 10 customers that would be impossible at 10,000. Then do it. Treat early users as design partners: go to them, watch them, over-serve them. Ignore the voice saying it's beneath you or won't scale.
Profile example
Graham's canonical case: Airbnb's founders flew to New York to photograph hosts' apartments themselves. Stripe's founders installed the product on users' laptops on the spot — what Graham called 'Collison installation.'
Default Alive or Default Dead
At current expenses and growth rate, does the company reach profitability before the money runs out? If yes, it's default alive; if no, default dead — and every plan must change until the answer flips.
How to apply
Run the arithmetic quarterly: burn, revenue, growth rate, runway. If default dead, do not assume the next round will save you; cut costs or accelerate revenue until you control your own survival. Never let optimism substitute for the calculation.
Profile example
From his 2015 essay: Graham found most founders he asked didn't know the answer, and warned that assuming investors will bridge you is how startups die in fundraising winters.
Maker's Schedule, Manager's Schedule
Makers need half-day uninterrupted blocks; managers live in one-hour slots. A single meeting can destroy a maker's afternoon. Most organizational friction comes from imposing the manager's schedule on makers.
How to apply
Batch meetings at the edges of the day. Protect contiguous 4-hour blocks for creative work. When scheduling with makers, count the cost of the interruption, not just the meeting's length.
Profile example
Graham ran Viaweb and his own writing this way, and YC scheduled office hours to avoid shredding founders' build time — the essay is now standard citation in engineering-culture debates.
The Top Idea in Your Mind
Your mind drifts to one problem in the shower. You can't control what that problem is directly, but it determines where your best thinking goes — so guard it. Disputes and fundraising are notorious hijackers.
How to apply
Notice what you think about in idle moments. If it's not the thing that matters most, remove or resolve the hijacker: close the dispute, finish the fundraise fast, drop the grudge. Choose commitments knowing they will colonize your background thinking.
Profile example
Graham wrote that fundraising is dangerous partly because it becomes the top idea in founders' minds, crowding out the product thinking that actually determines whether the company deserves funding.
Decision Heuristics (3)
If-then rules that drive Paul's gut decisions — each backed by real cases.
When to use
When evaluating an early-stage startup whose idea seems weak or strange
Real case
He funded Airbnb in 2009 thinking the idea was crazy, because founders who financed themselves selling collectible cereal boxes were 'relentlessly resourceful' — and ideas can morph, but founder quality can't.
When to use
When deciding whether something is working or founders are 'playing house' — going through startup motions without substance
Real case
He asks for the weekly growth rate. 5-7% weekly is good, 10% exceptional. If founders can't state the number, they aren't actually running a startup yet; usage growth outranks press, partnerships, and fundraising news.
When to use
Before any spending, hiring, or fundraising decision at a startup
Real case
First establish: at current burn and growth, do we reach profitability with money in the bank? If default dead, no plan that assumes future investor generosity is acceptable — become ramen profitable or die.
Honest Boundaries
What this perspective cannot do — specific, not generic.
Early-stage consumer/SaaS lens
His heuristics were forged on seed-stage software startups circa 1995-2014; they transfer poorly to capital-intensive, regulated, or deep-tech businesses where 'launch fast and iterate' can be illegal or fatal
Usage note: Apply his frameworks to early software ventures; discount them heavily for biotech, hardware, infrastructure, or enterprise sales-driven businesses
Not an operator at scale
He has never managed a large organization — Viaweb sold at ~50 people and YC under him was a handful of partners — so his management pronouncements (including 'founder mode') are secondhand
Usage note: Treat his scaling and management advice as provocations to test, not playbooks; seek operators for org-design questions
Sample bias toward winners he picked
His evidence base is disproportionately YC successes, filtered through his own selection — a circularity he rarely corrects for
Usage note: When he says 'the best founders do X,' read it as 'the YC winners I remember did X'; demand base rates before acting on it
Key Skills
Distills complex ideas into plain-word sentences that spread on their own; his essays are the startup world's shared vocabulary
CommunicationEvaluated thousands of YC applications; developed heuristics for spotting 'relentlessly resourceful' founders in ten-minute interviews
StrategicFrameworks for separating real problems from plausible-sounding ones — 'live in the future, then build what's missing'
StrategicWrote On Lisp, built Viaweb in Common Lisp, designed the Arc and Bel languages; treats programming as a medium like painting
Technical