A Problem Is Not a Fix Request

A patient walks into a doctor’s appointment and asks for antibiotics. The doctor who writes the prescription without examining the patient isn’t practicing medicine. The antibiotic might be exactly right, but that judgment requires understanding the problem first. Without that step, it’s guessing in a white coat.

Most “problems” that show up in planning sessions are like this patient. The fix walked in first. Someone noticed friction, their mind jumped to what would relieve it, and what they’ve written down is the fix, not the problem. The statement starts with “no” or “missing” or “we don’t have.” No automated tests. Missing a rollback procedure. We don’t have monitoring. Strip the negation and you have the affirmation of a solution: get tests, add rollback, build monitoring. The problem was never named.

Test every problem statement for solution-neutrality. Remove all reference to a solution or its absence. What remains? If nothing remains that explains who is affected, what they experience, and what it costs, you started with a fix. “No automated tests” — remove the solution — nothing stands. “Engineers hold finished work for days before deploying, and it’s compressing our release cadence” — remove any solution reference — still standing. That’s a problem.

A problem needs three things. A subject: who has it. An experience: what they observe or feel. A cost: what it takes away. You don’t need precision at the surfacing stage. You need honesty. “We’re slow to ship” is not a problem statement. “Engineers sit on finished work for days before deploying, and it’s narrowing the window for iteration” is. Same observation, different specificity. One is a feeling. The other is something you can take into discovery.

Naming an absence is the most common version of this in technical work. “We don’t have X” feels like a problem because X is genuinely useful and its absence is felt. But the absence of a solution is not the presence of a problem. The problem is what the absence of X causes: the specific friction, the cost, the person who bears it. Name that, and the fix may or may not be X. Maybe X is exactly right. Maybe something simpler does it. Maybe the problem is different than you assumed. You can’t find out if you’ve already committed to the fix.

The cost of skipping this is the entire discovery process. Discovery is built to find the right problem. Bring a fix request and the process inverts: instead of finding out what’s actually happening, you spend the time finding data that justifies the answer you came in with. You’ll find it. Data is accommodating. But you’ll have spent a quarter of your budget confirming a conclusion you held before you started.

Before surfacing a problem to any planning session, run these. Can you remove every reference to a solution and still have something that stands on its own? Can you name who has it and what they experience? Can you say what it costs, even roughly? Where the answer is not yet — that’s the work still left.

This comes before root cause analysis. Before asking whether you’re at the symptom level, you need something real to interrogate. You can’t ask “is this the root?” of a fix request. The logic doesn’t hold. Name the problem first. Then you can ask whether it’s deep enough.