The editorial argues PG presents a post-hoc decomposition of billion-dollar outcomes as if it were an actionable model. None of the three terms — problem size, solution quality, residual equity — are levers a founder can set on day one; problem size in particular is discovered through iteration (Stripe, Airbnb), not chosen from a TAM list.
Captured in the editorial as 'this is true and useless' — the decomposition is arithmetically correct but offers no guidance on which lever to pull before the outcome is known. The framework explains variance after the fact rather than informing pre-action choices.
Graham argues a billion-dollar outcome multiplicatively decomposes into problem size, solution quality, and residual founder equity — zeroing any term zeroes the product, halving any term halves the result. He presents this arithmetic as guidance founders can use to evaluate their trajectory and avoid catastrophic dilution or trivial problems.
The 515-point score and founder-heavy nodding in the thread signal a substantial audience finds the framework clarifying. They treat the multiplicative structure as a memorable heuristic for prioritizing problem ambition and equity preservation.
A long tail of commenters in the thread dispute whether residual equity actually behaves as a simple multiplier — they point to liquidation preferences, secondary sales, refresh grants, and option pool expansions that complicate the clean arithmetic PG presents. The argument is that the equity term is path-dependent in ways the essay glosses over.
Argues that founders who try to pick large problems on purpose end up in crowded, capital-intensive categories — autonomous trucking, consumer social, generalist AI agents — precisely because those problems look defensible on paper. Real billion-dollar outcomes emerge from small wedges (Stripe's better Authorize.Net, Airbnb's conference air mattresses) where the market reorganizes around the solution.
Paul Graham published *How to Earn a Billion Dollars* and it hit 515 on Hacker News. The structural move in the essay is unusual for him: he does the arithmetic. A billion-dollar outcome, he argues, decomposes into three multiplicative terms — the size of the problem you pick, the quality of your solution, and the residual equity you still hold when the outcome lands. Zero out any one and the product is zero. Halve any one and you halve the result.
The HN thread is the predictable mix: founders nodding, ex-founders rolling their eyes, and a long tail of commenters arguing about whether dilution math really works the way PG implies. The top comment, paraphrased, is the one worth pulling out: *this is true and useless*. Which is the part of the essay worth writing about, because PG is doing something here he almost never gets called out for — presenting a descriptive decomposition of outcomes as if it were a predictive model for decisions.
The distinction matters. A descriptive framework explains the variance you see in a sample after the sample is collected. A predictive framework tells you, before you act, which lever to pull. PG's three terms are descriptive. None of them is a thing a founder sets on day one.
Consider each term as a would-be control variable.
Problem size is not chosen — it's discovered. Stripe didn't pick "payments for the internet" off a list of trillion-dollar markets; they wrote a few API calls that were less painful than Authorize.Net and the market revealed its size to them over a decade. Airbnb's TAM at founding was "air mattresses at conferences." The size of the problem you end up solving is a function of how the world reorganizes around your solution, which you cannot price in advance. Founders who try to pick big problems on purpose end up in crowded, defensible-on-paper categories that eat capital — autonomous trucking, consumer social, generalist AI agents — precisely because the size is legible to everyone else too.
Solution quality is even worse as a control. You don't know if your solution is good until users tell you, and users tell you over a time horizon that is months at the earliest and usually years. The dial labeled "solution quality" on the founder's dashboard is actually a delayed, noisy readout from the market. Twiddling it harder doesn't make it move faster. The practitioners reading this know the feeling: you can ship for a year against the wrong abstraction and not know it was wrong until the metric tilts.
Residual equity is the term PG seems most confident about, and it's the one with the strongest illusion of control. The essay's implicit model is: raise less, dilute less, keep more. But the founders who kept the most equity by the exit were largely the ones who didn't need to raise — and not needing to raise is itself a consequence of the first two terms going right. Sam Walton kept his equity because Walmart's unit economics let it self-fund. Notch kept his equity because Minecraft was a sellable product the day he shipped it. Trying to optimize residual equity from year one — by raising late, raising small, or bootstrapping a venture-shaped business — is the most common way to end up with 100% of nothing.
The sharper way to read PG's framework is as a post-mortem template, not a planning tool. After the fact, every billion-dollar outcome decomposes into those three terms cleanly. Before the fact, the three terms are entangled, lagged, and largely outside the founder's control. This is the same shape as Tolstoy's happy-families line, or Anna Karenina principle as ML people now use it: there is one way to succeed and many ways to fail, but knowing the success path doesn't constitute a method for walking it.
The HN thread underlines this in passing. One commenter points out that the residual-equity term is doing most of the work in PG's examples — the difference between the founders he cites and the also-rans is almost never problem size or solution quality, both of which were comparable at the time, but how much of the cap table the founder controlled at exit. Which is, again, a descriptive observation about who PG already considers a success.
If you're a senior engineer reading this with founder ambitions, the actionable read is the inverse of the essay. Stop trying to score high on PG's three terms ex ante. Use them as a failure-mode checklist ex post. When a startup you know is struggling, ask which term went to zero: was the problem too small to support a billion-dollar outcome at any solution quality (most B2B SaaS niches), was the solution non-differentiated against incumbents (most AI wrappers), or did the cap table get crushed by a desperate late round (most overhyped consumer apps)? You'll find the diagnosis is almost always one of those three, and almost never "the founder didn't try hard enough."
For day-to-day technical decisions the framework is more useful inverted. Pick problems where the size could surprise you on the upside — narrow wedges with adjacent expansion paths, not large defined markets. Optimize solution quality on the only axis you can actually measure in week one: how fast a real user gets to a real result. And treat residual equity as a constraint, not a goal: take the smallest raise that lets you survive to the next signal, and only when you have a signal to chase.
None of this is novel. What's novel is naming why PG's essay reads as advice and functions as autopsy. The essay is not wrong. It is correctly identifying the variables that show up in the post-hoc decomposition. It's just that none of those variables are accessible to a founder at decision time, which means the essay's title — *How to Earn a Billion Dollars* — promises a function the body cannot deliver.
The broader pattern worth tracking: as the LLM-era founder population grows and capital remains concentrated, descriptive frameworks like PG's will get reinterpreted as predictive ones more often, because the supply of people who want a recipe vastly exceeds the supply of legitimate recipes. The essays that age best from this era will be the ones that resist that compression — that say, plainly, *here is what the survivors had in common, and here is why that does not tell you what to do next*. PG's essay gets most of the way there. The last step is admitting that the arithmetic only works backwards.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.