Manufacturing — torque defect
Short: Bracket loosening on Part 87-XR affects 1.8% of North America shipments (target <0.3%); $14k/month warranty.
Free tool · no signup · nothing leaves your browser
Free Problem Statement Generator
Write a clear, factual, quantified problem statement for 5 Whys, 8D, A3 or any RCA. Live validation catches blame, solutions, vague language and missing numbers. Three output formats.
128 statements writtenFor 8D D2For A3 backgroundFor full RCA
1
Answer six prompts
What, where, when, how much, target, impact. Each prompt with examples and live validation.
2
Get red-flag feedback
The tool flags blame language, solution language, vague words and missing numbers as you type.
3
Export three formats
Short for 8D D2, standard for A3 background, detailed for full RCA. Copy or PNG.
1. What is happening?
Describe the observable symptom. Facts only — no causes, no solutions, no blame. Answer: what would a third party see or measure?
Good example
Bracket on Part 87-XR is loosening in customer field returns.
Bad examples
"The operator forgot to torque" (blame). "We need to add a check" (solution). "Quality is bad" (vague).
0 / 240
2. Where does it occur?
Scope the problem. Which line, product, region, customer segment, process step, or team? Specific beats general.
Good examples
"Assembly Line 3, Station 4 torque operation." "Customer field returns — North America only, since shipment 2026-03." "Outpatient clinic billing workflow, evening shift."
0 / 240
3. When was it first observed?
Timing tells you whether the problem is new, recurring, or getting worse. Include: first observation date, frequency, and trend.
Good example
First reported March 2026. Recurring in approximately 2% of shipments. Trend: increasing month over month since April.
0 / 240
4. Current state (with numbers)
Quantify. Defect rate, cycle time, downtime minutes, complaint count, cost — whatever the metric is. A problem statement without numbers cannot be verified, which means you can never prove you solved it.
Good examples
"1.8% field return rate." "Average cycle time 58 seconds." "Medication reconciliation errors: 12 per 1,000 discharges."
0 / 240
5. Target or desired state
What does good look like? Use the contract target, the prior baseline, or the specification. The gap between current (step 4) and target (this step) is the problem you are solving.
Good examples
"Target <0.3% field return rate (customer quality agreement)." "Takt time 45 seconds." "Prior baseline Q4 2025: 2 errors per 1,000 discharges."
0 / 240
6. Why does it matter?
Cost, safety risk, customer impact, compliance exposure, schedule delay. The impact justifies why this RCA deserves priority over competing work.
Good example
"$14k per month in warranty cost. Customer has issued a SCAR that must be closed before Q3 launch. Risk of losing 40% of new-model allocation to competitor supplier."
0 / 280
Your problem statement
Three formats generated from your inputs. Pick the one that matches your downstream artefact: Short for 8D D2, Standard for A3, Detailed for full RCA report.
Generated statement
Review checks
Export & next steps
Download or copy your statement. Then pick the next step in the investigation.
Related resources
Tip — Your draft stays saved in this browser's local storage. Close the tab and return later; you'll see a "Continue where you left off" banner on the start screen.
How to write an effective problem statement
A problem statement is the fundament of every root cause analysis. Weak statement, weak investigation — every time. The six-step structure below produces statements that survive senior engineering review and give downstream tools (5 Whys, Fishbone, FMEA, 8D, A3) a clean starting point.
- Describe what is happening — factual only. What would a third party observe or measure? No causes ("because the operator forgot"), no solutions ("we need to add a check"), no blame. Just the symptom.
- Define the scope. Which line, product, region, customer segment, process step, team. "Bracket loosening" is weak; "Bracket loosening on Part 87-XR, Line 3, North America shipments since March 2026" is actionable.
- Record timing. First observation date, frequency, trend direction. Timing distinguishes a new issue from a recurring one and tells you whether the problem is accelerating.
- Quantify the current state. Defect rate, cycle time, downtime minutes, complaint count, cost per month. No numbers = no baseline = no way to prove you solved it later.
- State the target. Customer agreement, prior baseline, specification, takt time. The gap between current and target is the problem.
- Name the impact. Cost, safety, customer relationship, compliance, schedule. Impact justifies why this RCA deserves priority over competing work.
The four red flags that kill most problem statements
These patterns appear in roughly nine out of ten first-draft statements we have reviewed. The tool flags them live as you type.
- Blame language. "John forgot" or "the operator skipped the step" ends the analysis at a person. Rewrite as: the process permits a step to be missed without detection.
- Solution language. "We need to add a checklist" is a countermeasure, not a problem. Describe the failure first; the solution is discovered at D5 / the countermeasure box, not at D2 / the problem statement.
- Vague language. "Sometimes," "a lot," "issues," "quality is bad." Replace every vague word with a number or a specific observation. If you cannot quantify, go to gemba before writing more.
- No data. A statement with zero numbers cannot be verified. Without a baseline you cannot set a target, cannot prove the root cause explains the data, and cannot confirm the fix worked.
When to use this tool
The generator fits at the start of any structured investigation:
- Before a 5 Whys session — the first "why" needs a clear statement to push against.
- Writing 8D D2 — the problem-description discipline of Ford's 8D report, the single most-audited box.
- Writing A3 Background and Current Condition — Toyota's one-page canvas depends on a factual, quantified opening.
- Setting up an FMEA — item/function descriptions need the same rigour as any other problem statement.
- Customer complaint response — the SCAR response narrative starts with a problem statement the customer will accept.
Three worked examples
Software — deployment incident
Short: Checkout service p99 latency has risen from 180 ms to 520 ms since the 2026-03-14 deploy, breaching the 300 ms SLO and causing an estimated 2.1% conversion loss.
Healthcare — medication errors
Short: Medication reconciliation errors on inpatient discharge are running at 12 per 1,000 discharges vs prior-year baseline of 2 per 1,000, with two adverse events logged in Q1 2026.
Frequently asked questions
What makes a good problem statement?
A good problem statement is specific, factual, quantified and impact-oriented. It describes what is observed (not why), where and when it happens, the gap between current and target state with numbers, and why closing that gap matters. It does not blame people, propose solutions, or use vague language like "sometimes" or "a lot."
What are the common mistakes in writing problem statements?
Four patterns kill most problem statements: (1) blaming people — "the operator forgot" instead of "the process allows forgetting"; (2) solution language — "we need to add a check" instead of describing the failure; (3) vague words — "sometimes", "often", "a lot" instead of numbers; (4) no baseline data — "quality is poor" instead of "first-pass yield is 82% vs target 95%."
What format should I use — short, standard or detailed?
Short (1–2 sentences) fits the D2 box of an 8D report. Standard (4–6 sentences) fits the Background section of an A3 canvas. Detailed (paragraph with all data) fits a full RCA report or the intro of an FMEA. The tool generates all three from the same inputs so you pick based on the downstream artefact.
How does this relate to 5 Whys, Fishbone or 8D?
Every RCA method starts with a problem statement. 5 Whys uses it as the starting "why". 8D uses it as D2. A3 uses it as Background. FMEA uses it as the item/function description. Writing a strong statement up front shortcuts hours of downstream analysis. A vague problem statement dooms every RCA that follows.
Does the tool save my data?
Only in your browser's localStorage. Nothing is sent to a server, nothing is shared. Close the tab and come back later — the "Continue where you left off" banner brings back your last statement.
Why does the tool warn me about certain words?
Four patterns are flagged live as you type: blame language ("the operator", proper names), solution language ("we need to", "should", "fix"), vague language ("sometimes", "a lot", "issues"), and missing numbers in the current-state field. Each flag explains what to change. The goal is a statement that would survive a senior engineering review.