apply-problem-reframing

name	apply-problem-reframing
description	Use when facing a stated problem and about to move straight to generating solutions — pause and explicitly challenge whether the problem as framed is the right problem, since the frame (not the quality of the proposed solution) determines the entire solution space, and a wrong or too-narrow frame guarantees a suboptimal fix no matter how well it is executed.
source	Thomas Wedell-Wedellsborg, "Are You Solving the Right Problem?", Harvard Business Review (Jan-Feb 2017), and "What's Your Problem? To Solve Your Toughest Problems, Change the Problems You Solve", Harvard Business Review Press (2020); Russell L. Ackoff, "Redesigning the Future: A Systems Approach to Societal Problems" (1974) and "Idealized Design" (2006) — distinguishes resolving, solving, and dissolving a problem
tags	["problem-solving","strategy","innovation","root-cause","decision-making","consulting"]
related	["apply-mece","apply-inversion","apply-design-thinking","apply-systems-iceberg","apply-insight-synthesis"]

Apply Problem Reframing

Before generating solutions to a stated problem, explicitly challenge whether the frame itself is the right one — because the frame determines the entire available solution space, and an unexamined frame silently forecloses the best available fix before solution work even starts.

Why This Is Best Practice

Why best: Most problem-solving effort goes into optimizing a solution within a frame that was never itself examined. The frame a problem arrives in — how it is worded, what category it is implicitly assigned to, whose responsibility it is assumed to be — determines which solutions are even considered. A team that solves brilliantly within a wrong or too-narrow frame produces a worse outcome than a team that finds the right frame and applies an ordinary solution to it. Reframing is a distinct, teachable step that precedes solution generation, not a vague call to "think differently."

Thomas Wedell-Wedellsborg (HBR 2017; "What's Your Problem?", HBR Press 2020): Research into executives who successfully resolved persistently difficult organizational problems found that the decisive move was consistently a reframe of the problem statement itself, not a better solution to the original statement — and that specific, repeatable techniques (examining what the frame excludes, comparing to other cases, checking for exceptions/bright spots, checking one's own role in the problem, consulting other stakeholders' framing, and adjusting the frame's level of abstraction up or down) reliably surface a better frame. The most widely cited illustration in this literature: a building's tenants complained elevators were too slow; framed as a mechanical-speed problem, the only available fixes were expensive elevator retrofits; reframed as a perceived-wait problem, installing mirrors near the elevator doors (giving idle riders something to look at) resolved the large majority of complaints at a fraction of the retrofit cost — the same underlying complaint, two entirely different available solution spaces depending on the frame chosen.

Russell L. Ackoff ("Redesigning the Future", 1974; "Idealized Design", 2006): Ackoff, a Wharton operations research professor and consultant to major corporations including Anheuser-Busch, formally distinguished three responses to a problem: resolving it (a satisfactory-enough fix within the existing frame), solving it (an optimal fix within the existing frame), and dissolving it (redesigning the surrounding system so the problem no longer arises at all). His documented corporate consulting practice repeatedly found that redesigning the system containing a problem — rather than optimizing within it — eliminated categories of problems entirely rather than incrementally improving the response to them, avoiding the capital and operating cost of solving the same recurring problem indefinitely.

Adopted by: Wedell-Wedellsborg's reframing methodology is documented Harvard Business Review/HBR Press material used in strategy consulting and executive education; Ackoff's idealized-design and dissolving-problems methodology was applied in his consulting engagements with major corporations (including Anheuser-Busch) and is taught in systems-oriented operations research and management curricula descending from his Wharton work. Impact: The elevator/mirror case is the most widely cited demonstration in the reframing literature of a dramatically cheaper, more effective solution becoming available purely from a frame change, with no change to the underlying mechanical facts of the situation; Ackoff's dissolving-problem engagements are documented as eliminating the recurring cost of repeatedly solving the same category of operational problem by redesigning the system that generated it, rather than incrementally improving the fix.

Steps

1. Write down the problem exactly as given, before touching solutions. State it verbatim. This creates a fixed artifact to interrogate rather than an assumption everyone in the room silently agrees with.

2. Identify the implicit frame. Ask what category, cause, and owner the problem statement already assumes (e.g., "elevators are too slow" implicitly frames this as a mechanical-speed problem owned by facilities engineering). Naming the hidden frame is the prerequisite for challenging it.

3. Look outside the frame. Ask what the current frame excludes by construction — could the same complaint instead be about perception, timing, a different affected stakeholder, or a different level of the system than the one the frame assumes?

4. Check for bright spots. Find instances, subgroups, or time periods where the "same" problem doesn't occur. What differs in those cases points to a variable the current frame is missing entirely.

5. Look in the mirror. Check whether the current frame conveniently locates the fix outside your own control or responsibility — and verify whether your own prior decisions are actually part of the causal picture the frame is omitting.

6. Gather other stakeholders' independent framing of the same problem. People differently positioned relative to a problem often frame it differently; collect these before settling, not after.

7. Ladder the frame up and down one level of abstraction. Restate the problem one level more general ("why does this actually matter?") and one level more specific ("what exactly, precisely, is happening, to whom, when?"). The right frame is often at a different altitude than the one first proposed.

8. Select the frame that opens the widest, most tractable solution space — then generate solutions against that frame. The right reframe is validated by the fact that it makes previously invisible solutions available, not by how clever or novel it feels.

9. Apply Ackoff's dissolving test before committing to solving. Ask whether redesigning the surrounding system could make this category of problem stop recurring altogether, rather than producing a better fix within the system that keeps generating it.

Rules

• Never generate solutions before the frame has been explicitly stated and challenged at least once. Solving fast inside the given frame is the default behavior this technique exists to interrupt.
• A reframe is validated by whether it opens a genuinely different solution space, not by whether it sounds insightful — test every candidate reframe against "does this make a previously unavailable class of solution available?"
• Bound the reframing step. Set a fixed number of candidate frames or a time box before committing to one and moving to solution generation — indefinite reframing is itself a failure mode that avoids ever committing to a solution.
• Apply Ackoff's resolve/solve/dissolve distinction explicitly: check whether the problem can be dissolved (designed out of existence) before settling for solving it within its current frame.

Examples

Facilities complaint: Tenants complain elevators are too slow. Framed as a mechanical problem: an expensive elevator retrofit is the only option under consideration. Bright-spot check and outside-the-frame questioning reveal the complaint correlates with idle waiting time, not actual elevator speed. Reframed as a perceived-wait problem: installing mirrors near the elevator doors resolves the large majority of complaints without any mechanical work.

Sales decline: Initial frame: "sales are declining, the sales team needs better pitches." A bright-spot check shows sales are flat among customers onboarded before a recent product change and declining only among customers onboarded after it. Reframe: "the new onboarding flow is churning otherwise-satisfied customers." Solution space shifts entirely from sales training to fixing onboarding.

Dissolving example: A hospital frames its problem as "how do we reduce ER wait times," and pursues staffing and triage optimizations within the existing ER structure. Applying Ackoff's dissolving test: redesigning the front door of the care system — telehealth triage before arrival, urgent-care redirect for non-emergencies — removes a large share of visits from the ER queue entirely, eliminating the wait-time problem for those cases rather than optimizing the response to it.

Common Mistakes

• Treating the first stated problem as fixed and immediately brainstorming solutions against it. This is the default failure mode the entire technique exists to interrupt.
• Producing a "reframe" that is only a rewording, not a genuine restructuring. Test every candidate against whether it opens a previously unavailable solution space — a frame that changes the words but not the available solutions has not actually been reframed.
• Reframing indefinitely as a way to avoid committing to a solution. Bound the reframing step with a fixed budget of candidate frames or a time box.
• Skipping the dissolving test and settling for the best fix within a frame that will keep regenerating the same problem. A well-executed solve inside a bad frame still leaves the underlying system producing the same category of problem repeatedly.

When NOT to Use

• Well-understood, previously-solved problem types where the standard frame has a strong track record — reframing every routine, already-diagnosed problem wastes time for no gain.
• Genuine emergencies requiring immediate action with no time to challenge the frame — act within the given frame first, reframe afterward during the postmortem.
• A specific technical problem with a known, narrow root cause (e.g., a reproducible bug) — reframing a well-diagnosed technical issue adds nothing; use direct root-cause techniques instead.
• Human-centered product design work already running a full empathize-based design process — see apply-design-thinking's Define phase, which reframes specifically from ethnographic user-research insight rather than from the general-purpose techniques here.