AboutHow we built thisSponsorshipShop
SearchSubscribeDecision ToolsBusiness ModelsFrameworksReading Lists
Privacy PolicyTerms of UseCookie PolicyRefund PolicyAccessibilityDisclaimer

© 2026 Faster Than Normal. All rights reserved.

Faster Than Normal
DecisionsPeopleBusinessesNewsletterSubscribe
Start reading →
  1. Home
  2. Decision tools
  3. Ishikawa Diagram
Finding Root Causes

Ishikawa Diagram

Map all potential causes of a problem across categories to see the full landscape

ReversibilityAny — diagnostic tool
Complexity
Time required30-90 min
Tool #008Also called: Fishbone Diagram, Cause-and-Effect DiagramOrigin: Kaoru Ishikawa, 1960s (Kawasaki shipyards)21 min read

On this page

  • What This Tool Does
  • How to Use It — Step by Step
  • When It Works Best
  • When It Breaks Down
  • Visual Explanation
  • Pairs With
  • Real-World Application
  • Analyst's Take
  • Top Resources

Contents

  1. 1. What This Tool Does
  2. 2. How to Use It — Step by Step
  3. 3. When It Works Best
  4. 4. When It Breaks Down
  5. 5. Visual Explanation
  6. 6. Pairs With
  7. 7. Real-World Application
  8. 8. Analyst's Take
  9. 9. Top Resources
Use this when something has gone wrong and you need to find the real cause — not the obvious one. The Ishikawa diagram forces you to systematically decompose a problem into every category of possible cause before you start fixing anything, preventing the most common mistake in problem-solving: treating symptoms instead of root causes.
Section 1

What This Tool Does

Something breaks. Revenue drops, churn spikes, a product launch underperforms, a manufacturing line starts producing defects at three times the normal rate. The instinct — universal, immediate, almost always wrong — is to grab the first plausible explanation and start fixing it. The new vendor's materials are subpar. The sales team isn't closing. The latest code deploy introduced a bug. These explanations feel right because they're recent, visible, and emotionally satisfying. They give you someone or something to blame, and blame feels like progress. It isn't.
Kaoru Ishikawa understood this at the Kawasaki shipyards in the 1960s. He watched teams of skilled engineers repeatedly misdiagnose quality problems because they converged on single causes when the real failures were systemic — three or four contributing factors interacting in ways that no individual engineer could see from their vantage point. His solution was deceptively simple: draw a fish. Place the problem at the head. Draw bones — major categories of possible causes — branching off the spine. Then populate each bone with specific causes, drilling deeper with sub-branches until you've exhausted every plausible contributor. The result looks like a skeletal fish, which is why most people call it a fishbone diagram. The formal name honours its inventor.
The mechanism works because it changes the shape of the question. "What caused this?" invites a single answer. The human brain, wired for narrative coherence, will happily supply one. The Ishikawa diagram replaces that question with "What are all the things that could have contributed to this?" — and that plural framing is the entire cognitive intervention. It forces you to keep looking after you've found the first plausible cause. It forces you to look in categories you wouldn't naturally consider. And it forces you to see the problem as a system of interacting factors rather than a single point of failure.
Most real-world problems worth diagnosing have between three and seven contributing causes. The Ishikawa diagram is built to find all of them before you spend a dollar fixing any of them. That sequencing — diagnose completely, then act — is what separates teams that solve problems permanently from teams that play whack-a-mole with recurring symptoms for years.
Section 2

How to Use It — Step by Step

Instructions on the left. Worked example — "Why has our e-commerce order fulfilment error rate risen from 1.2% to 4.7% over the past quarter?" — on the right.
Step 1 — Define

Write a specific, measurable problem statement

Precision here determines everything downstream. "Fulfilment is bad" gives you nothing to work with. You need the metric, the magnitude of the deviation, and the timeframe. A good problem statement answers: what changed, by how much, and since when? Place this statement at the head of the fish — the right side of your diagram. If the team can't agree on the problem statement, you're not ready for the fishbone. Fix that first.
Worked example

E-commerce fulfilment errors

"Order fulfilment error rate (wrong item, missing item, or damaged shipment) increased from 1.2% to 4.7% between Q3 and Q4 2024, affecting approximately 3,400 orders per month." Specific. Measurable. Time-bounded. The team knows exactly what they're diagnosing.
Step 2 — Categorise

Select 4–6 cause categories as the main branches

The classic manufacturing framework uses the "6 Ms": Manpower, Methods, Machines, Materials, Measurement, Mother Nature (Environment). These work well for physical operations. For software, services, or commercial problems, adapt freely: People, Process, Technology, Policy, Data, External. The categories are scaffolding, not scripture. If a standard category doesn't apply to your problem, drop it. If you need a category that doesn't exist in any template, create it. More than six branches usually means you're slicing too thin.
Worked example

Categories for fulfilment errors

Warehouse Process (picking, packing, shipping procedures), Staffing (hiring, training, scheduling), Technology (WMS software, barcode scanners, automation), Inventory Data (SKU accuracy, stock levels, catalogue errors), Supplier/Materials (packaging, inbound quality), Volume/Seasonality (demand spikes, capacity constraints).
Step 3 — Brainstorm

Generate specific causes under each branch

This is a team exercise — not a solo activity. Get 5–8 people with direct knowledge of the problem domain. Use silent brainstorming first: everyone writes causes on sticky notes independently for 8–10 minutes before anyone speaks. One cause per note. No filtering, no debating, no "that's not really a cause." Quantity first. Then place the notes on the appropriate branches and discuss. Apply the 5 Whys to promising causes: keep asking "but why does that happen?" until you reach something structural and actionable. Sub-branches are where the real insight lives.
Worked example

Populating the branches

Under Staffing: → 40% of warehouse staff hired in last 60 days (holiday surge) → Training programme cut from 5 days to 2 days → Night shift has no senior picker on duty. Under Inventory Data: → SKU migration to new WMS left 300+ items with wrong bin locations → Product photos in pick system don't match updated packaging → Cycle counts suspended during peak season. Under Technology: → Barcode scanners failing in cold zone (battery issue) → WMS doesn't flag when two similar SKUs are in adjacent bins.
Step 4 — Prioritise

Vote on most likely root causes, then validate with data

Give each participant 3–5 votes (dots, stickers, digital votes). Cluster the results. The top-voted causes are your hypotheses — not your conclusions. Now comes the step most teams skip: verify with data. Pull error logs. Segment by shift, by warehouse zone, by SKU category, by employee tenure. A cause the team was certain about may not show up in the data. A cause nobody voted for may emerge as dominant. The fishbone generates the map of possibilities; data tells you which paths are real.
Worked example

Data overturns the consensus

The team voted "undertrained new hires" as the #1 root cause. Logical. But error log analysis tells a different story: error rates are nearly identical across new and experienced staff. The spike correlates instead with specific SKU categories — the 300 items whose bin locations were wrong after the WMS migration. New hires and veterans alike were picking from incorrect bins because the system was sending them to the wrong shelf. The root cause isn't people. It's data integrity. Without the fishbone, nobody would have listed "SKU migration errors" — it happened two months ago and seemed resolved. Without the data check, the team would have doubled down on training and watched the error rate stay at 4.7%.
Step 5 — Act

Design targeted countermeasures for validated root causes

For each data-validated root cause, define a specific countermeasure, an owner, a timeline, and a success metric. Resist the urge to fix everything at once. Start with the cause that explains the largest share of the problem. Implement, measure, confirm the error rate drops, then move to the next cause. This sequential approach lets you isolate which fix actually worked — critical for learning, not just solving.
Worked example

Targeted fix, measured result

Countermeasure #1: Audit all 300 migrated SKUs and correct bin locations in the WMS. Owner: inventory ops lead. Timeline: 5 business days. Success metric: error rate on affected SKUs drops below 2%. Countermeasure #2: Implement adjacent-bin conflict alerts in the WMS for similar SKUs. Owner: systems team. Timeline: 2 weeks. The team resists the temptation to also overhaul the training programme — that can wait until the data-validated causes are resolved and the residual error rate is measured.
Section 3

When It Works Best

✓

Ideal Conditions for the Ishikawa Diagram

DimensionBest fit
Problem typeRecurring or worsening problems with multiple possible causes. The tool earns its keep when the obvious fix has already been tried and the problem persists — a signal that the real root cause is hiding behind the visible symptom.
Team compositionCross-functional groups where each participant sees the problem from a different operational angle. A warehouse manager, a systems engineer, a customer service lead, and a data analyst will populate entirely different branches — and the intersections between their branches are where the real causes live.
Data environmentMost powerful when you can validate brainstormed causes with operational data afterward. The fishbone generates hypotheses; it doesn't prove causation. Without a verification step, the diagram becomes a group opinion exercise dressed up as analysis.
Decision stageEarly diagnosis — before any solution has been chosen or resources committed. This is a tool for understanding what's happening, not for deciding what to do about it. It sits at the very beginning of a problem-solving sequence.
Complexity levelProblems that are complicated (many parts, but knowable) rather than complex (emergent, unpredictable). A supply chain error is complicated. A market shift driven by consumer sentiment is complex. The fishbone assumes causes can be identified and categorised — an assumption that breaks in truly complex domains.
Time investmentWorth deploying when the problem costs more to leave unsolved than the 60–120 minutes the session requires. Overkill for a one-time minor glitch. Essential for chronic, expensive, or safety-critical failures where getting the diagnosis wrong means wasting months of effort on the wrong fix.
Section 4

When It Breaks Down

⚠

Failure Modes

Failure patternWhat goes wrongWhat to use instead
Interacting causes treated as independentThe fishbone's structure implies that each cause contributes independently to the problem. In reality, causes interact: "undertrained staff" combined with "confusing software interface" produces errors that neither cause would produce alone. The diagram has no mechanism for showing these interactions.Causal Loop Diagrams or Connection Circles to map cause-to-cause relationships
HiPPO dominanceThe Highest Paid Person's Opinion anchors the brainstorm. The diagram fills with causes that validate the senior leader's pre-existing theory. Dissenting hypotheses never make it onto the board. The output looks rigorous but is just one person's mental model with visual scaffolding.Silent individual brainstorming before group discussion; anonymous digital input tools
Category forcingTeams feel compelled to populate every branch equally, inventing causes for categories where none genuinely exist. If "Environment" isn't relevant to your software bug, don't manufacture three sub-causes to fill the branch. Forced symmetry dilutes the signal.Use fewer categories; let the problem dictate the structure, not the template
Diagnosis without verificationThe team completes the diagram, votes on "most likely" causes, and immediately begins implementing fixes — skipping data validation entirely. The fishbone produces plausible hypotheses, not proven root causes. Acting on unverified hypotheses is expensive guessing with a veneer of process.Pair with Pareto Analysis or structured data audit before committing to any countermeasure
Novel or emergent problemsThe tool assumes the problem has identifiable causes that fit into known categories. For genuinely unprecedented situations — a new technology failing in an unexpected way, a market discontinuity — the categories themselves may be wrong. You're brainstorming within the wrong frame.Cynefin Framework to classify the problem domain first; Reframing to challenge the problem definition
Shallow brainstormingTeams list surface-level causes ("communication breakdown," "lack of resources") without drilling into sub-causes. These are descriptions of symptoms, not root causes. A fishbone full of vague, high-level causes is useless — it tells you everything and nothing simultaneously.Pair with 5 Whys on every cause to force depth; require at least two levels of sub-branching
The most dangerous failure mode is diagnosis without verification — and it's the most common. The fishbone diagram has a seductive quality: it looks thorough. Branches, sub-branches, categories, votes. The visual complexity creates a feeling of analytical rigour that may be entirely unearned. Teams walk out of a fishbone session feeling confident they've found the root cause, when what they've actually done is collectively agree on a hypothesis that nobody has tested. The fix is simple but requires discipline: treat the fishbone output as a prioritised list of hypotheses, not conclusions. The next meeting should be about data, not solutions.
Section 5

Visual Explanation

PROBLEMFulfilment errors1.2% → 4.7%Warehouse ProcessPick-path not optimisedNo double-check at packStaffing40% hired in 60 daysTraining cut to 2 daysTechnologyScanner battery in cold zoneNo adjacent-bin alertInventory Data300 SKUs wrong bins ★Cycle counts suspendedSupplier / MaterialsNew packaging mismatchFragile items unmarkedVolume / SeasonalityHoliday volume +65%Temp staff on night shift★ = DATA-VALIDATED ROOT CAUSE
Ishikawa diagram — populated with the e-commerce fulfilment error worked example. The starred item (★) is the data-validated root cause.
Section 6

Pairs With

The Ishikawa diagram is a diagnostic tool, not a complete problem-solving system. It generates hypotheses about causes. What happens before and after it determines whether those hypotheses lead to real fixes or expensive guesses.
Use before
Reframing
The fishbone is only as good as the problem statement at its head. Reframing forces you to question whether you're solving the right problem before you start decomposing causes. A misframed problem produces a perfectly structured diagram that solves nothing.
Use before
Cynefin Framework
Is the problem complicated (knowable causes, analysable) or complex (emergent, unpredictable)? The fishbone works for complicated problems. For complex ones — where cause and effect are only visible in retrospect — you need probe-sense-respond, not root cause analysis.
Use after
5 Whys
Apply 5 Whys to each cause on the fishbone to drill below surface-level explanations. "Training was insufficient" is a symptom. Why was it insufficient? Budget was cut. Why? Because headcount grew faster than the L&D team could scale. Now you're at a structural cause you can actually fix.
Use after
Pareto Analysis
Once the fishbone generates 15–25 possible causes, Pareto analysis identifies which 20% of causes drive 80% of the problem. This is how you sequence your fixes — start with the causes that explain the largest share of the deviation.
Use after
Impact-Effort Matrix
After identifying and validating root causes, plot the countermeasures on an impact-effort grid. Some root causes are high-impact but cheap to fix. Others require months of systems work. The fishbone tells you what to fix; the matrix tells you what order to fix it in.
Mental model
[Inversion](/mental-models/inversion)
Inversion asks "what would guarantee this problem?" — the reverse fishbone. Use it as a brainstorming prompt to surface causes the team wouldn't naturally consider. If you were trying to create a 4.7% error rate on purpose, what would you do? That list often contains the actual root causes.
Section 7

Real-World Application

Toyota — the Andon cord and systemic quality diagnosis

The scenario
Toyota's production system is the most documented quality culture in industrial history, and the Ishikawa diagram sits at its centre — not as a standalone tool, but as the structured thinking step within Toyota's broader problem-solving methodology. In the early 1980s, Toyota's Georgetown, Kentucky plant (its first major US facility) faced a persistent problem: paint defects on the Camry line were running at roughly three times the rate of comparable Japanese plants. American managers initially attributed the gap to workforce inexperience. The Japanese advisors refused to accept that explanation without evidence.
How the tool applied
Cross-functional teams — paint shop operators, maintenance technicians, quality engineers, and supply chain staff — ran fishbone sessions using Toyota's adapted categories: Man, Machine, Material, Method, and Environment (the "4M+1E" variant). Under "Environment," a cause emerged that nobody had initially considered: humidity levels in the Kentucky plant fluctuated far more than in the climate-controlled Japanese facilities, and the paint booth's environmental controls weren't calibrated for the local climate range. Under "Material," the team discovered that a US-sourced paint thinner had slightly different evaporation characteristics than the Japanese equivalent. Under "Method," they found that the spray gun cleaning protocol — identical to the Japanese procedure — was inadequate given the different thinner chemistry.
What it surfaced
Three interacting causes, none of which was "workforce inexperience." The humidity variation changed how the paint adhered. The different thinner chemistry changed how the paint dried. And the cleaning protocol, designed for different chemistry, left residue that created micro-defects. No single cause would have produced the defect rate alone. The interaction of all three — environment × material × method — was the root cause system.
The non-obvious factor
What made Toyota's application distinctive wasn't the diagram itself — it was the cultural norm that the diagram's output required verification before action. Toyota's "genchi genbutsu" principle (go and see for yourself) meant that after the fishbone session, engineers physically went to the paint booth, measured humidity at different times of day, tested the thinner evaporation rates, and inspected the spray guns after cleaning. The fishbone generated the hypotheses. The shop floor validated them. Most organisations skip that second step. Toyota never does, which is why the fishbone actually works within their system — and why it often fails when transplanted into cultures that treat the brainstorming session as the endpoint rather than the beginning.
Section 8

Analyst's Take

Faster Than Normal — Editorial View
The Ishikawa diagram is sixty years old and was designed for shipyard quality control. It has no algorithm, no scoring mechanism, no mathematical sophistication. It is, at bottom, a structured way to brainstorm on a whiteboard. And it remains one of the most genuinely useful diagnostic tools available to any operator in any industry — because the problem it solves is not technical but cognitive. The human tendency to stop looking for causes after finding the first plausible one is so powerful, so automatic, that you need a physical structure to override it. The fishbone is that structure. Its longevity is not nostalgia; it's evidence that the underlying cognitive bias hasn't changed.
The failure mode I encounter most often in practice is what I'd call "fishbone theatre." A team gathers, draws the diagram, populates the branches, votes on root causes, and disperses feeling productive. Nobody checks the data. Nobody validates the hypotheses. The diagram goes into a slide deck, the team implements the fix that the most senior person advocated before the session started, and six months later the same problem recurs. The fishbone didn't fail — it was never actually used. It was performed. The tell is simple: if your fishbone session didn't change anyone's mind about the root cause, it didn't work. The whole point is to surface causes that weren't already on the table.
The highest-leverage modification: run the brainstorm in silence first. Ten minutes, sticky notes, no talking. Every participant writes their hypothesised causes independently before anyone shares. Then place the notes on the diagram. Then discuss. This single procedural change eliminates the anchoring effect of the first speaker, neutralises hierarchy, and consistently produces 30–40% more unique causes than open-discussion brainstorming. I've seen teams discover root causes from a junior operator's sticky note that no senior leader had considered — causes that turned out to be the actual driver when the data was checked. The fishbone's value is directly proportional to the diversity of hypotheses it surfaces. Silent brainstorming is how you protect that diversity.
Section 9

Top Resources

01
Guide to [Quality](/mental-models/quality) Control — Kaoru Ishikawa (1976)
Primary source
The original source. Ishikawa's own explanation of the cause-and-effect diagram within the context of his "Seven Basic Quality Tools." Manufacturing-oriented and dense, but the core method — particularly his guidance on category selection and sub-cause drilling — remains the definitive reference. Chapter 4 covers the diagram specifically; the surrounding chapters provide the quality-thinking context that makes the tool work.
02
The Toyota Way — Jeffrey Liker (2004)
Book
The best book for understanding how the fishbone fits within a complete problem-solving culture. Liker documents Toyota's integration of the Ishikawa diagram with 5 Whys, genchi genbutsu, A3 thinking, and the Plan-Do-Check-Act cycle. Read this to understand why the diagram works at Toyota and fails at most companies that copy it — the difference is always the surrounding system, not the tool itself.
03
Fishbone Diagram — American Society for Quality (ASQ)
Reference guide
The most comprehensive free reference available. Covers the three main fishbone variations (dispersion analysis, process classification, cause enumeration), the 6M framework, and worked examples across manufacturing, healthcare, and services. Bookmark this as your step-by-step facilitation guide.
04
Thinking, Fast and Slow — Daniel Kahneman (2011)
Book
Not about the fishbone directly, but essential for understanding why the tool is necessary. Kahneman's work on anchoring, availability bias, and the substitution heuristic explains exactly why human intuition fails at causal diagnosis — and why a structured brainstorming process that forces breadth before depth is a genuine cognitive intervention, not just a workshop exercise.
05
Working Backwards — Colin Bryar & Bill Carr (2021)
Book
Amazon's internal problem-solving culture shares DNA with Toyota's approach. Bryar and Carr describe how Amazon uses structured root cause analysis (their "Correction of Errors" process) to diagnose operational failures — a modern, tech-company adaptation of the same diagnostic discipline that Ishikawa formalised. Read Chapter 3 for the closest analogue to fishbone thinking in a software-era context.
Decision Tools Library — Browse by phase
FramingHard Choice ModelCynefin FrameworkReversibility TestReframingAbstraction LadderingSWOT Analysis
Root Causes5 WhysIshikawa DiagramIceberg ModelPareto AnalysisIssue TreesFirst Principles
GeneratingInversionSCAMPERZwicky BoxProductive Thinking
EvaluatingDecision MatrixSix Thinking HatsCost-Benefit AnalysisDecision TreeScenario Planning
Stress-TestingPre-MortemSecond-Order ThinkingLadder of InferenceConflict Resolution
PrioritisingEisenhower MatrixImpact-Effort MatrixSpeed vs. Quality
UncertaintyOODA LoopRegret Minimisation

Why this matters next

mental modelsLeverage

Reframing applied the Leverage mental model

mental models5 Whys

Reframing applied the 5 Whys mental model

mental modelsNarrative

Reframing applied the Narrative mental model

mental modelsScale

Reframing applied the Scale mental model

mental modelsIntuition

Reframing applied the Intuition mental model

mental modelsQuality

Reframing applied the Quality mental model

Continue exploring

5W

Decision tool

5 Whys

Drill vertically into a single causal chain by asking why repeatedly until you h

IM

Decision tool

Iceberg Model

Look beneath surface events to find the patterns, structures, and mental models

PA

Decision tool

Pareto Analysis

Identify the 20% of causes responsible for 80% of the impact — know where to foc

IT

Decision tool

Issue Trees

Break a complex problem into smaller, mutually exclusive, collectively exhaustiv

FT

Decision tool

First Principles Thinking

Strip away assumptions and inherited wisdom to rebuild understanding from fundam

More like this, in your inbox

I send a newsletter every week — free, no spam, unsubscribe anytime.

Or open the full subscribe page.

On this page

  • What This Tool Does
  • How to Use It — Step by Step
  • When It Works Best
  • When It Breaks Down
  • Visual Explanation
  • Pairs With
  • Real-World Application
  • Analyst's Take
  • Top Resources