128 statements written

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. No signup.

✓ For 8D D2 ✓ For A3 background ✓ For full RCA

📅 You have a draft saved. Continue where you left off?

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.

What's next?

🎯

Run a 5 Whys

Use this statement as your starting point and drill to the systemic root cause.
📊

Map causes in a Fishbone

Brainstorm candidate causes across 6M categories before picking the vital branch.
⚠

Score risks in FMEA

Quantify failure modes with Severity × Occurrence × Detection (RPN) scoring.
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 was the generator?
★ ★ ★ ★ ★
Helps others find it

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. State the target. Customer agreement, prior baseline, specification, takt time. The gap between current and target is the problem.
  6. 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.

When to use this tool

The generator fits at the start of any structured investigation:

Three worked examples

Manufacturing — torque defect

Short: Bracket loosening on Part 87-XR affects 1.8% of North America shipments (target <0.3%); $14k/month warranty.

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.

How to Write a Problem Statement (Complete Guide) Step-by-step formula, good vs bad examples, worked 5 Whys cases, a checklist. 8D Problem Solving Guide (D2 deep-dive) The customer-facing discipline that depends on a rock-solid problem statement. A3 Problem Solving Guide (Background section) Toyota's one-page canvas and the standard-format statement that opens it. 5 Whys Tool Use your new statement as the starting "why" and drill to the systemic root. FMEA Calculator Quantify risks on the problem you just defined with RPN scoring. Root Cause Analysis: Complete Guide The end-to-end RCA playbook that wraps this entire toolkit.
Quick feedback

What’s on your mind?

Pick one — takes under 30 seconds. Your message goes straight to the operator’s inbox.
🍪 Why cookies?

Why #1: Because they help us see how people use this tool.

Why #2: So we can make it better for you.

Why #3: And keep it completely free — ads help cover the costs.

No creepy tracking. Just analytics & ads. Learn more