I finally read Project Hail Mary. It is the best book about running experiments I have come across, and it has nothing to do with growth.
The setup, without spoiling much: a science teacher wakes up alone on a spacecraft with no memory, a dying-sun problem to solve, and whatever equipment happens to be bolted to the walls. No research budget. No peer review. No second opinion. Nobody to escalate to.
What he has instead is a chain of tiny, cheap, fast experiments, most of them improvised out of the wrong materials.
That is the part that stayed with me. Not the scale of the problem. The posture toward it.
The smallest question you can answer today
He never waits for better instruments. He asks the smallest question he can answer with what is in front of him, answers it, and lets the answer choose the next question.
It sounds obvious written down. It is not how most organisations behave.
Watch what that loop actually does. Each answer is imperfect. Some are wrong and get corrected later. But every answer narrows the space of what could be true, and narrows it now, rather than after the perfect apparatus arrives. Ten rough answers in sequence beat one precise answer that is still being set up. Not because rough is better than precise, but because the sequence compounds and the setup does not.
And notice what he does not do. He does not decide that the problem is too important for improvised tools. If anything, the stakes are the reason he moves fast. When the clock matters, waiting for certainty is not caution. It is a decision to lose time.
The meeting that is the exact inverse
I have sat in a great many growth meetings that were the exact inverse of this.
The pattern is familiar enough that you could script it. Someone proposes a test. Then the objections arrive, each reasonable in isolation:
- We cannot test that properly until the warehouse is clean
- Until attribution is trustworthy
- Until we have the traffic to reach significance
- Until the new CDP is live
- Until we have agreed on the definition of an active user
Every one of those objections is legitimate. I want to be clear about that, because the argument here is not that data quality does not matter. It does. Bad instrumentation produces confident nonsense, and I have shipped my share of it.
But together, those objections function as something else. They become a way of postponing a decision behind infrastructure. Nobody says "I don't want to find out." They say "not yet," and "not yet" is a much more respectable way of saying the same thing.
The infrastructure project always has a delivery date. The delivery date always slips. And the question that prompted the meeting sits, unanswered, for as long as it takes.
What the real question cost
Here is the shape of it, which I suspect is familiar. A team has a strong product and is debating a second one. The real question is not about attribution, or significance, or the warehouse. The real question is simpler and more frightening: does anyone want the second product at all?
That question could have been settled in under two weeks with a fake door and a spreadsheet. Put a button where the product would live. Count who clicks it. Talk to the people who did. You learn more about demand from that than from months of debate about measurement, and you learn it before you have built anything.
Instead, the question waits for the stack to be ready. And the stack is never quite ready, because a stack is a thing you can always improve.
Precise answers that arrive next quarter lose to directional answers that arrive this week. Not sometimes. Almost always.
What the best experimenters actually have
The strongest experimenters I have worked with did not have the most sophisticated stack. What they had was a low threshold for what counts as a usable answer.
That is a specific trait, and it is worth describing carefully, because it is easy to mistake for sloppiness.
They take directional over precise, every time, if directional arrives this week. They know the difference between a question that needs a rigorous answer and a question that only needs to know which way the wind is blowing. Most questions in growth, especially early ones, are the second kind. Is there demand? Does this message land at all? Is this channel dead or merely expensive? You do not need three decimal places to answer any of those. You need enough signal to decide what to do next.
They are also comfortable being wrong in small ways. A scrappy test that misleads you a little and gets corrected next week is far cheaper than a rigorous test that takes a quarter to set up and answers a question nobody is asking anymore.
And they save rigour for the decisions that deserve it. When a result is going to move a large budget, change pricing for everyone, or end up in a board deck, they slow down, instrument properly, and wait for significance. The skill is not being scrappy everywhere. It is knowing which decisions can survive a rough answer.
Why teams default to waiting
If scrappy answers are so useful, why do teams keep waiting for perfect ones? A few reasons, none of them stupid.
Infrastructure work feels like progress. Cleaning the warehouse, rebuilding attribution, migrating to a new CDP: these are real projects with real deliverables. They produce visible output. Running a scrappy test that might return an embarrassing answer does not feel nearly as productive, even when it is.
A rough answer is easy to argue with. Anyone who disliked the result can attack the method. A precise answer is harder to dismiss, so people who expect pushback reach for precision as armour. That is understandable. It is also how a team ends up spending a quarter building a test that could have been a fake door.
Nobody gets blamed for waiting. If you postpone a decision until the data is clean, and the decision turns out badly, you followed process. If you act on a directional answer and it turns out badly, you were reckless. The incentives reward delay, even when delay is the most expensive option on the table.
None of these are character flaws. They are the rational responses of reasonable people to the way most growth organisations keep score. Which is exactly why they are so hard to shift.
Improvised junk and patience
There is a moment late in the book where an enormous problem gets solved with improvised junk and patience. I will not say more than that.
That is most of growth, honestly. Not the clean experiment design from the textbook, not the dashboard with every metric reconciled. A series of rough, fast, slightly embarrassing answers, each one good enough to choose the next question, assembled patiently until the shape of the truth becomes clear.
If your team's experiments keep getting postponed until the stack is ready, it is worth asking a blunt question: which of these decisions actually needs a precise answer, and which ones are we waiting on because waiting feels safer?
Your stack is not the constraint. Your tolerance for a scrappy answer is.