Fishbone Diagram Example: How to Find a Root Cause

A coffee shop I worked with kept getting the same complaint: drinks coming out lukewarm. The manager's first instinct was the obvious one — "the baristas are slow." So she added a stopwatch culture, posted speed targets, and the complaints kept coming. Three weeks of pressure, zero improvement. The problem wasn't speed at all. It was a steamer that had drifted out of calibration and a milk fridge set two degrees too cold.

That gap — between the cause you assume and the cause that's actually there — is exactly what a fishbone diagram is built to close. So instead of defining it to death, let me just walk you through one.

What a fishbone diagram example actually shows

A fishbone diagram (also called an Ishikawa diagram, after the Japanese quality expert who popularized it, or a cause-and-effect diagram) puts one problem at the "head" of a fish and branches every possible cause off the spine like ribs. You're not mapping a process and you're not charting numbers — you're spreading out the suspects for a single bad outcome so you can investigate them one by one instead of fixating on the first guess.

The shape matters. The horizontal spine points at the problem. Big diagonal bones come off it, each labeled with a category of cause. Smaller bones branch off those with specific causes, and you keep asking "why does that happen?" to grow sub-bones deeper.

Most people start with the classic manufacturing categories, the 6 Ms:

• Machine — equipment, tools, software
• Method — the process or procedure being followed
• Material — inputs, ingredients, raw supplies
• Manpower (people) — skills, training, staffing
• Measurement — how you're inspecting or measuring
• Environment (the "mother nature" M) — temperature, space, lighting, anything ambient

You don't have to use those exact six. A software team might swap in Code, Data, Infrastructure, Process, People, External. A marketing team might use Audience, Channel, Message, Timing, Budget. The categories are scaffolding — their job is to stop you from dumping every idea in one pile and to force you to look in corners you'd otherwise skip.

The worked example: lukewarm coffee

Here's the actual fishbone we built for the coffee shop. The head — the problem statement — was deliberately specific: "Espresso drinks served below 60°C." Not "bad coffee." A vague head gives you a vague diagram.

Then we filled in bones by category:

Machine

• Steam wand pressure low
• Espresso machine not reaching set temp
• Group head not pre-heated

Method

• Milk steamed too early, sits before pour
• No standard target temperature taught
• Cups not pre-warmed

Material

• Milk stored too cold (fridge at 2°C instead of 4°C)
• Thin paper cups lose heat fast

Manpower

• New hires never trained on milk temperature
• Rush-hour multitasking — drinks queue before pickup

Measurement

• Nobody actually measures serving temperature
• "Hot enough" judged by hand on the cup

Environment

• Pickup counter sits under the AC vent
• Winter — ambient room temp dropped

Look at what that surfaced. The manager's original theory — slow baristas — shows up as exactly one sub-bone under Manpower. The diagram quietly demoted her assumption to one suspect among fifteen. And it exposed two causes nobody had said out loud: the fridge running cold (Material) and the pickup counter sitting directly under an AC vent (Environment).

That's the whole point. A fishbone doesn't solve the problem — it makes sure you're not solving the wrong one.

Turning the diagram into an answer

A wall of fifteen possible causes isn't an action plan. The diagram is step one; here's how you get from it to a fix.

Drill with "why." Take a promising bone and keep asking why. "Milk stored too cold" → why? → "Fridge set to 2°C" → why? → "Thermostat bumped during a clean and never reset." Now you've got something you can actually fix, and you've quietly run a mini "five whys" inside one rib of the fish.

Vote, don't guess. Have the people closest to the problem mark the two or three bones they think are most likely and easiest to test. You're looking for high-likelihood, low-effort causes to check first.

Test cheaply before you commit. Our top suspects were the fridge temp and the lack of any measurement at all. Both were a five-minute check, not a renovation. We put a thermometer in a finished drink (Measurement), found 54°C, then nudged the fridge to 4°C and pre-warmed cups. The complaints dropped to near zero within a week.

Notice we never had to "fix the baristas." The cause-and-effect map saved three weeks of pointing at the wrong rib.

The mistakes that make a fishbone useless

I've seen plenty of fishbone diagrams that were pure theater, and they usually fail the same handful of ways.

A fuzzy head. "Sales are down" or "the app is bad" gives you a fish with no focus. Make the problem statement measurable and specific — "checkout conversion dropped 12% on mobile in March." The sharper the head, the sharper the bones.

Confusing causes with symptoms. "Customers are unhappy" isn't a cause, it's the effect restated. Keep asking "why" until you hit something you could actually change.

Stopping at the first level. A bone that just says "poor training" is a category, not a cause. Push it: poor training how? Missing onboarding doc? No one assigned to teach it? The fix lives two or three levels down the bone, not at the top.

Categories as decoration. If every cause lands under "Method" and the other five bones are empty, you're not using the categories to explore — you're confirming what you already believed. Force at least one candidate into each category before you stop.

Treating it like a chart. A fishbone shows possible causes, not proven ones or quantities. It's a thinking tool, not evidence. When the question is "which of these is biggest," you've moved on to a different job — that's where picking the right chart earns its keep.

Build one without drawing it by hand

The slow part of a fishbone isn't the thinking — it's redrawing the bones every time someone adds a cause and the layout breaks. That's the kind of grunt work worth handing off.

In Ridvay you can describe the problem and your suspected causes in plain language, and it lays out the spine, the category bones, and the sub-bones for you — already structured, ready to drag and edit. You spend your time investigating causes instead of nudging arrows. If you've ever turned a messy flowchart into something readable, it's the same idea applied to cause-and-effect.

Try it with the coffee example baked in, then swap in your own problem:

Generate a fishbone diagram from your problem →

Whatever keeps going wrong on repeat — a bug that won't stay fixed, a metric that keeps slipping — start by spreading out the suspects. The cause you finally fix is rarely the one you'd have blamed on day one.