Long before anyone agrees on the problem, a meeting has usually already produced three solutions. “What if we made the button bigger?” “Let’s just add one more onboarding screen.” Proposals like these get thrown out before anyone has settled what the actual problem is. Naming the problem is harder than finding an answer to it, yet most meeting time goes to debating solutions while almost none goes to defining what’s broken. A poorly framed problem defeats even a brilliant solution, because the team ends up solving something else entirely.
1. Solutions Arrive First — Always
Reaching for a fix before the problem is understood is a natural reflex. Proposing an idea simply feels more satisfying, psychologically, than sitting with an unresolved question, and it reads as a fast, visible contribution in the room. But solutions that appear this quickly are usually answers to different, unspoken problems held by different people. One person is silently responding to “our churn is too high,” another to “new users feel overwhelmed.” Of course the fixes they suggest pull in different directions — they were never solving the same problem in the first place.
2. Separating Symptom From Cause
Framing a problem well starts with separating the symptom from the cause. “Onboarding completion is low” is a symptom, not a problem statement on its own. The real problem only becomes visible once you’ve asked, a few layers down, why the number is low. Maybe there are too many required fields, maybe an unclear step causes drop-off midway, or maybe the incentive to sign up in the first place is too weak — and each of these calls for a completely different fix. Product design consulting sees this pattern constantly: a client’s very first request is often already dressed up as a solution, phrased as “please redesign this screen.”
💡 Pro tip — When a client asks you to “redesign this screen,” resist jumping straight into layout work. Ask first what specifically feels broken about the current screen. The real issue is often nothing like the original request.
3. Writing a Problem Statement That Holds Up
A strong problem statement is concrete enough that anyone reading it pictures the same scene, and specific enough that it doesn’t quietly assume a particular fix. This discipline lines up closely with the framing step inside design thinking applied to everyday work, where naming the problem carefully is treated as its own dedicated stage.
A Solution Disguised as a Problem
“We need to add a search filter button” — a fix dressed up in the grammar of a problem statement.
An Actual Problem Statement
“Users can’t narrow down the product they’re looking for, so they scroll the full list to the end” — this leaves room for many different fixes.
On a given project, it’s common for the planner to see it as a conversion problem, the engineer as a technical-debt problem, and the designer as a usability problem — all at once. In that situation, the most useful move is to have everyone write their version of the problem in a single sentence, then lay the sentences side by side and compare. Wherever several people’s sentences converge is very likely where the real priority sits. IDEO.org’s Design Kit proposes a similar practice for surfacing and comparing the assumptions of different stakeholders at this exact stage.
A feel for problem framing is built by repeatedly rewriting statements, not by studying the theory once. Take a sentence like “we need to add a progress bar to the checkout screen” and ask why, and you get “users get anxious not knowing how much of checkout is left.” Ask why again, and you land on something more fundamental: “the steps run on with no visible end point.”
Write down the current task as a solution sentence: “We need to build ~”
Strip the solution out of that sentence and ask “why is this needed” three times in a row
Once you reach the root cause, rewrite it as a problem statement that doesn’t assume a specific fix
4. How Many Times Should You Ask “Why”
Repeating “why” isn’t a novel idea. The five-whys technique, rooted in Toyota’s production system, came out of the experience of asking “why” five times when a defect occurred and finding it usually cut through surface symptoms to the true root cause on the shop floor. The same principle applies directly to problem framing. What matters more than counting to some fixed number is recognizing the point where you should stop.
Common mistakes run in two opposite directions. One is stopping at the first “why” and declaring that the root cause, and the other is pushing so far that the team ends up at a point nobody can actually act on, framed as if the issue were simply inherent to users. The real root cause has to be a point your team’s own decisions and actions can actually move.
Closing thoughts
If a whole team practices this drill together, the habit of jumping to solutions in meetings gradually shifts on its own. It feels slower and more awkward at first, but after a few repetitions you can feel it cutting out the unnecessary arguments that come from proposing fixes for mismatched problems.
Did we separate what we’re dealing with right now into symptom versus cause?
Does the problem statement already assume a specific fix?
Did each stakeholder write down what they think the problem is, in a single sentence?
Could the team picture the same scene from the problem statement alone?
Did we spend enough time on problem framing before discussing solutions?
Did stakeholders actually agree on the same problem statement?
This work isn’t about slowing meetings down — it’s an investment that saves time spent redirecting course later. When running a design sprint on a compressed timeline, skipping this first framing step tends to make the rest of the process shaky. Before your next meeting turns to solutions, try spending just five minutes writing the problem down as a single sentence first.
Design Daily Life · Notes on design, daily
한국에 온 외국인 친구가 있나요? 메뉴 번역·택시 요금·약국 카드가 한 앱에 있는 K-OREA를 알려 주세요.
Visiting Korea? K-OREA puts menu scanning, taxi fare guidance and a pharmacy card in one app. Get it on the App Store.