Framing and Defining Problems

The way a problem is written down quietly decides which solutions are even thinkable. "The elevator is too slow" invites an engineering answer - a faster motor, a smarter scheduling algorithm, a second lift. "The wait is annoying" invites something completely different. Most teams pour their effort into solving the problem exactly as it was first stated, and the first statement is almost never the best one available.

Solving the wrong problem well is worse than solving the right problem badly. A polished solution to the wrong problem looks like success, gets shipped, and then gets defended - while the real issue sits untouched. The cheapest and most neglected move in problem solving happens before any solving begins: getting the problem right.

Symptoms versus the real problem

A symptom is what you notice; the problem is what produces it. "Sales are down" is a symptom. The problem might be pricing, a broken checkout, a new competitor, or a message that no longer lands. Rushing to fix the symptom - a discount to lift sales - can bury the real problem for another quarter. The test is simple: if your fix worked perfectly and the complaint still came back, you were treating a symptom.

The frame decides the field of solutions

A frame is the sentence you put the problem in, and each frame comes with its own menu of solutions attached. Frame slow elevators as a speed problem and every answer costs money and months. Frame it as a boredom problem and cheap answers appear. Neither frame is "true" - they are different lenses, and a lens you never switch is one you have mistaken for the world.

Reframing

Reframing is deliberately restating the problem to reveal solutions the first framing hid. Useful prompts: What is the problem behind the problem? Who has this same complaint but describes it differently? What are we assuming that we do not have to? Is the person who owns the complaint the person we are trying to help? Reframing is not a one-time step - good problem solvers cycle between framing and solving rather than framing once and charging ahead.

A software team gets a stream of tickets: "the export button is broken." Framed as a bug, engineers spend a week and find nothing wrong - the button works. Reframed by asking what users were actually trying to do, the real problem surfaces: people cannot find the file after it exports. The button was never the issue; the download location was invisible. The one-line fix - show the file when it is ready - makes the tickets stop. A week of debugging solved the stated problem perfectly and would have changed nothing.

Reframing is not an excuse to redefine every problem until it becomes someone else's. Some problems are exactly what they look like: a server that is genuinely out of memory needs more memory, not a philosophical restatement. Endless reframing can also become a way to avoid committing to any solution at all. The skill is knowing when the frame is doing damage - when good solutions keep failing, when the same complaint returns in new clothes - and when the frame is fine and the work is simply hard.

In his Harvard Business Review article "Are You Solving the Right Problems?" (January-February 2017), Thomas Wedell-Wedellsborg opens with a building whose tenants complain that the elevator is too slow. Framed as an engineering problem, the options are expensive: replace the motor, upgrade the algorithm, install another elevator. But the reframe was that the real issue was not speed - it was that waiting is boring. The response was to hang mirrors beside the elevators. People looked at themselves and each other, the wait stopped feeling long, and complaints dropped.

Wedell-Wedellsborg presents the mirror story as an illustrative example rather than a controlled study, and it is now widely cited precisely because it is memorable. His larger point, developed further in his 2020 book "What's Your Problem?", is that reframing is a repeatable practice, not a one-off flash of insight. The mirror solves a different problem than the one first stated, and it was only reachable by changing the question from "how do we make the elevator faster?" to "how do we make the wait more pleasant?"

• A clearly stated problem is a correctly framed one. Clarity and correctness are different; a crisp statement of the wrong problem is still the wrong problem.
• The problem is whatever the person first says it is. The first statement is a starting point, not a verdict.
• Reframing means brainstorming solutions. It happens one step earlier - on the problem itself, before any solutions.
• There is one true frame. Frames are lenses; the goal is to try several, not to find the single correct one.

You are given three problem statements as first written. For each, produce at least two alternative framings and note which solutions each new framing makes available - then pick the frame you would actually solve.

Think Like a Maester: Before you solve a problem, write it three different ways - the solutions you can see depend entirely on the sentence you put the problem in.

1. What is the difference between a symptom and the problem that produces it?
2. Why does the framing of a problem limit which solutions you can find?
3. What does it mean to reframe a problem, and when is it worth doing?
4. Why is solving the wrong problem well often worse than solving the right one badly?
5. In the elevator case, what changed between the first framing and the reframe?

The sentence you put a problem in decides which solutions you can reach. Symptoms are not problems, and the first statement of a problem is rarely the best one. Reframing - deliberately restating the problem to expose hidden options - is the cheapest high-leverage move available, as long as you know when to stop reframing and start solving.

• Breaking Problems into Smaller Parts
• Prototyping and Experimentation