A problem is a difference between things as desired and things as perceived. Not between things as desired and things as they are — because you never have direct access to how things are. You only have your perception, and your perception is shaped by the same framework that defined the problem in the first place.
Not too many people, in the final analysis, really want their problems solved.
Simple Picture
An office building gets complaints that the elevators are too slow. The engineering solution: faster motors, better algorithms, more elevators. Expensive and slow to implement. The actual solution: install mirrors next to the elevators. People stop complaining — not because the elevators are faster but because they are now occupied with looking at themselves. The problem was never “slow elevators.” The problem was “unpleasant waiting.”
The mirror solution is only visible if you question the problem definition. Every engineering solution assumes the problem is “slow elevators.” The engineering algorithm says: before optimizing the elevator, ask whether the elevator is the problem at all.
The Problem Definition Trap
Most people have been trained by school to seize upon the first statement that looks like a problem and solve it as fast as possible. Speed counts on exams. This instinct carries into professional life, where the first plausible problem definition is adopted without examination and all subsequent effort is spent on solving a problem that may not be the actual problem.
The will to think names the cognitive version: most people stop when they have an answer that sounds right. Problem-solving has the same trap one level up: most people stop when they have a problem that sounds right. The cached thought is not just the solution — it is the problem definition itself.
If you cannot think of at least three things that might be wrong with your understanding of the problem, you do not understand the problem. This is tempo applied to problem-solving: premature exploitation of the first problem definition produces the same brittle result as premature exploitation of any mental model. The exploration phase — sitting with ambiguity about what the problem is — must precede the exploitation phase of solving it.
Problem Displacement
Engineers recognized their own safety problem but failed to see that it could be a problem for someone else. This is problem displacement — solving a problem in one part of the system by moving it to another part, where it becomes invisible to the people who “solved” it.
The Systems Bible frames this structurally: systems develop goals of their own, and one system’s solution is another system’s problem. The Theory of Constraints adds specificity: improving a non-constraint displaces attention and resources from the actual bottleneck, making the system worse while the local metrics improve.
If you’re part of today’s solution, then you’re part of tomorrow’s problem.
This inverts the usual framing. The person who solves a problem creates a new system configuration that will eventually produce its own pathologies. The local optimum of the current solution becomes the obstacle to the next improvement — and the people who built the current solution are the least likely to question it, because their identity is invested in it.
Why People Resist Solutions
The deepest insight in the book: people are often more attached to their problems than to any possible solution. A problem, once accepted, provides structure — it explains why things are bad, it justifies current behavior, and it gives the sufferer a narrative identity. Solving the problem would dissolve all of that.
This maps directly onto locally-optimal at the psychological level. The dysfunction is not a bug — it is serving a purpose. The person who complains about their job but never leaves is getting something from the complaint. The team that identifies a process problem but never fixes it is getting something from having the problem. IFS says every part serves a function; Weinberg says every unsolved problem serves a function too. The focusing problem is the purest version: there is always something wrong, and if you solve it, the next one is already waiting — because the function of the problem is not to be solved but to shield the person from the groundlessness that appears when nothing is wrong.
Don’t solve other people’s problems when they can solve them perfectly well themselves. This is boundaries stated as a problem-solving principle — the same separation of tasks that Adler formalized. Whose problem is this? If they can solve it, solving it for them robs them of the growth and robs you of time better spent elsewhere.
The corollary: if a person is in a position to do something about a problem but does not have the problem, then do something so he does. This is the feedback pipe in action — making the problem visible to the person who has the power to fix it, rather than absorbing it yourself.
Word Games and Reframing
Word games are usually cheaper than unwanted solutions.
Before committing resources to solve a problem, play with the definition. Reframe it. Test whether the problem survives being described differently. If it does not — if changing the words dissolves the problem — then the problem was in the framing, not in reality.
People seldom know what they want until you give them what they ask for. The Milo Criterion builds on this: the user’s stated requirements are always wrong, and the only way to discover the real requirements is to give them something and watch what they actually do with it. There is no such thing as a final problem definition — only successive approximations that get closer to the real gap between desired and perceived.
Dimwit / Midwit / Better Take
The dimwit take is “just solve the problem — stop overthinking it.”
The midwit take is “we need better requirements gathering and stakeholder alignment before solutioning.”
The better take is that the problem definition is the most valuable and most dangerous artifact in any project — more dangerous than a wrong solution, because a wrong solution to the right problem can be iterated, while the right solution to the wrong problem is a permanent waste. The instinct to solve fast is the enemy. The discipline to question the problem — to sit with three possible misunderstandings before committing — is the most leveraged skill in engineering, therapy, and life. Most of what looks like problem-solving is actually problem-avoidance: solving a convenient problem to avoid confronting the real one.
Main Payoff
We never have enough time to do it right, but we always have enough time to do it over.
This is the sunk-cost dynamic of bad problem definitions. The organization that rushes to solve the wrong problem will spend more total time than the one that invests upfront in getting the definition right. The school system that produces people who seize the first problem statement and solve it at speed is producing people who will spend their careers doing things over — brilliantly, efficiently, and in the wrong direction. McGraw crystallizes it: “Without a specification, a system cannot be wrong — it can only be surprising.” Much of the essence of building a program is debugging the specification, not the code.
References:
- Donald C. Gause and Gerald M. Weinberg, Are Your Lights On? How to Figure Out What the Problem Really Is