Split View: 문제를 정의하는 능력 — 잘못된 문제를 완벽히 푸는 실패를 피하는 법

Framing the Problem — How to Avoid Perfectly Solving the Wrong One

• Where a Perfect Answer Stops Being Useful
• Why This Sits on the Expensive Side
• Requirements Usually Arrive Dressed as Solutions
• Write Down What You Will Not Build First
• A Six-Line Problem Statement
• Narrowing Scope Versus Changing the Problem
• Try It This Week
• Further Reading
• Sources

Where a Perfect Answer Stops Being Useful

A constructed illustration. A request comes in: search is slow, please add a cache. Two weeks later the cache is in, median response time is halved, the dashboard is green. The complaints are unchanged. What the people who said "slow" were hitting was not an average lookup but a twelve-second query that only appears when three filters are stacked — and that band happened to have a cache hit rate near zero.

Nothing about the execution was wrong here. The cache was built well. What was wrong was the choice of what to fix. And this kind of failure has a nasty property: a rough answer signals that it is not finished, while a perfect answer signals that it is. So the better you solve a badly framed problem, the longer the mistake stays hidden.

Why This Sits on the Expensive Side

Part 1 listed four things that make verification expensive: tacit context, delayed results, the absence of an oracle, and accountability. Hold framing up against them and all four apply. There is no answer key telling you which problem is the right one, the news that you picked wrong usually arrives after release, the information needed to judge lives in people rather than in code, and in the end somebody has to put their name on the choice.

Fred Brooks put it more sharply in "No Silver Bullet" in 1986: the hardest single part of building a software system is deciding precisely what to build, no other part of the work so cripples the resulting system if done wrong, and no other part is more difficult to rectify later.

That is a forty-year-old sentence, and cheap generation has sharpened rather than dulled it. When building gets faster, arriving at the wrong problem also gets faster. A quick implementation does not correct a wrong direction; it carries you further along it.

Requirements Usually Arrive Dressed as Solutions

"Add a cache" is not a requirement, it is a solution. Requesters translate the discomfort they experienced into an answer before they reach you. The translation is made in good faith, and it is made strictly within what the requester happens to know.

Unwinding that translation usually takes three questions.

• What happens today if this does not exist? This one surfaces the symptom.
• When did it start being a problem? This one surfaces what changed.
• If this is solved, what will you do differently? This one surfaces the success test.

The third filters the most. If no answer comes, the request is not yet a problem — it is a wish. If an answer comes, that answer is your completion criterion, already written.

One caution about posture. These questions exist to receive a request accurately, not to refuse it, and the difference shows up in what you do next rather than in your tone. Ask them and then do nothing, and nobody answers you the next time.

Write Down What You Will Not Build First

Scoping usually gets expressed as a list of things to do, and that list grows on its own. The opposite direction is far stronger: write down what you are not doing this time.

Non-goals buy three things. First, the argument moves earlier. Show people the list of things you are dropping and the objections arrive now, and objections that arrive now are cheap to handle. The same objection after the work is built is expensive. Second, you get a standard for judging requests that arrive later. Third, it acts as a brake on yourself.

There is one rule. Attach a reason to each non-goal. Do not just write "no localization"; write that the first two customers are both domestic and that pulling strings out later costs only linearly. A non-goal without a reason gets reversed in the next meeting.

A Six-Line Problem Statement

Turn framing into a document and it tends to get long, and long documents do not get read. Six lines is enough.

Example — a six-line problem statement

Symptom:   search responses exceed 10s when 3+ filters are combined. ~40/day
Impact:    those users abandon search and phone their account manager instead
Success:   p95 for the same combinations under 3s. confirmed by fewer phone calls
Non-goal:  overall search speed. the tail is the problem; the median is fine
Constraint: index schema changes are blocked until next quarter
Unknown:   how many users hit this combination, and when it started growing

The line most often left blank is the last one. A problem statement with nothing under "unknown" has usually not been researched. A document containing only what you know looks confident, but the item that actually moves the schedule is always the one that was not on it.

Narrowing Scope Versus Changing the Problem

Here is the part to be honest about. The ability to reframe is easy to abuse. When a hard request arrives, declaring that the real problem is actually something else and switching to the easier thing happens constantly, and that is avoidance, not framing.

There is exactly one test that separates them: check whether the original requester agrees with the reframing. Narrowing scope cuts the same problem into a smaller piece, and the piece still touches the requester's symptom. Changing the problem aims at a different symptom, and the requester receives the deliverable and keeps experiencing what they experienced before. So a reframing has to be taken back to the requester, and without that confirmation you have just turned the wheel on taste.

Try It This Week

Pick one task you are working on right now and fill in the six lines above. Thirty minutes is enough. Whichever line you get stuck on tells you who to ask and what to ask them. If the success line in particular will not write, that task is currently running without a completion criterion.

• Problem-Solving Trainer — restating a problem in your own words and deleting assumptions nobody imposed are two of the nine moves. They do the same job as the first line and the non-goal line of the statement.
• Collab RPG — the price that asking a clarifying question puts on a relationship arrives several scenes later. Asking back is not free, and this one shows you the cost on a delay.

Where this does not apply: sometimes the requester already knows their problem precisely. Regulatory work, line items written into a contract, an interface imposed by an upstream system — cases where the definition was fixed outside the room. Attaching a problem statement there only spends time. Asking back earns its keep when there is an information gap between requester and implementer.

Further Reading

• Related post on this blog: How to Define Problems and Ask Questions — The Problem Matters More Than the Answer

What Stays Expensive series

• Previous: Writing as an Engineering Skill — What Design Docs, Postmortems, and Review Comments Actually Do
• Next: A Sense for Production — What Looks Different After You Have Been Through an Outage

Sources

• No Silver Bullet: Essence and Accidents of Software Engineering — Fred Brooks, 1986 (full text) — the sentences about deciding precisely what to build being the hardest single part, no other part crippling the resulting system as much if done wrong, and no other part being more difficult to rectify later appear in the "Requirements refinement and rapid prototyping" section. Read 2026-08-15.
• The three unwinding questions, non-goals with reasons attached, and the six-line problem statement are not from that source; they are the procedure assembled in this post.