An AI generated image of a laboratory with a Question Mark in the center fashioned with laboratory glassware.

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

Table of Contents

Recap of Posts 1 and 2

Post 1: A Problem Well Stated—The Bridge to Better Outcomes

  • 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.

Post 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.

Introduction

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.

A matrix outlining the 7-question matrix: Who; What; When; Where; Why; How; and How much

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

What's the difference?

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

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. 

Be Hard on the Process, Not the Person

To help teams quickly capture metadata during triage and build stronger problem statements, we’ve created a downloadable 7-Questions Matrix Worksheet. This visual tool guides users through the key elements of effective problem framing—bridging metadata signals with root cause thinking.

Use it during triage sessions to:
– Organize contextual signals (metadata)
– Prompt deeper inquiry into underlying causes
– Align teams around actionable problem statements

Leave a Reply

Your email address will not be published. Required fields are marked *

JOIN OUR NEWSLETTER
And get notified everytime we publish a new blog post.