{"site":{"name":"Koji","description":"AI-native customer research platform that helps teams conduct, analyze, and synthesize customer interviews at scale.","url":"https://www.koji.so","contentTypes":["blog","documentation"],"lastUpdated":"2026-05-02T15:14:42.592Z"},"content":[{"type":"documentation","id":"0476aca3-1e55-4c9f-96f9-2298db794258","slug":"five-whys-technique-user-research","title":"The Five Whys Technique: How to Find Root Causes in User Research (with AI)","url":"https://www.koji.so/docs/five-whys-technique-user-research","summary":"The Five Whys is a root-cause analysis technique developed by Sakichi Toyoda at Toyota in the 1930s. By asking \"why\" five times in succession on a single causal thread, researchers move past surface symptoms to system-level causes. Koji's AI interviewer automates Five Whys probing across hundreds of respondents at once.","content":"\n## What Is the Five Whys Technique?\n\nThe Five Whys is a root-cause analysis technique that uncovers the underlying reason behind a problem by asking \"Why?\" five times in succession. Each answer becomes the foundation for the next \"Why?\" — peeling back layers of symptom until you reach the actual cause. In user research, it converts vague complaints (\"the dashboard is confusing\") into specific, fixable problems (\"users can't tell which metric drives their bonus, so they assume the entire dashboard is wrong\").\n\nThe technique was developed by Sakichi Toyoda in the 1930s and codified by Taiichi Ohno as a foundational element of the Toyota Production System. Originally used to debug manufacturing defects, it has since spread to incident postmortems, customer support investigations, and qualitative user research — anywhere a team needs to move past surface symptoms.\n\nThe number five is not magic. The discipline is to keep asking until you reach a cause that, if changed, would actually prevent the problem. Sometimes that takes three whys. Sometimes seven. Five is just a useful target that prevents teams from stopping at the first plausible explanation.\n\n## Why Surface Feedback Fails Product Teams\n\nMost user feedback dies on the surface. A user says \"the onboarding is too long,\" and the team adds a progress bar. A user says \"I don't trust the AI summaries,\" and the team adds a confidence score. Both responses treat the symptom and miss the actual cause — which might be that the user lost a previous account when they trusted an automated decision they didn't understand.\n\nSurface feedback fails for three reasons:\n\n1. **Users describe symptoms, not causes.** They feel the friction, not the mechanism that produces it.\n2. **First answers are socially shaped.** People give the explanation they think you want to hear.\n3. **Product teams default to action.** A reported problem becomes a Jira ticket before anyone validates the diagnosis.\n\nThe Five Whys disrupts all three failure modes. By insisting on five layers of causation, it forces both interviewer and respondent past the first plausible-sounding answer.\n\n## The Classic Five Whys Example\n\nToyota's canonical example involves a stopped welding robot:\n\n1. **Why did the robot stop?** Its circuit overloaded, blowing a fuse.\n2. **Why did the circuit overload?** There was insufficient lubrication on the bearings, so they locked up.\n3. **Why was there insufficient lubrication?** The lubrication pump was not circulating enough oil.\n4. **Why was the pump not circulating enough oil?** The pump intake was clogged with metal shavings.\n5. **Why was the intake clogged?** There is no filter on the pump.\n\nNote where the chain ends: at a missing filter. That is something you can fix. \"Replace the fuse\" — the symptom — would have left the actual problem in place.\n\nThe same shape works for product research. A user says onboarding is confusing. Five whys later, you discover their company uses a single-sign-on provider that doesn't pass through the user's role, so every new account starts in a permission-stripped state, so every welcome screen looks broken. That is something engineering can fix.\n\n## How to Apply Five Whys in Customer Interviews\n\nRunning Five Whys in a live interview takes practice. The technique looks simple on paper but requires three habits most interviewers don't have:\n\n**1. Stay on a single thread.** Each \"why\" must build on the previous answer, not branch into a new topic. If the respondent jumps, gently bring them back: \"Hold that thought — going back to what you said about the export failing, why was that important?\"\n\n**2. Avoid blame-loaded \"whys.\"** \"Why did you do that?\" sounds accusatory. Reframe as: \"What was happening when you decided to do that?\" or \"Walk me through what was on your mind.\" The \"why\" lives inside the question's purpose, not its literal phrasing.\n\n**3. Stop when you hit a system, not a person.** A bad chain ends at \"because the user wasn't paying attention.\" A good chain ends at \"because the email subject line was indistinguishable from spam.\" The first blames a person; the second points at a system you can change.\n\n## Five Whys with Koji's AI Interviewer\n\nTraditional Five Whys requires a skilled human moderator who can listen, hold context across multiple turns, and gently keep the respondent on a single causal thread. That skill is rare and expensive — which is why most teams collect surface-level feedback and never reach the root cause.\n\nKoji's AI interviewer runs Five Whys by default. When you set a question's `maxFollowUps` to 2 or 3 in Koji's structured question framework, the AI:\n\n- Detects vague answers (\"it was confusing\", \"it didn't work well\") and probes for specificity\n- Holds the original question as the anchor across multiple follow-up turns\n- Asks neutral, blame-free \"what was happening\" style probes instead of accusatory \"why did you\" phrasing\n- Stops probing when the respondent reaches a concrete, system-level cause — preventing the over-probing that exhausts participants\n\nBecause the AI runs in parallel across many interviews, you get root-cause depth at survey scale — something a human-moderated study could never reach without weeks of work. Compared to traditional tools like SurveyMonkey or Typeform that capture a single answer and stop, Koji's AI keeps probing until the cause is actionable.\n\n## Five Whys vs. Other Root-Cause Techniques\n\nThe Five Whys is one of several root-cause methods. Each fits a different situation:\n\n| Technique | Best For | Output | Effort |\n|-----------|----------|--------|--------|\n| Five Whys | Linear, single-cause problems | Causal chain | Low |\n| Fishbone (Ishikawa) | Multi-cause problems with several contributing factors | Categorized cause map | Medium |\n| Fault Tree Analysis | Safety-critical, low-frequency failures | Probabilistic failure tree | High |\n| Critical Incident Technique | Specific past events with rich context | Categorized incident bank | Medium |\n| Pareto Analysis | Many problems, need to prioritize the vital few | Frequency ranking | Low |\n\nFor most user research, Five Whys is the right starting point. Move to Fishbone only when you discover that a problem has multiple parallel causes that don't reduce to a single root.\n\n## Common Five Whys Mistakes\n\nTeams that try Five Whys without practice tend to make the same mistakes:\n\n**Stopping too early.** \"It crashed because the API timed out\" sounds like an answer but it is still a symptom. Why did the API time out? Why was the request that slow? Most chains require six or seven whys to reach an actual root.\n\n**Branching the chain.** Each \"why\" must follow from the previous answer, not from your own theory. If you skip ahead, you confirm your bias instead of finding the real cause.\n\n**Interviewing without context.** Five Whys works best when the respondent recently experienced the problem. Memory fades fast — try to interview within 48 hours of the incident.\n\n**Treating opinion as cause.** \"Why is engagement low?\" \"Because users don't see the value.\" That is an opinion, not a root cause. Reframe: \"Walk me through the last time you opened the product and didn't take any action — what was on your mind?\"\n\n## A Five Whys Interview Template for Koji\n\nHere is a battle-tested structure you can drop into a Koji study:\n\n**Anchor question (open_ended):** \"Tell me about a specific recent moment when you felt frustrated using [product].\"\n*AI probing:* maxFollowUps = 3. Probe for specifics. After each answer, ask why that mattered or why it happened. Stop when the respondent describes a concrete system or process cause.\n\n**Severity check (scale, 1–10):** \"How much did that moment affect your decision to keep using [product]?\"\n*AI probing:* maxFollowUps = 1, anchor = true.\n\n**Counterfactual (open_ended):** \"What would have prevented that moment from happening?\"\n*AI probing:* maxFollowUps = 1.\n\n**Pattern check (yes_no):** \"Has something similar happened more than once?\"\n*If yes, AI probes:* \"Tell me about the most recent time.\"\n\nThis four-question structure runs in 8–12 minutes per respondent. Across 30 respondents, Koji's analysis automatically clusters the root causes by frequency, giving you a Pareto-ranked list of system-level fixes — something traditional research tools simply can't produce without weeks of manual coding.\n\n## When Not to Use Five Whys\n\nFive Whys is powerful but it has limits:\n\n- **Statistical questions** (\"how many users churn?\") need quantitative methods, not causal probing.\n- **Aspirational research** (\"what features do users wish existed?\") is better served by generative discovery interviews.\n- **Multi-causal failures** with several parallel contributing factors usually need a Fishbone diagram.\n- **Sensitive incidents** where the respondent may be embarrassed or defensive require trust-building first; aggressive probing will shut them down.\n\nFor everything else — onboarding friction, churn drivers, feature-adoption stalls, support escalations — Five Whys is the highest-leverage interview technique you can learn.\n\n## Getting Started in Koji\n\n1. Create a new study and add your anchor question as `open_ended` with `maxFollowUps: 3`\n2. Set probing instructions: \"Keep asking why or what was happening until you reach a concrete cause\"\n3. Add the severity, counterfactual, and pattern questions from the template above\n4. Send to 30+ respondents who recently experienced the problem\n5. Open the auto-generated report to see causes clustered by frequency\n\nThe whole study runs end-to-end in a single afternoon — including analysis. No moderator hours, no transcript coding, no spreadsheet wrangling.\n\n## Related Resources\n\n- [How to Conduct User Interviews](/docs/how-to-conduct-user-interviews) — foundational interview skills the Five Whys builds on\n- [Critical Incident Technique](/docs/critical-incident-technique) — pair with Five Whys to investigate specific past events\n- [Avoiding Bias in Interviews](/docs/avoiding-bias-in-interviews) — keep the Five Whys chain neutral and non-leading\n- [Thematic Analysis Guide](/docs/thematic-analysis-guide) — cluster Five Whys root causes across many respondents\n- [Structured Questions Guide](/docs/structured-questions-guide) — combine open-ended Five Whys probes with quantitative scales\n- [Mom Test Customer Interviews](/docs/mom-test-user-interviews) — bias-free interview discipline that pairs with Five Whys probing\n","category":"Interview Techniques","lastModified":"2026-05-01T03:27:18.415065+00:00","metaTitle":"Five Whys Technique for User Research: Find Root Causes with AI","metaDescription":"Use the Five Whys technique to uncover root causes behind user complaints. Step-by-step playbook plus a Koji AI template for running Five Whys interviews at scale.","keywords":["five whys","five whys technique","root cause analysis","user research methods","interview probing","toyota five whys","5 whys","sakichi toyoda","qualitative root cause","user interview techniques"],"aiSummary":"The Five Whys is a root-cause analysis technique developed by Sakichi Toyoda at Toyota in the 1930s. By asking \"why\" five times in succession on a single causal thread, researchers move past surface symptoms to system-level causes. Koji's AI interviewer automates Five Whys probing across hundreds of respondents at once.","aiPrerequisites":["Basic user interview skills","Familiarity with qualitative research"],"aiLearningOutcomes":["Apply the Five Whys technique to user research interviews","Stay on a single causal thread without branching","Use blame-free probing language","Run Five Whys at scale with Koji's AI interviewer","Combine Five Whys with structured questions for quantitative anchors"],"aiDifficulty":"beginner","aiEstimatedTime":"11 min read"}],"pagination":{"total":1,"returned":1,"offset":0}}