The Swiss cheese model: why product failures are rarely one bug

Last updated: August 5, 2026

Most serious product failures aren't caused by one bad decision. They're caused by several small ones lining up.

Amy Edmondson, a Harvard researcher who studies how failure happens, calls this a complex failure — distinct from a basic failure, which does trace back to one clear cause. She borrows the term Swiss cheese model from error researcher James Reason to describe it. Every process has small gaps, like holes in a slice of cheese. Most of the time the holes don't align and nothing gets through. Occasionally several line up in a row, and whatever was meant to get caught passes straight through.

Where this shows up in a product

The same structure shows up in a product experience. A checkout form autofills the wrong country. A confirmation step becomes something users learn to click past without reading. A default value sits unreviewed since launch. A validation rule checks the format of an input without checking whether the value makes sense.

None of these breaks the product on its own. Together, in the right sequence, they cause a real one: a customer paying for the wrong plan, a message sent to the wrong recipient, a form submitted with data no one meant to submit.

Auditing a product for its single point of failure misses this type of risk, because there usually isn't one. The more useful audit asks where two or three unrelated small gaps could land on the same user, in the same flow, at the same time. Toyota's answer to this at the assembly line was the andon cord: any worker can flag something that might be wrong the moment they see it, before it lines up with the next small gap behind it.

The audit, not just the question

What's the equivalent of that cord in your product? Something that catches a small gap early, before it has anything else to combine with.

The audit that finds this isn't a search for the one broken feature — it's mapping where two or three unrelated small gaps could land on the same user, in the same flow, in the same week. The autofill default. The confirmation nobody reads. The validation rule that checks format but not meaning. Each one is cheap to fix in isolation. Finding the combination before a real customer does is the actual job, and it's a different skill than fixing bugs as they're reported.

That's the audit worth running before a launch, not after an incident report forces it. If you want a second pair of eyes on where your product's holes are already lined up, that's a conversation worth having on your terms, not the tribunal's.