Plan for a quarter of your projects to fail
A failure rate can be a target, as long as the failures are cheap and the lessons are kept.
Expect and hope that a quarter of your projects fail. If not, you’re not taking enough risks.
The name invites a mix-up with the economist, but this Adam Smith co-founded Xobni, the Outlook add-on for searching and sorting email, which came out of Y Combinator’s summer program in 2006. The line appears in notes on a talk he gave at MIT’s Startup Bootcamp in 2009, as one of a list of lessons from building the company.
The claim is about calibration. A team whose projects all succeed is almost certainly choosing projects it already knows how to finish. That feels like good management and often is, for a while. The cost shows up later, when a competitor ships something the team considered and dropped as too uncertain. A failure rate near zero means the portfolio holds only safe bets.
Picking a number turns a vague encouragement to take risks into something a team can check. If a product group runs eight experiments in a quarter and all eight work, the next round should include harder ones. If six of eight fail, the problem is different: the bets may be too wild, or the team may be abandoning them before they have had a fair test. A rough target marks out the range in which risk-taking is doing its job.
The rule fits work where individual projects are small and their outcomes independent. A software company testing new features is the clearest case, since one failed feature costs a few weeks and teaches something about the next attempt. Google’s practice of letting engineers spend part of their week on side projects rests on similar arithmetic. Most side projects go nowhere and a few become products.
It fits badly where a single project is the company. A startup with one product and eighteen months of money cannot hope that a quarter of it fails. For that founder the useful version of the advice sits one level down, inside the product: a quarter of the pricing tests, the landing pages, the sales scripts. The bet on the company itself is already as risky as it needs to be.
It also fails when failure is expensive in ways a count does not show. A failed internal tool costs time. A failed launch that loses customer data costs trust, and trust is not restored by the three projects that went well. Some work deserves a far lower tolerance, and a team that applies one ratio to everything will take risks in exactly the places it should not.
There is a quieter trap as well. Once failure is expected, a team can stop asking why a given project failed. The value of the failed quarter lies in what the team learns before starting the next project: which assumption was wrong, and how early the warning signs appeared. Without that review a steady failure rate is just a steady loss.
Read this way, the line is less about courage than about measurement. Count the projects that fail, and treat both a very low count and a very high one as information.