There is a half-life on growth advice, and it is short. The thread about the cold-email template that tripled replies, the post about the onboarding tweak that doubled activation, the framework named after a fruit: most of it is true for one company at one moment and stale by the time it reaches you. We noticed, over a few years of running experiments off that kind of content, that the things which kept working did not come from the feed at all. They came from a handful of books, most of them older than the tactics, and the books kept being right long after the tactics expired. Lenny Rachitsky, whose newsletter is itself a firehose of current tactics, makes the same admission in his list of essential books for product builders: “how many blog posts or tweets have had anywhere near the lasting impact on your life as a great book?”
The interesting part is not that books beat tweets. The interesting part is that the three books that changed how we grow products all argue, in different vocabularies, for the same uncomfortable discipline.
Why we stopped chasing frameworks
The chasing has a cost that is easy to miss while you are doing it. Every new framework is a context-switch, a re-tooling, a week spent learning someone else’s vocabulary for a problem you already had. And because the tactic is tuned to its author’s company, importing it usually means importing assumptions that do not hold for yours. Lenny cites Marc Andreessen’s rule on this directly: you should mostly read books that are over ten years old, “because those are the ones that have stood the test of time.” The filter is brutal and useful. A tactic that survived a decade of changing channels, platforms, and ad markets is describing something about people, not about a particular growth surface.
So we did the unfashionable thing and went backward. The books below are not new. Two of the three predate most of the growth playbooks that cite them, and the oldest idea in them is the one we lean on most.
The Mom Test: stop contaminating the evidence
The first book that rewired us is the shortest. The Mom Test by Rob Fitzpatrick, published in 2013, is a handbook for talking to customers without fooling yourself. Fitzpatrick, a YCombinator alum from the summer 2007 batch, wrote it out of frustration at being a programmer forced into customer conversations, and its core claim, per a detailed summary on Medium, is this: “you aren’t allowed to tell them what their problem is, and in return, they aren’t allowed to tell you what to build. They own the problem, you own the solution.”
The three rules are deceptively plain, per the same summary: talk about their life instead of your idea, ask about specifics in the past instead of opinions about the future, and talk less and listen more. The reason it matters for growth specifically is that almost every growth experiment starts from a belief about why users do something, and that belief is usually built on contaminated evidence. “Would you use this?” gets a yes that means nothing. “Walk me through the last time you faced this problem” gets a story you can act on. Fitzpatrick’s rule of thumb, per the Medium summary, is that “you should be terrified of at least one of the questions you’re asking in every conversation.” If none of your questions risk a no, you are running a comfort exercise, not research. The book taught us that most failed growth bets are not execution failures. They are failures of evidence that felt like fact.
Escaping the Build Trap: count outcomes, not features
The second book names the trap we kept falling into. Escaping the Build Trap by Melissa Perri, published by O’Reilly in 2018, is about the gap between shipping and creating value. Perri’s definition of the trap, per a detailed briefing on it, is sharp: “The build trap is a terrifying place for companies because it distracts them. Everyone is so focused on shipping more software that they lose sight of what is important: producing value for customers, hitting business goals, and innovating against competitors.”
The mechanism, per a chapter-by-chapter summary, is incentives: companies measure value by “the sheer volume of things they build,” celebrate the number of features shipped even when those features miss their goals, and reward “quantity of code, designs, or backlog items rather than the value delivered.” For a growth team this is the deadliest pattern of all, because growth work is so easy to measure by activity. Tests run. Experiments launched. Variants shipped. None of which is the same as users who stuck around. Perri’s frame, output versus outcome, gave us language for the thing we kept doing wrong: confusing a busy roadmap for a working one.
Most failed growth bets are not execution failures. They are failures of evidence that felt like fact.
Working Backwards: write the result before you build
The third is Working Backwards by Colin Bryar and Bill Carr, two long-tenured Amazon executives, which Lenny includes in his strategy shortlist. Its best-known practice is Amazon’s habit of starting a new product by writing the press release and the customer FAQ first, before any code, and refusing to build until that document describes something a customer would actually want. We have not reproduced every claim in the book here, so we will keep this to its widely-documented core: the discipline of writing the desired outcome, in the customer’s words, as the first artifact rather than the last.
That practice pairs with the other two like a third leg. The Mom Test fixes how you gather evidence. Escaping the Build Trap fixes what you measure. Working Backwards fixes when you decide what “good” means, which is before you start, not after you ship and go looking for a metric that flatters the work. Together they describe a single loop: define the outcome up front, validate it against real customer behavior, and judge the result by that outcome instead of by how much you shipped.
What we did with one lesson
The concrete application, for us, was deciding to track one outcome metric per growth initiative instead of a dashboard of activity. We had been reporting experiment volume, the number of tests in flight, the size of the backlog, all the proxies Perri warns about. We stopped, picked retained active users as the single number a given initiative was allowed to claim credit for, and required every experiment to start with a one-paragraph statement of the outcome it expected, written before the work, in the Working Backwards spirit.
We are not going to quote you a percentage lift, because the honest result was quieter and more useful than a number. The discipline killed experiments before they started. Several ideas that looked exciting could not survive writing down the outcome they expected and the evidence they were based on, because the evidence turned out to be a polite yes from a Mom Test conversation we had run badly. Fewer experiments ran. More of the ones that ran moved the one metric we cared about. The change was not a tactic. It was the removal of a habit, and the books are what told us the habit was there.
A short list for the long game
If you read three, read these three. The Mom Test by Rob Fitzpatrick, for evidence. Escaping the Build Trap by Melissa Perri, for measurement. Working Backwards by Bryar and Carr, for deciding what good looks like before you chase it. They cost a few dollars each and a weekend of attention, which is Fitzpatrick’s own pitch for his book: take two hours and it repays itself tenfold.
If you want more, Lenny’s full list is organized by job to be done, and the adjacent shelves are worth a look: High Output Management by Andy Grove and The Making of a Manager by Julie Zhuo for running the team that runs the experiments, Good Strategy/Bad Strategy by Richard Rumelt for the level above tactics, Build by Tony Fadell and Shoe Dog by Phil Knight for the nerve to keep going. The trick, per Lenny, is small: Bryan Johnson’s habit of reading for ten minutes before bed, which Lenny credits with changing how much he reads at all.
There is a tempting counter-argument, that AI has made all of this obsolete, that you can just ask a model what to build. Dan Shipper, cofounder of Every, a roughly 30-person company where, per his conversation with Lenny, everyone is an AI early adopter, argues close to the opposite: every agent still needs a human, and he is bullish on product managers precisely because someone has to decide what is worth building. The model can run the experiment. It cannot tell you whether the yes you got was real. That is still the oldest skill in the books, and it is still the one most growth teams skip.