"Fail Fast": Where the Phrase Actually Came From, and What It Really Means
Team Ilm Ora · 13 September 2026
The man whose 2011 book made "fail fast" a household phrase in the business world has publicly said he hates the phrase — and the software engineer who coined a nearly identical term seven years earlier meant something almost entirely different by it.
Origin One: A Software Engineering Principle
The earliest well-documented, formal use of "fail fast" as a specific technical term comes from software engineering, not business strategy. In a 2004 article for IEEE Software titled simply "Fail Fast," software engineer Jim Shore described a specific system-design philosophy: software should be built to immediately and visibly report an error the moment something goes wrong, rather than quietly working around the problem and continuing to run in an unreliable, partially broken state.
In this technical sense, a "fail-fast" system is explicitly the opposite of a "fault-tolerant" one. Instead of trying to gracefully absorb an error and keep functioning, a fail-fast system deliberately halts and raises a clear signal the instant it detects something wrong — because a system that keeps running silently after an internal error is far harder to debug than one that stops immediately and points directly at the problem. This idea, sometimes formalized in object-oriented programming as checking an object's internal state the moment it's created rather than waiting for it to cause a mysterious failure later, remains a standard, widely taught principle in software design today, entirely separate from anything to do with startups or business strategy.
Origin Two: A Startup Strategy Phrase
The far more famous modern usage comes from the startup and business world, closely associated with entrepreneur Eric Ries and his 2011 book The Lean Startup. Ries's "lean startup" methodology — drawing on ideas from Japanese manufacturing practices like Toyota's Kaizen and Just-in-Time production, alongside agile software development principles formalized in the 2001 Agile Manifesto — argues that startups should rapidly build minimal versions of a product, test them against real customer feedback, and use that feedback to decide quickly whether to continue or change direction, rather than spending months or years building something in isolation based on untested assumptions.
"Fail fast" became the popular shorthand for this approach: run small, cheap experiments, find out quickly which ideas don't work, and move on before wasting significant time or money on a flawed direction.
The Twist: Ries Himself Rejects the Phrase
Here's the detail that rarely makes it into how the phrase gets used today: Eric Ries, the person most responsible for popularizing this idea in modern business culture, has explicitly and repeatedly said he dislikes the phrase "fail fast." In one widely cited comment, Ries compared it to telling a sprinter, "the point isn't to run fast, it's to breathe fast" — arguing that the phrase mistakes a side effect (failing quickly, when you do fail) for the actual goal, which is learning quickly through disciplined, structured experiments, not failing for its own sake or treating repeated failure as inherently virtuous.
Ries has pushed back specifically against the idea that "fail fast" gives entrepreneurs license to skip rigorous thinking altogether — throwing out random ideas as quickly as possible and calling any resulting failure "progress." His actual framework calls for formulating a specific, testable hypothesis, running a deliberate experiment to test it, and learning from the result — a considerably more disciplined process than the popular, watered-down version of "fail fast" that gets repeated in many business contexts today, often used as a justification for careless, unstructured trial and error.
What "Fail Fast" Should Actually Mean
Put both origins together, and a more accurate version of the phrase emerges than the one usually thrown around in casual business conversation: build a way to detect problems — in code, in a product idea, in a business assumption — as early and as clearly as possible, so you can address them before they compound into something far more costly to fix later. That's genuinely useful advice, grounded in both a specific software engineering discipline and a specific, structured approach to entrepreneurial experimentation.
What it was never meant to mean, in either its technical or business origin, is "failure doesn't matter, just do things quickly and see what happens" — a much looser, more casual interpretation that has become disconnected from both of the phrase's actual, more rigorous roots.
The entrepreneur most responsible for popularizing "fail fast" has publicly said he hates the phrase — arguing that failing quickly was never the actual point. Learning quickly was.