필사 모드: How to Define Problems and Ask Questions — The Problem Matters More Than the Answer

Opening: When the Fastest Route Is the Longest One

Monday morning, a request lands on the team. "Please add infinite scroll to the search results page."

A diligent engineer gets to work right away. They strip out the pagination logic, attach a scroll listener, and implement prefetching for the next page. Three days later, a clean infinite scroll is working. It passes code review, ships smoothly. Everyone seems pleased.

Two weeks later, the same requester comes back. "Users still say they cannot find what they want, even with infinite scroll." Only now does the real conversation begin. It turns out the problem was never "scrolling is inconvenient" but "search accuracy is poor." Users were not annoyed by flipping pages; they gave up because the item they wanted never appeared even ten pages deep. Infinite scroll was just a device for showing bad results faster and in greater quantity.

Three whole days vanished. To be precise, the team spent three days very efficiently **solving the wrong problem.**

This piece is not about "working harder." It is, if anything, the opposite. It is about a habit that may have the highest return on cost of any: pausing for a moment before you start, to confirm "is the thing we are solving actually the thing we should be solving?" The ability to produce good answers is common. The ability to choose good problems is rare. And the latter is almost always more important.

1. The True Cost of Solving the Wrong Problem

We usually think of "working slowly" as waste. But in practice the most expensive waste is "arriving quickly at the wrong answer." That is because the wrong answer only tells you it was wrong long after the fact.

Lay out the structure of the waste and it looks like this.

Pick the wrong problem

│

▼

Design / build (time invested)

│

▼

Ship / release

│

▼

"Why isn't this working?" (delayed realization)

│

▼

Root-cause analysis / rollback / rework

│

▼

Redefine the real problem (back to square one)

The scariest part of this flow is the "delayed realization." A wrongly solved problem does not light up a red flag immediately. The code runs fine, the feature works fine. You have simply built, very well, something nobody wanted. It can take days, sometimes months, for that fact to surface.

On top of this come two hidden costs.

First, the **sunk-cost trap.** Having already spent three days on infinite scroll, it is hard to say "actually, this was never the problem." So many teams keep stacking new features on top of the wrong solution, growing the problem.

Second, **the erosion of trust.** From the requester's side, the question piles up: "I clearly asked for what I needed, so why isn't it solved?" Eventually a reputation forms: "this team works fast but cannot solve problems." Fast hands paradoxically chip away at trust.

So time spent on problem definition is not a cost but an investment. If 30 minutes of questions prevents three days of rework, that is a return of more than a hundredfold.

2. Receive the Problem, Not the Solution

Most requests arrive not as problems but **already shaped as solutions.** "Add infinite scroll," "add a graph to the dashboard," "send notifications more often." These are all answers someone has already worked out in their head and handed over.

It is natural for a requester to arrive with a solution. They are busy too, and within their own context they thought "this ought to do it." The trouble is that this answer is just a stopgap produced within the information and time they had. The expert who looks at that domain every day is the one receiving the request.

So the first move is always the same: **step back one level from the solution to recover the problem.**

What the requester said: "Add infinite scroll" ← solution

│ (step back one level)

▼

Actual friction: "Cannot find the wanted result" ← symptom

│ (one more level)

▼

Real problem: "Search accuracy is low" ← problem

│ (one more level)

▼

Underlying need: "Reach accurate info fast" ← need

Skip this stepping-back and we become people who implement someone else's mental solution. Step back and we become people who find a better answer together. That difference changes not only the outcome of the work but our position within it.

3. 5 Whys: From Symptom to Cause

The simplest and most powerful tool for stepping back is the 5 Whys, which originated in the Toyota Production System. The method is exactly as named. You repeat "why?" roughly five times to dig from surface symptom to root cause. The number five is not a rule but a rough heuristic. Usually after about five whys you reach either an area you cannot control (the market, the weather, human nature) or a cause you can actually act on.

Let me work through a real case. A SaaS team raised the problem "new signups are declining."

Problem: New signups dropped 20% month over month.

Why did signups drop?

→ The share of signup-page visitors who complete signup

(conversion rate) fell.

Why did conversion fall?

→ More people are dropping off at the final step of the form.

Why are they dropping off at the final step?

→ That step now asks for "company billing info" first.

Why does it ask for billing first?

→ Last month we moved card entry earlier to curb free-trial abuse.

Why move card entry earlier?

→ We addressed abuse only by "tightening the signup step" and

never considered other defenses (email verification, usage limits).

Root cause: We chose "increasing signup friction" as the way to stop

abuse, and as a side effect we are blocking normal users too.

The problem we first received was "signups dropped." Had we stopped there, we would have run more ads or made the signup button bigger. All wasted effort. After the 5 Whys, the real problem turned out to be entirely different: "abuse defense is blocking normal users." The solution changes too. Move card entry back, and stop abuse with email verification and usage-based limits.

A few cautions when using 5 Whys.

- **Aim at the system, not the person.** Ask "why was this possible?" rather than "who did this?" If it turns into a hunt for a culprit, people get defensive and the real cause hides.

- **Do not dig only one branch.** Some problems have several converging causes. When needed, branch off a "why?" and follow multiple paths.

- **Confirm with evidence.** If the answer to a "why?" is a guess, it is just another hypothesis. Where possible, verify each step with logs, data, or user interviews.

4. Reframing: The Same Situation as a Different Problem

If 5 Whys is a tool for "digging down," reframing is a tool for "twisting sideways." It restates the same situation as an entirely different problem.

Thomas Wedell-Wedellsborg tells a famous example. Tenants in a building complain endlessly that "the elevator is too slow." The engineer's instinct is clear: replace the motor, improve the algorithm, or install a new elevator. All expensive and slow.

But the building manager restated the problem. Not "the elevator is slow" but **"the wait is boring."** With the problem reframed, the solution changes completely. They hang a mirror beside the elevator. People check their reflection or quietly observe others and feel the wait less. The complaints disappear. For almost nothing.

The heart of reframing is the question "what if I stated this problem a different way?" A few practical angles.

Original statement: "The elevator is slow"

─────────────────────────────────────────────

Different actor: "The office is swamped handling complaints"

Different emotion: "The wait is boring"

Inverted: "How do we reduce that people wait at all"

Widen scope: "The building's flow itself is inefficient"

Narrow scope: "The wait is only long from 8 to 9 a.m."

Each statement opens a different door of solutions. "Slow" calls for construction, "boring" calls for a mirror, "only 8 to 9" calls for staggered arrival times or dedicating one car to that window. A good problem-definer generates several statements before searching for an answer.

A small habit for applying reframing daily is this: write the problem as one sentence, then **swap out its key noun or verb one at a time.** In "users cannot find the feature," change "find" to "need" and you open the more fundamental question "do users really need that feature at all?"

5. Inversion: Thinking Backward

A favorite mode of thinking Charlie Munger likes to cite is inversion. Instead of asking "how do we succeed?" you ask "how would we guarantee failure?" List the conditions for failure and avoid them, and often a sharper path appears than the direct approach.

Applied to problem definition, it looks like this.

Forward question: "How do we improve onboarding?"

→ Vague. Anything could be an answer.

Inverted question: "How would we guarantee that new users leave?"

→ Show only a blank screen right after signup

→ Force difficult setup from the very first step

→ Give no guidance on what to do

→ Make the first success take far too long

Now flip this list = the list of things to do.

→ Show a meaningful first screen right after signup

→ Minimize setup or defer it

→ Clearly guide the next action

→ Create the first success quickly

Inversion is powerful because people picture "what ruins this" far more concretely than "what to add." When handed a vague improvement task, briefly flip the direction and write down "the surest way to ruin this," and a surprisingly tangible action list emerges.

6. Finding the Real Need: The Desire Beneath the Solution

Step back through a problem far enough and you eventually reach the **underlying need.** What people request and what they truly want are often different. As the familiar metaphor goes, people do not want to buy a drill; they want a hole in the wall, and deeper still, they want a picture hanging on that wall.

The most common trap when excavating needs is asking "what do you want?" directly. People often do not know their own need, or believe they do, or answer already in the language of a solution. So instead of asking about future assumptions, you should **ask about past facts.** This is the core lesson of Rob Fitzpatrick's "The Mom Test." Ask your mother about your business idea and you get a lie (kind praise); ask about her actual behavior and you get the truth.

Compare good and bad need-discovery questions.

| Bad question (asks solution/assumption) | Good question (asks fact/behavior) |

| --- | --- |

| Would you use this feature if it existed? | Last time you did this, how did you do it? |

| Would more notifications be helpful? | How are you keeping track of this today? |

| What price would you buy it at? | How much are you spending on similar tools now? |

| Doesn't this seem like a good idea? | When did this problem last cause you trouble? |

| Do you need a dashboard? | What steps do you go through now to check that number? |

The questions on the left all ask for a future opinion or assumption. People answer politely with "yes, that sounds good," and we build the wrong thing on the strength of that praise. The questions on the right ask about concrete behavior that already happened. Behavior does not lie. "Last week I opened three spreadsheets and merged them by hand to check that number" tells you the real need far more precisely than any "I'd love a dashboard."

7. The XY Problem: A Question Trapped in a Solution

The classic pattern of failing to find the need has a name. The XY problem. There is a real problem X, but stuck on a solution Y you came up with yourself, you ask only about Y.

Here is a conversation that happens daily in tech-support channels.

Asker: How do I strip the last three characters off a filename?

Helper: What are you trying to do with those three characters?

Asker: I want to change the file extension.

Helper: Ah... extensions aren't always three characters (.jpeg, .html).

What you really want is "change the extension." Here's how...

The asker had a real problem X ("I want to change the extension"), invented a solution Y ("strip the last three characters"), got stuck on Y, and asked only about Y. Had the helper solved only Y, the asker would have gotten code that silently breaks on files like ".jpeg".

The question that breaks the XY problem is always one: **"What are you ultimately trying to do with that?"** or **"One level up, what's the real problem you're trying to solve?"** This question lifts the other person out of the well of their own solution and back to the original problem. Whether we are the one being asked or the one asking, it is always worth posing.

8. The Structure of a Good Question

Defining a problem well comes down to asking well. Questions have structure too.

8.1 Open vs. Closed

A closed question is answered with yes/no or one of a fixed set of choices. An open question lets the other person explain in their own words. Both are useful, but **open questions fit the exploration stage and closed questions fit the narrowing-down stage.**

| Closed (narrows, confirms) | Open (widens, explores) |

| --- | --- |

| Was this feature hard to use? | What was your experience using this feature? |

| Is Friday the deadline? | What worries you most about this timeline? |

| Which is better, option A or B? | What is the most important criterion in this decision? |

If you throw only closed questions in the exploration stage, you hear answers only within the choices you already imagined. The real problem, the one outside your choices, never surfaces. So early on you must consciously throw more open questions, starting with "how," "what," "why," and "in what cases."

8.2 Questions That Surface Assumptions

Every problem statement rests on hidden assumptions. A good question pulls those assumptions to the surface.

Request: "The checkout page loads slowly and we need to fix it."

Questions that surface hidden assumptions:

- How many seconds exactly does "slow" mean? (quantify)

- Slow for all users, or only under certain conditions? (scope)

- What is actually happening because it's slow? (impact)

- Is load speed the real problem, or is drop-off the real problem? (redefine)

- Is there a reason now is the right time to fix this? (priority)

The single word "slow" compresses three assumptions: "how much," "for whom," and "so what's the problem." Without unpacking these, we work toward an unmeasured goal, with no agreement on what "fast enough" even is.

8.3 Questions Have Manners Too

A question can easily sound like an interrogation. The same question can read as collaboration or as resistance depending on tone. The key is **stating your intent before the question.**

Sounds like resistance:

"Do we really have to do this right now?"

Sounds like collaboration:

"If I understand the goal you're aiming for, I think I can suggest the

best-fitting approach. Is this work connected to some larger goal?"

"Why?" should not be a challenge but a signal that says "give me context so I can help better." Lay the intent first and the same question becomes an invitation to collaborate rather than a defense.

9. Form a Hypothesis and Test It

Defining a problem is no guarantee the definition is right. The definition itself is a hypothesis. So a good problem definition should be written in a testable form.

A testable hypothesis roughly follows this frame.

We believe [who] is experiencing [what difficulty] because of [what],

in [what situation]. If this is true, we will see [observable signal].

We will confirm it via [method].

Applied to the search case, it looks like this.

We believe:

Users of search are failing to find the item they want and leaving,

because result accuracy is low.

If true, we will see these signals:

- Low click-through on the first three results after search

- Repeated re-searches with the same keyword

- High share of search sessions ending with no click

We will confirm by:

- Measuring the above metrics in search logs

- Observing the actual search process of five users

Writing it this way gives two benefits. First, you learn quickly when the problem is wrong. If the signals do not appear, the hypothesis is wrong, so you change direction before spending three days. Second, you leave documented grounds for "why we chose to solve this problem." It becomes a verified judgment rather than a gut feeling.

If you can test it small, testing it small is always better. Confirming with a single prototype or five user interviews is far cheaper than building the whole thing, shipping it, and confirming in the market.

10. Make Constraints and Scope Explicit

Even with a defined problem, fuzzy boundaries let work spread endlessly. "Let's improve search" could take a month or a year. So a problem must always come with constraints and scope.

Write three things explicitly.

In scope:

- Improve the ranking algorithm for keyword search results

- Typo correction

Out of scope:

- Voice search

- A full overhaul of the recommendation system

- A redesign of the search UI

Constraints:

- Ship the first improvement within two weeks

- Solve within existing search infrastructure (no new search engine)

- Keep response time under 200 milliseconds

Naming "out of scope" is as important as setting "in scope." Without agreement on what not to do, someone well-intentioned keeps inserting new requirements and inflating the problem. This is scope creep. Constraints are not a stifling fence but a track that lets you finish. Basecamp's Shape Up calls this "fixed time, variable scope," the same spirit. Fix the time and you are forced to pick out what truly matters within it.

11. Stakeholder Alignment: Is Everyone Seeing the Same Problem?

Even on the same problem, the picture in each head differs. Sales pictures "a big customer says search is bad," design pictures "the search UI is dated," engineering pictures "search indexing is slow." All three say "search problem," but they are actually talking about three different problems.

Fail to surface this difference at the definition stage and you clash later over the output. That is why crafting one agreed sentence of problem statement matters. Write it as a single line and confirm with everyone involved: "is this the problem we are trying to solve?"

Agreed problem statement (one sentence):

"Enterprise users, when they search with frequently used keywords,

do not get the wanted result within the top three, and suffer the

inefficiency of having to look up the material manually again."

Confirming questions:

- Sales: "Is this what the big customer meant?"

- Design: "Can we treat this as an accuracy problem, not a UI one?"

- Engineering: "Within this scope, is a first improvement possible in two weeks?"

Once this one sentence is agreed, every later argument gets shorter. When someone brings a new idea, you can quickly filter it against one yardstick: "does that fit this problem statement?" Alignment is not a procedure that lengthens meetings but an investment that reduces later rework and conflict.

12. A Concrete Case: Inverting the Requirement

Let me follow one case all the way through to show how redefining a problem actually changes the work.

A request comes from sales. "Please add a button to export the report as PDF for each customer. Customers keep asking for PDFs."

A hasty team immediately builds PDF generation. They spend three days on every pitfall of PDF rendering: broken fonts, tables spilling across pages, mismatched chart resolution. But let us step back through the problem.

Request: "PDF export button" ← solution

│ Why is a PDF needed?

▼

Symptom: "Customers ask for the report as a PDF"

│ Why do they want PDF form?

▼

Reason: "The customer must share that report with internal executives"

│ Does sharing with executives require it to be PDF?

▼

Real problem: "Customers cannot easily share our data

within their own organization"

│ Then what best helps with sharing?

▼

Need: "Share in a trustworthy form that the recipient can view

without a separate login"

Once you know the real problem is "sharing," the range of solutions widens. PDF is just one of them.

Possible solutions (real problem = "easy sharing"):

- A read-only share link viewable without login

- Auto-send a report summary by email

- PDF export (the original request)

- A one-page executive summary view

What is interesting here is that a share link can be easier to build than a PDF and at the same time gives the larger value of always showing the latest data (a PDF starts going stale the moment it is made). Of course some customers cannot allow external share links for security reasons, so the final answer may not be a single one. The point is that options which would never have surfaced had we taken the "PDF button" request at face value all landed on the table once we stepped back one level on the problem.

13. Anti-Patterns: Traps to Avoid

There are classic patterns that wreck problem definition. Knowing them lets you catch the moment you fall into one yourself.

**Leading with the solution.** The most common and most expensive trap. The moment you hear a problem, "oh, just do that with X" pops out. It feels like a sign of a quick mind, but it is really jumping to a familiar answer from your own experience before understanding the problem. You cannot stop answers from coming to mind, but the habit of asking yourself once before voicing it, "wait, what was the real problem again?", makes the difference.

**Not measuring the problem.** Write the problem only with adjectives like "slow," "inconvenient," "bad," and you can never know whether you have solved it. Write it in a measurable form, like "solved when three seconds drops to one," and there is an end.

**Mistaking one voice for the whole.** The "customers" in "customers want PDF" might actually be one person. Fail to distinguish one loud request from the quiet need of many and you spend the resources of the many on the few.

**Repeatedly switching off the symptom.** If the same problem keeps returning in different shapes, we are switching off symptoms rather than the root cause. That is the moment for 5 Whys.

**Dwelling in problem definition forever.** There is a trap in the opposite direction too: analysis paralysis, endless analysis that never starts anything. The goal of problem definition is not perfect understanding but "enough understanding to be okay taking one step now." Once you have a testable hypothesis and have confirmed the biggest assumption, the next stage is moving small and learning.

Balance matters. Problem definition is not an excuse to put off work but preparation to start it properly.

14. A Practical Checklist

When a request lands, run through the following quickly before you start. For trivial or obvious work you need not go through all of it. But the more time-consuming the work, the greater this list's value.

[ Recover the problem ]

- Is this request a solution, or a problem?

- If a solution, what is the real problem one level back?

- Did you ask "what are you ultimately trying to do?" (check XY problem)

[ Root cause ]

- Did you dig beneath the symptom with 5 Whys?

- Is each "why?" answer a guess, or evidence?

- Did you restate the problem differently? (reframing)

[ Need and verification ]

- Did you ask about "behavior/facts," not the user's "opinion"?

- Did you write the definition as a testable hypothesis?

- Is there a cheap way to confirm the single biggest assumption?

[ Scope and constraints ]

- What is in scope, and what is out of scope?

- Did you write the time/tech/resource constraints?

- What is the measure of success?

[ Alignment ]

- Is there an agreed problem statement in one sentence?

- Are the relevant people seeing the same problem?

[ Balance ]

- Do you understand enough to take a step without analysis paralysis?

Closing: From Someone Who Produces Good Answers to Someone Who Picks Good Problems

The ability to produce answers is becoming ever more common. Tools get faster, information overflows, and we live in an age when anything can be built quickly. So paradoxically the scarcer ability is "choosing what to build," that is, defining the problem.

The tools covered here are not grand. Asking "why?" five times, writing the same situation as a different sentence, flipping it backward, asking about behavior instead of opinion, agreeing on one sentence. All of them take 30 minutes at most. But those 30 minutes save three days, sometimes a whole quarter.

What to remember is simple. Before you start, pause a moment and ask. **"Is what we're solving right now actually the problem we should be solving?"** If you can pose this question politely yet without fail, you move beyond someone who handles assigned work to someone who helps decide what to do. And in almost every organization, that difference ultimately makes trust and influence.

Before you rush a good answer, pick a good problem first. The problem matters more than the answer.

References

- Thomas Wedell-Wedellsborg, "Are You Solving the Right Problems?" — Harvard Business Review (hbr.org/2017/01/are-you-solving-the-right-problems)

- Thomas Wedell-Wedellsborg, *What's Your Problem?* (a book on problem reframing)

- "5 Whys" technique overview — Wikipedia (en.wikipedia.org/wiki/Five_whys)

- Lean Enterprise Institute (lean.org) — the Toyota Production System and root-cause analysis

- Rob Fitzpatrick, *The Mom Test* (momtestbook.com) — questioning that excavates the real need

- The XY problem explained (xyproblem.info)

- Will Larson, lethain.com — writing on strategy, writing, and engineering decisions

- Basecamp, *Shape Up* (basecamp.com/shapeup) — shaping problems and fixing scope

- General material on Richard Feynman / first-principles thinking