Skip to content

Problem Exploration

What problem are we actually trying to solve?

Series identity. Learn in cycles. Move in a line. The product keeps moving forward, while understanding improves through repeated PDSA learning loops.

Use this guide to: keep the team from accepting the first problem statement too quickly.

PDSA emphasis: Plan through systems understanding and problem framing.

Purpose

Problem exploration builds a usable picture of the current system: who is involved, what they are trying to accomplish, what happens today, where friction appears, and why it matters. The goal is not perfect certainty. The goal is a problem frame strong enough to guide a small useful test.

When To Use It

  • When a request arrives as a solution: add this button, build this workflow, automate this step.
  • When multiple stakeholders describe the same situation differently.
  • When the team's last solution did not change the outcome.

Core Questions

  • Who experiences the problem, and who absorbs its consequences?
  • What happens today, step by step?
  • Where does the current system produce delay, rework, risk, or confusion?
  • What evidence shows this problem matters?
  • What might be a symptom rather than a cause?

Facilitation Pattern

  1. Invite people close to the work, not only decision-makers.
  2. Map the current flow in plain language.
  3. Mark evidence separately from interpretation.
  4. Ask where variation appears: common pattern or special incident?
  5. End with a refined problem statement and remaining unknowns.

Working Example

Support wants a dashboard because escalations feel chaotic. Exploration shows the bigger problem is not visibility alone: escalation rules differ by region, definitions of severity vary, and agents cannot tell when ownership transfers. The first useful problem frame becomes: agents lack a shared escalation system, not merely a better dashboard.

Common Traps

  • Treating the requested feature as the problem.
  • Mapping only the happy path.
  • Confusing anecdotes with evidence or dismissing anecdotes because they are not metrics.
  • Ignoring downstream operators who live with the result.

Outputs And Artifacts

  • Current-system map.
  • Actors and affected parties.
  • Problem statement with evidence.
  • Causes, symptoms, and open questions.
  • Candidate measures for Study.

PDSA Linkage

Problem exploration strengthens Plan by making the theory visible. Shewhart and Deming both push the team toward understanding variation in a process before acting as though a single fix explains the system.

Working Worksheet

  • Write the problem without naming a solution.
  • Identify the people who experience and operate the current system.
  • Mark facts, interpretations, and guesses.
  • Look for common-cause patterns and special cases.
  • Choose the part of the problem the next cycle will test.

Lineage Notes

Direct lineage: Walter Shewhart's statistical view of process learning influenced W. Edwards Deming, and Deming made PDSA a disciplined loop for prediction, action, study, and adjustment. Complementary quality thinkers - Juran, Ishikawa, Feigenbaum, and Taguchi - sharpen the product team's attention to fitness for use, causes, total systems, and variation. Ackoff, Drucker, Ries, and Blank are useful adjacent thinkers for systems, management, and product discovery, but they are not presented here as the historical source of PDSA.

References