The One Theorem That Governs Survival in a Volatile World
Why lowering the cost of failure matters more than raising the quality of your plan
More than a decade ago, I was in the insanely fortunate position of running Mozilla Labs – the “please disrupt yourself” unit inside the nonprofit behind Firefox. The team was brilliant, some of the best engineers in Silicon Valley, and we had a pattern that felt productive but was quietly killing us: an idea would hit our standup, we’d debate it like philosophers, and then someone would say the five most dangerous words in product development – “I know how to build this.” They’d vanish into their cave, headphones on, code editor glowing, and three days later they’d resurface with something gorgeous. Real, running code. You could click around and interact with it. We all felt accomplished.
Then we’d put it in front of a user. Fifteen seconds. “I don’t get it.” Three days of work – DOA (“dead on arrival” – fun fact: also the name of a meeting room at Mozilla at the time).
At that pace we could test maybe ten ideas a month. Product-market fit usually takes hundreds of iterations. We were years away from finding it, and we simply didn’t have years.
One afternoon, after yet another fifteen-second rejection, I did something that felt outright strange at the time: I asked a colleague to close his laptop, grab a stack of index cards and some Sharpies, and start drawing. He looked at me like I’d suggested interpretive dance. He was a C++ and Python person – not someone who drew doodles on index cards. But he did – badly, reluctantly, beautifully – and we walked those cards across the street to the Starbucks on Castro Street in Mountain View, which at the time was basically Silicon Valley’s cafeteria. “Can I buy you a coffee in exchange for five minutes of your time?” More than 80% of the people we asked said yes. We’d place the first card on the table, get feedback, retreat to a corner to redraw, find the next stranger. By the time the caffeine jitters set in – three hours, maybe – we hadn’t tested one prototype. We’d tested thirty.
That afternoon changed the way I think about everything. Three days to learn one thing with code. Three hours to learn thirty things with Sharpies and index cards. Not because the engineers were slow, but because the medium was expensive. High-fidelity code carries a high cost of failure – emotionally, financially, temporally – and when failure is expensive, you instinctively avoid it. You plan more. You debate more. You polish more. You learn less.
Which brought me to the idea I’ve spent the last fifteen years trying to articulate as precisely as I can – what I now call the Core Theorem: the speed of learning is inversely proportional to the cost of failure. If failure is expensive, you learn slowly. If failure is cheap, you learn fast. That’s it. That’s the whole thing. And it governs the survival of every organization operating in a volatile world, which – in case you haven’t checked the news lately – is every organization.
The logic is disarmingly simple. When a mistake could cost you $100,000, your reputation, or your job, you’ll hesitate. You’ll double-check. You’ll form a committee. You’ll bring in a consultant. You’ll optimize for the appearance of competence instead of the reality of learning. But when a mistake costs $10 and an awkward conversation at a coffee shop? You’ll just try. And if that fails, you’ll try something else – all before lunch.
Tom Chi, one of the founding members of Google X – the moonshot factory behind self-driving cars and Internet balloons – understood this better than anyone. When his team was working on Project Glass (which became Google Glass), the engineers estimated it would take six months to build the first working prototype. Optics, miniaturized projection, ergonomics, software – hard technology, expensive to get wrong. Tom walked out of the room and came back 45 minutes later with a coat hanger bent into a neck loop, a sheet of plexiglass, a middle-school sheet protector taped to it, and a pico-projector connected to a netbook. It looked like garbage. It cost less than $500. And within an hour his team had learned that red text washes out, the upper right corner gives headaches, and email pop-ups are socially awkward. They learned more in one afternoon with a coat hanger than they would have in six months of “proper” engineering – because the cost of being wrong was almost zero.
The engineers wanted to predict the solution. Tom wanted to ping the solution space. The beautiful irony is that by refusing to build the “real” thing, he got to the real thing faster than anyone else.
Most organizations get this backwards. They shout “go faster!” while keeping the cost of failure high. They say “fail fast and fail forward” while promoting the people who never make mistakes. They create innovation labs and demand agile workflows – but require three signatures to approve a $500 experiment. The incentive structure contradicts the aspiration, and incentives always win.
So here’s the practical question: What is your coat hanger? What is the cheapest, fastest, ugliest version of the thing your team has been debating in conference rooms for six months? And what would it take to test it this week – not next quarter, not after the strategy offsite, not when the budget gets approved – but this week?
Audit the price of your errors. Count the signatures required to run a small experiment. Look at what happens to the person who tries something and fails versus the person who sits in meetings and never ships. That gap – between the stated value of learning and the actual cost of failure – is where your organization’s speed goes to die.
Close that gap, and you don’t need to hire faster people or buy better tools. You just need to hand them a Sharpie and point them at the nearest coffee shop.
This briefing is adapted from my new book OUTLEARN: The Art of Learning Faster Than the World Can Change, launching April 28. It’s the first volume in a series called Built for Turbulence – short, framework-dense field manuals for leaders who are done planning beautifully and ready to start learning fast. More on that soon.
@Pascal


