A Problem Well Stated Post 3: Building Problem Statement that Actually Work

Recap of Parts 1 & 2

As we continue this discussion of problem statements, we are going to explore the 7-Question Framework that helps collect information, what we know about the problem.

Part 1: A Problem Well Stated: An Introduction

Explored the importance of defining problems as the smartest first move.
Discussed the psychology and philosophy behind the problem-first approach.
Introduced problem statements as strategic tools.

Part 2: Why We Fail at Defining Problems

Highlighted common pitfalls in crafting problem statements.
Discussed the impact of weak problem statements on outcomes.
Shared the Gumball Theft analogy to illustrate overdoing investigations.

The Answer Begins with the Right Question.

Imagine that your team suspects that there has been a dilution misstep during standard prep. The suspicion stems by the fact that quality control (QC) checks are not passing. You can initially frame the problem by applying the matrix:

Who: Technician on prep duty
What: Reagent failed spec due to unexpected concentration
When: Occurred during Monday prep batch
Where: Workstation B, known for variable lighting
Why: Preliminary review suggests visual measurements instead of pipetting
How: Solution added manually, bypassing calibrated equipment
How Much: Concentration off by 22%, prompting retests

This transforms the vague “something went wrong” into a detailed map, improving the chances of meaningful root cause analysis. As you study the problem, you will naturally look to fill in any gaps in the matrix.

The 7-Question Matrix

You can visualize these as lenses—each one focusing attention on a different dimension of the issue. These questions help teams move from vague concerns to well-defined problems that are ready for meaningful analysis

This is certainly not a new concept. We all learned about the 5-W's in grade school English lessons. It turns out that storytelling is powerful in problem solving. Check out this article for an even deeper dive.

Problem Statement or Root Cause Analysis—Which Comes First?

This is a question I hear all the time:

“Should I start with a root cause analysis or a problem statement?”

Here’s the short answer: Start with the problem statement. Always.

A well-crafted problem statement is your investigation’s launchpad. It captures what you know right now—not what you assume, not what you’ll eventually uncover. That’s why it comes first. But here’s the nuance: it’s not static. A good problem statement is a living document. It evolves as your understanding deepens.

Jumping into root cause analysis too early is like trying to solve a puzzle without knowing what picture you’re building. You risk chasing symptoms, misallocating resources, or worse—solving the wrong problem entirely.

So instead:

Begin with metadata thinking: What do we know right now?
Let the problem statement evolve as you gather insights.
Then, when the picture is clearer, move into root cause thinking with confidence.

This approach doesn’t slow you down—it sets you up to move faster and smarter.

Metadata vs. Root Cause Thinking

At this point, it’s crucial to talk about the difference between metadata and root cause thinking.

Metadata Thinking captures surface-level signals—error codes, logs, user reports. It tells you what is happening and where.
Root Cause Thinking digs deeper to uncover why the problem exists and how to prevent it.

Why it matters:

Metadata helps triage and categorize issues quickly, but root cause thinking drives resolution and systemic improvement. Strong problem statements bridge both—using metadata for clarity and root cause thinking for depth.

Metadata thinking leads connects data with an anecdotal description of the problem.

By combining clarity, context, impact, and root cause orientation, your problem statements become powerful tools for triage, collaboration, and resolution.

Case Study - The Dilution Error