Problem Framing

Overview

Problem framing doesn't have a single originator. It draws from at least three traditions: systems thinking, design practice, and consulting methodology.

Russell Ackoff, the systems theorist, was among the first to articulate the distinction rigorously. In his decades of writing on management and systems — including Ackoff's Best (1999) and the earlier The Art of Problem Solving (1978) — he argued that most management failures result from solving the wrong problem precisely rather than solving the right problem approximately. He called tangled, poorly defined problem situations "messes" to distinguish them from well-structured "problems."

In management consulting, the discipline was embedded in firm training from early on. McKinsey's problem-solving approach puts problem definition at the front of every engagement. Barbara Minto's MECE framework (see Issue Trees) builds on the assumption that you've already framed the problem correctly; framing comes before the tree.

Design thinking added the "how might we" reframe as an explicit technique — a way of restating a problem as an open invitation to solve it. Stanford's d.school and IDEO popularized this in the 2000s. Roger Martin's The Design of Business (2009) connected design thinking disciplines to strategic management for a business audience.

The core insight that runs through all of these: clients present problems in the form of solutions. "We need a new CRM" usually means "our customer data is fragmented." "We need to cut costs by 15%" may mean "our margins are eroding and we don't know why." A consultant who takes the stated problem at face value is already halfway to the wrong answer.

When to Use It

At the very start of every engagement — before any analysis begins. Also valuable mid-engagement when the team's findings suggest the original question was poorly specified. Not a tool for later phases: if you're reframing at the synthesis stage, something went wrong at the start.

How It Works

1. Capture the presenting problem exactly as the client stated it. Write it down verbatim.
2. Ask "what would solving this achieve?" — move from the solution the client named to the goal beneath it.
3. Ask "what does success look like in a year?" — surface underlying intent and expose what the client is actually optimizing for.
4. Ask "what else could cause this symptom?" — challenge the assumption that the stated problem is the real one.
5. Restate the problem as a clean "we're trying to…" sentence at the right level of abstraction: concrete enough to be solvable, broad enough to encompass the real issue.
6. Check it back with the client. "Yes, exactly" means you're aligned. "Well, sort of" means keep going.

Useful techniques within framing:

• Ladder of abstraction — move up ("why does this matter?") to find the goal, move down ("what specifically is happening?") to find the constraint. The right level is usually one step up from where the client started.
• "How might we" — rewrite the problem as an open invitation: "How might we help customers find the right product faster?" This shifts the room from defense to invention.
• Five Whys applied to the problem statement — ask why the presenting problem exists, five times, before accepting it (see also: Root-Cause Tools).

Common Pitfalls

• Reframing as performance — changing the question for novelty rather than because it's genuinely better
• Reframing without the client — agreeing internally on a different question without checking it back explicitly
• Over-abstracting — "the real problem is your culture" is almost always unhelpful; effective reframes are still concrete and solvable
• Skipping it entirely — assuming the client has already done this work before coming to you; they usually haven't

Recommended Books

• The Design of Business — Roger Martin
• Are Your Lights On? — Gause & Weinberg
• Bulletproof Problem Solving — Charles Conn & Robert McLean