Fishbone Diagram

Why it matters

The obvious cause is rarely the root cause — and a team that grabs the first plausible explanation stops digging exactly where the real problem hides. The fishbone forces you to look everywhere before you commit.

For example: a website keeps going down. The obvious cause is “the server crashed — add more servers.” But a fishbone makes you enumerate possibilities across every category, not just hardware: the deploy method with no rollback, the missing alerting, the single overloaded on-call engineer, the flaky third-party dependency. Drill each with “why?” and the root turns out to be a release process that can’t be reversed when a bad build ships — nothing to do with server count. Buying more servers would have felt like progress and fixed nothing.

What it reveals. The full landscape of candidate causes, organized so the comfortable explanation can’t crowd out the categories a team would otherwise skip.
How it changes the read. You stop asking “what’s the cause?” (singular, first one that fits) and start asking “what could cause this, in each category — and which survives the evidence?”
When to foreground it. A recurring or complex problem where the obvious fix keeps failing, or a post-mortem at risk of blaming the most visible factor.
What you’d miss without it. The causes in the categories nobody looked at — the bias the diagram exists to defeat is anchoring on one loud theory before the others are even written down.
Where it misleads. A populated diagram is a map of hypotheses, not findings — treating the most plausible-sounding bone as proven, without testing it against evidence, just dresses up a guess.

How to invoke it in Ora

You have a recurring or stubborn problem — something that keeps breaking, or that the obvious fix didn’t fix — and you want the real cause, not the first one that comes to mind.

State the problem as a failure, and ask:

“Find the root causes: our checkout conversion keeps dropping after releases, and rolling back the last change didn’t help — what’s actually going on?”

The fishbone diagram is one of the core protocols of the Root Cause Analysis mode. Ora states the problem precisely, picks a category framework that fits the domain (the manufacturing 6 Ms, or service/software variants), enumerates candidate causes within every category, drills each with repeated “why?”, and then ranks the survivors for evidence-based testing rather than stopping at the most plausible one.

One thing to know: phrases like root causes of, why does this keep happening, draw a fishbone / give me an Ishikawa, what’s the real problem here, or we tried X but it didn’t work are what route you here. State the thing as a failure (“X exhibits failure mode Y”), not as a wish (“we need X to work better”) — the analysis reshapes wishes into failures before it can diagnose them.

One thing Ora won’t do: let plausibility stand in for proof. A candidate cause is a hypothesis until it’s tested against evidence, and the analysis flags every cause→effect link as evidenced as causal or correlation only rather than declaring a winner because it sounds right.

How it works

In the 1960s, a Japanese engineering professor named Kaoru Ishikawa spent a lot of time on factory floors, teaching ordinary workers how to hunt down the causes of quality problems. He kept running into the same human habit: a defect would appear, and the team would seize on the first explanation that came to mind — usually whatever was most visible or most recently changed — fix that, and move on. The defect would come back, because the thing they’d fixed wasn’t really the cause. They’d stopped looking the moment they found a suspect, never asking whether the categories they hadn’t checked might be hiding the real culprit.

So Ishikawa gave them a picture. He drew the problem as the head of a fish, with a horizontal spine running back from it, and off that spine, large diagonal “bones,” one for each major category of cause. In a factory these were the famous 6 Ms — Man, Machine, Method, Material, Measurement, and Mother Nature (the environment). The team’s job was to brainstorm possible causes and hang each one on the appropriate bone, and — this is the whole trick — to put at least something on every bone before deciding anything. Then, for each candidate, they’d ask “why does that happen?” and grow smaller bones branching off, drilling from a surface cause down toward its sub-causes. The result was a diagram shaped like a fish skeleton, which is why it’s called a fishbone (or, after its inventor, an Ishikawa diagram).

The power of the thing is almost embarrassingly simple, and it isn’t the drawing. It’s that the structure makes you look in the places your bias wants to skip. Left to itself, the mind anchors hard on one category — “it’s the machine,” “it’s the new hire” — and pours all its attention there while genuinely better explanations sit unexamined in a category nobody opened. Forcing a cause onto every bone breaks that anchor. A team convinced the problem was a faulty machine is made to ask, out loud, what about the method, the measurement, the materials — and surprisingly often the real cause is sitting on a bone they’d never have visited on their own. The diagram is a discipline against premature certainty, dressed up as a fish.

But Ishikawa was careful about its limits, and so is anyone who uses it well. A fishbone produces candidates, not conclusions. Every cause on every bone is a hypothesis, and the diagram’s worst failure mode is the team that brainstorms a beautiful, exhaustive map, votes on the most likely-sounding bone, and declares victory — having never tested whether that cause is actually responsible. Plausibility is not evidence. The map’s job is to make sure you’ve considered everything; verifying which candidate is the true root cause — by data, by experiment, by ruling out the rest — is the separate, non-negotiable step that turns a good brainstorm into a real diagnosis.

Framework & implementation

This section uses Ora’s own terms for the parts of an analysis, so that if you open the actual mode and lens files they line up. Each is glossed in plain language on first use.

Pipeline execution

The fishbone diagram is one of the two required protocols of the Root Cause Analysis mode (the other is the five-whys protocol it nests inside it) — listed in the mode’s lens_dependencies and loaded in its ANALYTICAL PERSPECTIVES block. As a lens_type: protocol, it contributes a procedure rather than a concept. The mode runs at Gear 4, Ora’s most thorough setting — a Depth analyst and a Breadth analyst diagnose the problem in parallel, critique each other, and revise.

Where the lens engages. It activates on its Detection Signals — a recurring or complex problem where the obvious explanation hasn’t produced a fix; a team defaulting to blame the most visible factor; surface-level fixes that keep failing. Its Application Steps run the six-step protocol: state the problem specifically, choose domain-appropriate categories, brainstorm causes within each, drill sub-causes via repeated “why?”, rank the candidates, and test the top ones against evidence.

What it produces in the analysis. The mode’s output sections are this protocol made structured. The problem-as-failure lands in Presented problem. The Chosen framework and rationale section is the lens’s category choice — the 6M (manufacturing), 4P (marketing), 4S (service), or other declared set — with the canonical category names appearing verbatim. The Category analysis section is the populated diagram: per category, the candidate causes, each drilled with a five-whys descent on the survivors. The Root causes section names the causes that reach real depth (2–4 levels beneath the symptom), each justified by the test “would removing it prevent recurrence?”

Cross-adversarial evaluation. At Gear 4 each analyst’s reading is critiqued by the other, which catches the lens’s signature failures — keyed to its Critical Questions: most causes piled under one category while others sit empty (single-category anchor); the team voting on a likely cause and stopping without testing (plausibility-as-evidence); and a diagram built once and never revised as evidence arrives (stale diagram). The evaluator presses the mode’s discipline hardest at the Evidence assessment section, where at least one cause→effect link must carry an explicit correlation-vs-causation note — a candidate is evidenced as causal or flagged correlational, never assumed.

Honesty discipline. The mode separates corrective recommendations (fix the surfaced failure) from preventive ones (fix the root condition that produced it), and where a branch bottoms out at “human error” it is required to descend one more level — to the process, policy, or incentive that made the error likely — rather than stopping at a person to blame. And it records confidence in the dominant causal chain alongside the alternative framing it considered and rejected.

What the analysis will not do. It will not let a category go unexamined to keep the diagram tidy, will not promote a plausible cause to a root cause without evidence, and will not accept “operator error” as a terminal answer when a process produced the operator’s mistake.

Origin and evidence

The fishbone is Kaoru Ishikawa’s, developed in the 1960s as part of Japan’s post-war quality revolution and popularized in his Guide to Quality Control (1968) and What Is Total Quality Control? The Japanese Way (1985). Ishikawa, working alongside the broader quality movement of W. Edwards Deming and Joseph Juran, designed the diagram specifically as a tool ordinary factory workers could use in quality circles — democratizing root-cause analysis rather than reserving it for engineers. It became one of the “seven basic tools of quality” and spread far beyond manufacturing into healthcare, software incident response, and service operations, where the category sets are adapted (the 6 Ms become People/Process/Policy/Place or Infrastructure/Code/Data/Process) but the categorize-then-drill discipline is unchanged. Its enduring evidence is practical: decades of use across industries because the structure reliably surfaces causes that unstructured brainstorming misses.

Applications and common uses

The fishbone is a working tool wherever a problem needs its causes mapped before a fix is chosen, used to structure a diagnosis and to guard it against premature blame.

Manufacturing and quality control. Its native ground: diagnosing defects, yield losses, and process variation against the 6 Ms, the use Ishikawa built it for.
Software incident post-mortems. Adapted categories (infrastructure, code, data, process, external services, monitoring) keep a retrospective from blaming the most visible failure and missing the process gap underneath it.
Healthcare and patient safety. Root-cause analysis of adverse events uses the fishbone to force consideration of system causes — staffing, equipment, procedure, communication — rather than stopping at the clinician nearest the error.
Service and operations. Customer-experience failures, delays, and recurring complaints get mapped against People/Process/Policy/Place/Product/Procedure to find the structural cause behind a symptom.
Any team retrospective. Wherever a group is at risk of anchoring on one theory, the requirement to fill every bone is a cheap, fast antidote to tunnel vision.

In every case the payoff is the same: a structured map that has been forced to consider every category, a short-list of candidate root causes drilled to real depth, and the discipline to test them rather than crown the most plausible one.

Failure modes and when not to use it

The lens’s characteristic ways of going wrong are catalogued in its Common Failure Modes:

Single-category anchor. Most causes listed under one category while others stay sparse or empty — the very bias the tool exists to defeat, re-emerging inside it. The tell is a lopsided diagram. Require at least one cause per category before proceeding.
Plausibility-as-evidence. Voting on the most likely-sounding cause and stopping there, without testing. The tell is a “root cause” backed by a show of hands rather than data. Require evidence-based verification before declaring any cause root.
Stale diagram. Building the diagram once and never updating it as new evidence arrives. The tell is a fixed artifact contradicted by later findings. Treat it as a living analysis, revised as evidence accumulates.

When not to reach for it. When the problem is simple and the cause is genuinely known, the ceremony adds overhead without insight — just fix it. When the causes are tightly interdependent with feedback loops between them, the fishbone’s neat independent categories misrepresent the structure, and a systems-dynamics loop map serves better. And when what’s needed is a probabilistic weighing of competing explanations against evidence rather than an exhaustive enumeration of candidates, an analysis of competing hypotheses is the sharper instrument — the fishbone is for making sure nothing was missed, not for adjudicating which survivor is true.

Root Cause Analysis — the analysis this protocol anchors; turns a recurring failure into a tested set of root causes with corrective and preventive fixes.
Five Whys — the drilling discipline used inside each bone: ask “why?” repeatedly to descend from a surface cause to its root.
Fundamental Attribution Error — the bias the analysis guards against: blaming a person (“operator error”) when the situation or process was the real cause.
Feedback Loops — when causes interact rather than sit in independent categories, the loop map picks up where the fishbone’s neat bones leave off.