Skip to content
All articles

Problem Definition & Storytelling: The SCQ Framework

Dean Jain

Dean Jain

Senior Staff Software Engineer · Enterprise AI, Data & Cloud Architect

· 5 min read

CommunicationProblem SolvingStorytelling
---
config:
  theme: dark
  fontSize: 17
  themeVariables:
    fontFamily: "Comic Sans MS, Comic Neue, Chalkboard SE, cursive"
---
flowchart LR
    S["📍 Situation"]:::obs --> C["⚡ Complication"]:::warn
    C --> Q["❓ Question"]:::gate
    Q --> WD["🎯 Well-defined problem"]:::server
    WD --> BS["💡 Breakthrough solution"]:::good
    classDef obs fill:#AED6F1,stroke:#2E86C1,stroke-width:2px,color:#0F172A
    classDef warn fill:#FFE6A8,stroke:#E0A106,stroke-width:2px,color:#0F172A
    classDef gate fill:#D7C3F2,stroke:#8E5BD0,stroke-width:2px,color:#0F172A
    classDef server fill:#A8E6D0,stroke:#2FA37C,stroke-width:2px,color:#0F172A
    classDef good fill:#BFEFC8,stroke:#3FA34D,stroke-width:2px,color:#0F172A

Figure 1: Framing is the work. A problem told well, as Situation then Complication then Question, becomes a problem you can actually solve.

Teams love to jump straight to solutions, because it feels productive.

But most failed projects didn’t fail at the solution. They solved the wrong problem, beautifully, because nobody framed it first. A well-defined problem leads to breakthrough solutions; a vague one leads to expensive thrashing.

Problem definition is a storytelling skill, and the SCQ framework, Situation then Complication then Question, is the spine. Get the frame right and the solution gets dramatically easier.

TL;DR

  • Framing is the highest-leverage step. The clearer the problem, the better the solutions and the cheaper they are to find.
  • SCQ tells the problem as a story: Situation (the agreed starting point) → Complication (what changed) → Question (what we must now answer).
  • Separate knowns, unknowns, and assumptions. The quality of your assumptions largely determines the quality of your strategy so make them explicit and challengeable.
  • Use MECE to structure the problem break it into parts that are mutually exclusive and collectively exhaustive, often as an issue tree.
  • Diverge, then converge. Open the problem space wide before you narrow it; jumping straight to convergence is how you solve the wrong thing.

1. Tell the problem as a story (SCQ)

A problem stated as a flat fact (“conversion is down”) invites a reflexive fix. A problem told as a story invites understanding. SCQ is that story in three beats:

  • Situation one to three sentences on how things worked before the issue, framed so almost everyone agrees. This builds the shared ground you’ll reason from.
  • Complication one to three sentences on what changed and created the problem or opportunity. This is the tension the reason we’re here.
  • Question the question the complication forces. Usually one of: What should we do? How will we do it? Should we do it? Why did it happen?

The discipline is subtle but powerful. State the Situation as something everyone agrees on, and you stop the argument starting in the wrong place. Isolate the Complication, and you name the actual problem rather than a symptom.

This is Minto’s SCQA, which the Pyramid Principle uses in full to open a recommendation. Here I stop at the Question on purpose, because the point is to frame a problem before any answer exists.

2. Knowns, unknowns, and the assumptions that decide everything

Once SCQ frames the problem, sort what you actually have into three buckets:

---
config:
  theme: dark
  fontSize: 17
  themeVariables:
    fontFamily: "Comic Sans MS, Comic Neue, Chalkboard SE, cursive"
---
flowchart LR
    K["✅ Knowns<br/>facts you can rely on"]:::good
    U["❔ Unknowns<br/>gaps to investigate"]:::obs
    A["⚠️ Assumptions<br/>beliefs you're betting on"]:::warn
    A -->|"quality of assumptions =<br/>quality of strategy"| STR["🎯 Strategy"]:::server
    classDef good fill:#BFEFC8,stroke:#3FA34D,stroke-width:2px,color:#0F172A
    classDef obs fill:#AED6F1,stroke:#2E86C1,stroke-width:2px,color:#0F172A
    classDef warn fill:#FFE6A8,stroke:#E0A106,stroke-width:2px,color:#0F172A
    classDef server fill:#A8E6D0,stroke:#2FA37C,stroke-width:2px,color:#0F172A

Figure 2: Knowns, unknowns, assumptions. The third bucket is the dangerous one, because the quality of your assumptions sets the ceiling on your strategy.

The first two buckets are easy to respect. The third assumptions is where strategies quietly go wrong, because assumptions masquerade as knowns. The quality of your assumptions largely determines the quality of your strategy. So the most valuable move in problem definition is to drag them into the open and label them.

“We’re assuming demand holds. We’re assuming the integration is two weeks. We’re assuming the competitor won’t respond.”

Once named, an assumption can be tested, challenged, or designed around. Left implicit, it becomes the silent crack the whole plan rests on.

This is also why we’re so bad at prediction: we think in binaries and absolutes rather than in probabilities.

The fix is scientific: formulate explicit theories about how knowns and unknowns relate, gather data to test them, then revise. Treating assumptions as hypotheses to validate, rather than truths to defend, is the difference between a strategy and a hopeful guess.

3. Structure the problem with MECE

A big problem is unsolvable until it’s decomposed well. MECE Mutually Exclusive, Collectively Exhaustive is the test for a good decomposition:

  • Mutually exclusive the parts don’t overlap, so you don’t double-count or argue in circles.
  • Collectively exhaustive together they cover the whole problem, so nothing important is missed.

The practical tool is an issue tree. Break the central question into sub-questions, each into sub-sub-questions, keeping every level MECE. A clean tree turns “why is retention falling?” into a small set of investigable branches instead of a fog.

It also tells you where to dig. Peel the onion with repeated “why”, the 5 Whys, down a branch until you hit a root cause you can act on.

4. Diverge, then converge

The last discipline is sequencing. Good problem formulation has two distinct modes, and doing them in the wrong order is the classic mistake:

---
config:
  theme: dark
  fontSize: 17
  themeVariables:
    fontFamily: "Comic Sans MS, Comic Neue, Chalkboard SE, cursive"
---
flowchart LR
    P["🎯 Framed problem"]:::gov --> DIV["↔️ Diverge<br/>widen the space · many framings &amp; options"]:::obs
    DIV --> CON["↘️ Converge<br/>narrow to the best problem &amp; solution"]:::good
    classDef gov fill:#E0D6F5,stroke:#9B7EDE,stroke-width:2px,color:#0F172A
    classDef obs fill:#AED6F1,stroke:#2E86C1,stroke-width:2px,color:#0F172A
    classDef good fill:#BFEFC8,stroke:#3FA34D,stroke-width:2px,color:#0F172A

Figure 3: Diverge before you converge. Explore framings and options widely, then narrow deliberately.

Diverge first, and deliberately widen the space. Restate the problem several ways, surface competing theories, and ask exploratory questions to narrow scope and expose hidden assumptions.

Then converge. Narrow to the sharpest problem statement and the most promising solutions, ideally as confirmatory hypotheses that are measurable and testable: an independent variable you control, a dependent outcome you measure.

Skipping the diverge step is how teams lock onto the first plausible framing and miss the better one sitting one reframe away. It is the cheapest mistake on this list to avoid, and the most common one to make.

The rigour pays off when you write the actual problem statement. Is this really many problems? What must a solution satisfy? Who should solve it? How will success be measured? A statement that answers those is a brief a team can run with.

The instinct to start solving is the enemy of solving well.

Frame the problem as a story with SCQ, separate your knowns from the assumptions you’re betting on, decompose it MECE, and diverge before you converge. Do that and you spend your effort on the right problem, which is the only kind of effort that compounds.

A problem well-defined is a problem half-solved. Nobody can reliably say who first said it, but anyone who has watched a team solve the wrong thing beautifully knows it holds.

Further reading