Brand
Get all logo versions.
Download 
A root cause analysis (RCA) digs past a problem's first apparent cause to the condition that actually produced it, the way a doctor treats the illness rather than the fever. This template shows one worked end to end: a bad espresso traced through three symptom branches, off taste, low pressure, no crema, that all converge on one root cause, a grinder nobody maintained. Run the same structure on your outages, defects, and recurring failures.
Troubleshooting gets things working again; root cause analysis stops them from breaking the same way. Troubleshooting is fast, experience-driven, and stops at the first fix that holds: restart the service, replace the part. RCA is slower and systematic: it maps the causal chain past the immediate trigger to the condition that allowed it. You usually need both, in order. Troubleshoot to recover, then run the RCA before the lesson evaporates.
A root cause analysis (RCA) is a systematic process for finding the underlying cause of a problem instead of patching its symptoms, so the fix prevents recurrence rather than postponing it. It's standard practice after incidents, defects, and recurring process failures. RCA is the methodology; techniques like the 5 whys, fishbone diagrams, fault tree analysis, and Pareto charts are the tools used inside it.
The board on this page is one: a cafe's espresso turns bad. Three symptoms get their own branches: the taste is off (sour or bitter shots), extraction pressure is low (shots pull too fast), and no crema forms (weak, watery body). Drilling each branch, the same culprit keeps appearing: inconsistent grind from a grinder nobody maintained or calibrated. Fix the cleaning schedule, and all three symptoms go with it.
Often, and sometimes the opposite happens: several problems share one. Complex failures usually have contributing causes across process, tooling, and environment, which is why branching beats a single chain. But watch for convergence, like this template's espresso example, where three separate symptoms all trace to one unmaintained grinder. When independent branches keep landing on the same node, you've found the fix with the highest payoff.
Root cause analysis is the umbrella process; the 5 whys and the fishbone diagram are techniques inside it. The 5 whys drills one cause chain by asking why repeatedly, which suits simple, linear problems. The fishbone spreads causes across categories, which suits messy multi-causal ones. This mind-map template sits between them: it branches like a fishbone but drills like the 5 whys.
A symptom is what you observe: the error rate spiked, the part failed, the customer churned. A root cause is the condition that produced it, usually two or three whys deeper: the missing monitor, the worn process, the unowned handoff. The test: if you fix it and the problem can still come back the same way, you fixed a symptom. The smoke-versus-fuel distinction is the whole discipline.