Most continuous improvement projects fail before they even begin. Why? Because the team starts with a vague frustration instead of a defined problem. Statements like “Production is bad” or “We have too much downtime” are impossible to solve because they don’t give you a target.
A good problem statement creates extreme focus. It forces alignment among your team and sets the foundation for accurate Root Cause Analysis. In this guide, we will show you exactly how to rewrite vague complaints into bulletproof problem statements using the 5W1H method and real-world manufacturing examples.
What is a Problem Statement?
A problem statement is a clear, concise description of an issue that needs to be addressed. It does not explain why the problem is happening, and it definitely does not offer a solution. It simply states the facts.
A strong statement always contains five key components. Click the labels below to see how they map to a real sentence:
Common Mistakes
Before you write your own, you must unlearn bad habits. Click the cards below to reveal why these common statements are actively hurting your team’s ability to solve problems.
“Operators need more training.”
Click to reveal why this is bad
The Mistake: Jumping to Solutions
This implies you already know the root cause (lack of training) and the solution. What if the machine is just broken? Never include the solution in the statement.
“The machine is unreliable.”
Click to reveal why this is bad
The Mistake: Too Vague & Unmeasurable
“Unreliable” is an opinion, not a fact. How many times did it break? How much time was lost? If you can’t measure it, you can’t improve it.
The Simplest Structure: 5W1H Builder
The easiest way to guarantee a perfect problem statement is to answer the 5 Ws and 1 H. Use the live generator below to see how answering these basic questions automatically builds a professional, Lean-ready problem statement.
Interactive Rewrite Workshop
Watch how a terrible problem statement evolves into a world-class one by systematically applying the rules we just learned. Click the steps in order.
Examples by Process Type
While the structure remains the same, the data you focus on changes depending on whether you are looking at quality, maintenance, or logistics. Click through the tabs below for specific examples.
The Final Validation Test
Before you present your problem statement to management or launch a DMAIC project, put it through this final pass/fail checklist. If you answer “No” to any of these, rewrite it.
- Can I measure it? (Is there a baseline number and a current number?)
- Is it free from blame? (Does it focus on the process instead of “lazy operators”?)
- Is it solution-free? (Does it strictly avoid words like “need,” “lack of,” or “require”?)
- Is the impact clear? (Does management immediately understand why this costs the business money?)
Frequently Asked Questions
What is a good problem statement?
A good problem statement is a concise, factual, and measurable description of an issue. It explains what is happening, where, when, how big the issue is, and why it matters to the business—without blaming people or suggesting a solution.
Should a problem statement include the solution?
Never. Including a solution in the problem statement creates a cognitive bias. It prevents your team from investigating the true root cause because they are already focused on implementing the predetermined “fix.”
How long should a problem statement be?
Ideally, it should be 1 to 3 sentences. If it takes a whole paragraph to explain, the problem is likely too broad and needs to be broken down into smaller, more manageable sub-problems.
What is the difference between a problem statement and a root cause?
The problem statement describes the symptom (what you see and measure). The root cause is the underlying system failure that created the symptom. You write the problem statement on Day 1; you don’t find the root cause until the end of your analysis.
