A problem statement is "step zero" of every root cause analysis. Before you ask a single "Why?", you need a clear, shared description of the problem you are investigating. It sounds obvious, yet most failed root cause analysis sessions fail for exactly this reason: the problem was poorly defined. A vague starting point produces vague conclusions and corrective actions that fix nothing. This guide gives you a repeatable formula for writing problem statements that make your 5 Whys analysis sharper, faster, and more effective. You can practice immediately using our free online 5 Whys tool.

What is a problem statement?

A problem statement is a concise, factual description of an undesirable event or condition. It tells the team exactly what happened, when it happened, where it happened, and how much impact it had. It does not explain why it happened — that is the job of the root cause analysis itself.

Think of the problem statement as the destination marker on a map. Without it, your analysis wanders. With it, every "Why?" question drives the team closer to the true root cause. In quality management and lean manufacturing, the problem statement is sometimes called the "problem description" or the "event statement," but the purpose is always the same: to give the investigation a precise, agreed-upon starting point.

A strong problem statement does three things for your RCA:

The anatomy of a good problem statement

Every effective problem statement answers four questions and explicitly excludes three things. Here is the formula:

What to include

  1. What happened? — The event, symptom, or deviation. Describe the observable facts. "API returned 500 errors." "12 units failed the pressure test." "Customer received the wrong shipment."
  2. When did it happen? — The date, time, shift, sprint, or frequency. "On March 5 between 2:00 PM and 2:47 PM." "During every night shift in the past two weeks." "Three times in the last sprint."
  3. Where did it happen? — The location, system, process step, production line, department, or geographic region. "On the checkout microservice in production." "On Assembly Line 3." "At the Atlanta distribution center."
  4. What is the impact? — The cost, downtime, safety consequence, customer impact, or regulatory exposure. "Blocked 2,300 customer transactions." "Caused $18,000 in lost revenue." "Resulted in 2 recordable safety incidents."

What to exclude

Quick test: Read your problem statement out loud. If a team member who was not present during the event can understand exactly what happened without asking follow-up questions, your statement is good. If they ask "What do you mean by that?" or "So what caused it?" — revise.

Good vs. bad problem statements

The difference between a useful and a useless problem statement is almost always specificity. Below are five pairs of examples from different industries. Notice how the good versions follow the four-question formula while the bad versions are vague, include causes, or embed blame.

Bad statement Good statement
Manufacturing
"Quality is bad on the night shift." "12 units failed the pressure test on Assembly Line 3 during the night shift on March 10, resulting in $4,800 of scrapped material."
Software / IT
"The website keeps going down because of bad code." "The checkout API returned HTTP 500 errors for 47 minutes on March 5 (2:00–2:47 PM EST), blocking 2,300 transactions and causing an estimated $18,000 in lost revenue."
Healthcare
"Medication errors are happening too often." "A patient on Ward 4B received 200 mg of ibuprofen instead of the prescribed 400 mg at 6:00 AM on March 8. No adverse outcome occurred, but the deviation was classified as a near-miss event."
Customer Service
"Customers are unhappy because the team is slow." "Average first-response time for Tier 1 support tickets increased from 2.1 hours to 6.8 hours between March 1 and March 14, resulting in a CSAT drop from 87% to 71% and 14 customer escalations."
Human Resources
"People keep leaving because management is bad." "7 engineers in the Platform team (out of 18) resigned between January and March 2026, compared to an average of 1 resignation per quarter over the previous year. Exit interviews cite workload as the top concern."

Every bad statement in the table above suffers from at least one of the same problems: it is vague ("quality is bad"), it includes a cause ("because of bad code"), or it assigns blame ("management is bad"). The good statements are factual, specific, and neutral. They give a team everything it needs to start a 5 Whys analysis without biasing the outcome.

Step-by-step guide to writing a problem statement

Follow these six steps before your next root cause analysis session. The entire process takes 10 to 15 minutes — a small investment that dramatically improves the quality of your investigation.

Step 1: Gather facts

Before you write anything, collect the raw data. Pull logs, review tickets, talk to the people closest to the event, and look at timestamps. You need facts, not opinions. If someone says "it happened around lunchtime," pin it down: was it 11:45 AM or 1:15 PM? Precision matters because each detail narrows the scope of the investigation.

Step 2: Quantify the impact

Put numbers on the consequences. How many customers were affected? How many units were scrapped? How many minutes of downtime? What is the dollar estimate? Quantifying the impact serves two purposes: it makes the problem statement concrete, and it helps the organization prioritize which problems to investigate first. A problem that cost $500 and a problem that cost $50,000 deserve different levels of attention.

Step 3: Define the scope

Draw a boundary around the problem. Is this about a single incident or a recurring pattern? Does it affect one production line or all of them? One customer segment or all segments? Scope prevents the analysis from expanding into territory that is not relevant. A well-scoped problem statement keeps the 5 Whys chain focused and manageable. If you are unsure about scoping, our guide on common 5 Whys mistakes covers the risks of going too broad.

Step 4: Write the first draft

Combine your facts into one to three sentences using the formula: What + When + Where + Impact. Do not worry about perfect phrasing on the first attempt. Just get the key elements on paper. Then review it against the exclusion rules: does it contain a cause, blame, or a solution? If yes, remove those elements.

Step 5: Test with the "So what?" method

Read the statement and ask yourself: "So what? Why does this matter?" If the answer is obvious from the statement itself — because the impact is clearly stated — the statement is strong. If you find yourself needing to add context for someone to understand why this is important, the impact section needs work. The "So what?" test also catches statements that are too narrow or trivial to warrant a full root cause investigation.

Step 6: Get team agreement

Share the draft with the people who will participate in the analysis. Ask: "Is this an accurate description of the problem? Is anything missing or incorrect?" This step is critical because it builds shared ownership. If the team does not agree on the problem statement, they will not agree on the root cause either. A skilled facilitator makes this alignment step fast and productive.

Worked example 1: Software incident (API outage)

Initial (bad) problem statement
"The checkout API went down and we lost money."

This statement is vague. It does not say when, for how long, how many customers were affected, or how much money was lost. It also uses "went down," which could mean anything from a full outage to intermittent slowness.

Improved problem statement
"On March 5 at 2:00 PM EST, the checkout API began returning HTTP 500 errors. The issue lasted 47 minutes (until 2:47 PM). During this window, 2,300 checkout attempts failed, and an estimated $18,000 in revenue was lost. No data was corrupted."

Now the team has a precise starting point. Here is the 5 Whys analysis built on this statement:

Why #1 Why did the checkout API return 500 errors? — The API server ran out of available database connections.
Why #2 Why did it run out of database connections? — A long-running query held connections open for 8+ minutes each, exhausting the connection pool.
Why #3 Why was a long-running query executing in production? — A new reporting feature was deployed that morning. It runs an unoptimized aggregation query against the production database.
Why #4 Why was the query unoptimized? — The reporting feature was not load-tested before deployment. The query worked fine in the staging environment with 500 records but failed with 2.4 million production records.
Root Cause Why was the feature not load-tested? — The deployment checklist does not include a load-testing step for features that introduce new database queries.
Corrective action: Add a mandatory load-testing gate to the deployment checklist for any feature that introduces or modifies database queries. The test must run against a production-scale dataset. Owner: Engineering Lead. Deadline: March 19.

Worked example 2: Manufacturing defect

Initial (bad) problem statement
"The night shift keeps making defective parts because the operator is not paying attention."

This statement includes both a cause ("not paying attention") and blame (the operator). It makes a real investigation impossible because the conclusion is already embedded in the starting point.

Improved problem statement
"On March 10 during the night shift (10:00 PM – 6:00 AM), 12 out of 300 units produced on Assembly Line 3 failed the final pressure test. The defect rate was 4%, compared to the standard tolerance of 0.5%. Scrapped material cost $4,800."

This version is factual and specific. It lets the team investigate without assumptions:

Why #1 Why did 12 units fail the pressure test? — The seal on each unit was misaligned by 1.2 mm, causing a leak under pressure.
Why #2 Why was the seal misaligned? — The seal-insertion jig on Line 3 had shifted out of calibration.
Why #3 Why was the jig out of calibration? — The jig was last calibrated 6 weeks ago. The calibration schedule calls for every 2 weeks.
Why #4 Why was the calibration overdue? — The maintenance management system does not generate automatic alerts when a calibration is approaching its due date.
Root Cause Why are there no automatic calibration alerts? — When the new maintenance system was deployed, the alert configuration was not migrated from the old system. No one verified the migration was complete.
Corrective action: (1) Immediately calibrate the Line 3 jig. (2) Audit all calibration schedules in the new maintenance system against the old system and configure missing alerts. (3) Add a migration-verification step to the IT deployment procedure for maintenance system changes. Owner: Maintenance Manager + IT Lead. Deadline: March 17.

Notice how different the investigation looks compared to the original bad statement. Instead of blaming the operator, the team discovered a system migration gap that affected the entire maintenance schedule. The corrective action is structural and prevents recurrence — not just on Line 3, but across all lines.

Common problem statement mistakes

Even teams that understand the formula still fall into these four traps. Watch for them every time you draft a problem statement.

Mistake 1: Too vague

Vague statements sound like headlines: "Quality is declining." "The system is slow." "Customers are unhappy." They give the team nothing to investigate because there is no specific event to trace backward. The 5 Whys chain built on a vague statement will be equally vague, and the corrective action will be some variation of "try harder" or "be more careful."

Fix: Add numbers, dates, and locations. Transform "the system is slow" into "The order processing system averaged 12-second response times between March 1 and March 7, compared to the 2-second SLA, affecting 850 orders per day."

Mistake 2: Contains the cause

This is the most dangerous mistake because it looks harmless. "The server crashed because of a memory leak" seems like a helpful, detailed statement. But it pre-loads the investigation with a conclusion. The team will spend the entire session confirming the memory leak theory instead of exploring other possibilities. What if the crash was caused by a disk-full condition, and the memory usage was coincidental?

Fix: Remove everything after "because." The problem statement is "The server crashed at 2:14 AM on March 12, causing 35 minutes of downtime for 4,000 users." The cause is what the 5 Whys will discover.

Mistake 3: Contains the solution

Some statements skip straight to prescribing a fix: "We need more training on the new system." This is not a problem statement — it is an action item disguised as a diagnosis. It assumes the root cause is a knowledge gap without any investigation. Maybe the real issue is that the system has a confusing interface, or that the process documentation is outdated.

Fix: Describe the observable outcome, not the remedy. "15 data-entry errors were recorded in the new CRM system during the first two weeks of deployment, affecting 15 customer accounts." Now the team can investigate whether the cause is training, UX design, documentation, or something else entirely.

Mistake 4: Too broad in scope

An overly broad statement tries to cover everything at once: "Our product delivery process has multiple inefficiencies causing delays and customer complaints." This is not one problem — it is an entire program of work. A 5 Whys session cannot investigate "multiple inefficiencies" simultaneously. The team will either get lost or default to the loudest person's pet theory. For more on this trap, see our guide to common 5 Whys mistakes.

Fix: Narrow to a single, specific event. "Order #4821 was delivered 5 days late to Client X on March 9, breaching the SLA and triggering a $2,000 penalty clause." You can always run separate analyses for separate problems.

Problem statement checklist

Use this checklist before starting any root cause analysis session. If every item passes, your problem statement is ready. If any item fails, revise the statement before proceeding.

Pre-analysis problem statement checklist

Start Your 5 Whys Analysis

Write your problem statement, then let our free guided tool walk you through each "Why?" step by step. No signup required.

Start Free Analysis →

Frequently asked questions

What makes a good problem statement for RCA?

A good problem statement for root cause analysis is specific, measurable, and free of causes or solutions. It answers four questions: What happened? When did it happen? Where did it happen? What is the impact? It should be one to three sentences long, written in neutral language, and agreed upon by the team before the analysis begins.

How long should a problem statement be?

One to three sentences. It needs to be detailed enough to give the team a shared understanding of what happened, but concise enough to fit on a whiteboard or at the top of an analysis document. If your problem statement is longer than three sentences, you are probably including causes, context, or solutions that do not belong there.

Should a problem statement include the cause?

No. Including a cause in the problem statement biases the entire analysis toward confirming that cause instead of discovering the true root cause. Remove all causal language ("because," "due to," "caused by") from the statement. The cause is what the 5 Whys investigation will reveal.

Can you change the problem statement during a 5 Whys session?

Yes, and sometimes you should. As the team investigates, new facts may emerge that make the original statement too broad, too narrow, or slightly inaccurate. It is better to refine the problem statement mid-session than to continue analyzing the wrong problem. Make sure the team agrees on the revised statement before continuing.

What is the difference between a problem statement and a hypothesis?

A problem statement describes what happened and its impact — it is a factual observation. A hypothesis is a proposed explanation for why it happened. In a 5 Whys analysis, the problem statement comes first and stays fixed. The hypotheses are the answers to each "Why?" question. Mixing the two leads to biased analysis because the team investigates a suspected cause instead of the actual problem.

📚 Recommended Reading

Browse all recommended books →

Related resources