2.1Defining the problem (not the symptom)
The essentials in 30 seconds
- A well-posed problem is half-solved: rushing to solutions without framing risks solving the wrong problem.
- Cause vs symptom: the symptom is visible and bothersome (complaints); the cause is what produces it (the process) — only it fixes durably.
- Reflex: rephrase with no disguised solution (« how to meet deadlines? », not « we need more staff »).
Running mini-case — Sara and the returning complaints
Sara runs a small garment workshop in Algiers: customers complain about delays. First reflex: reassure the unhappy ones one by one. But more complaints arrive at once. Rereading the situation, she understands she treats the symptom (the visible complaints) instead of the cause (the slipping process). We will frame the real problem with her, step by step.
This same case runs through the course, the diagram, the script and the 48h challenge — and continues in 2.2, 2.3, 2.4 and 2.5.
1. A well-posed problem is half-solved
Before looking for solutions, you must define the problem well — and this is the most often botched step. The classic error: rushing to solutions for a poorly framed problem, or worse, solving the wrong problem.
You then tackle the symptom (what is visible and bothersome) instead of the cause (what actually produces the problem), and the problem keeps coming back.
2. Cause vs symptom
Distinguishing cause and symptom is fundamental. « Customers complain about delays » is a symptom; the cause may be a poorly organized process, understaffing, a failing supplier.
Treating the symptom (reassuring customers) without treating the cause (the process) fixes nothing durably. The test: if the « solved » problem returns, you treated the symptom.
3. Reframe without a disguised solution
Defining the problem well means reframing it precisely and avoiding slipping in a disguised solution. « We need more staff » presupposes the solution; the real problem may be « how to meet the deadlines? ».
This rigorous framing, often neglected out of impatience, guarantees you solve the right problem. The following tools (5 whys, Ishikawa, 5W1H, reformulation) serve precisely this framing.
🔎 Concrete example — The wrong problem is costly
A complaint about delays: symptom or cause?
Symptom treated: « We reassure unhappy customers. » → others complain.
Cause treated: « Why do the delays slip? » → process revised → no more complaints.Result: treating the cause fixes it durably; the symptom, never.
Reflex: reframe without a hidden answer (« how to meet the deadlines? »).
Section vocabulary
- Problem definition
- The step of precisely framing the real problem, an indispensable prerequisite to any solution search.
Simple example: Sara writes: « the workshop's delays have slipped for two months » before any solution.
What it is not: rushing to solutions for a poorly framed problem.
Reflex: write the problem in one clear, factual sentence before acting.
- Cause vs symptom
- The symptom is visible/bothersome; the cause is what really produces it (treat it to fix durably).
Simple example: complaints (symptom) come from the disorganized process (cause).
What it is not: reassuring customers believing the delays fixed.
Reflex: ask « is this the problem, or its manifestation? ».
- Root cause
- Deep origin of a problem, whose resolution prevents its return.
Simple example: the never-formalized validation process, at the origin of delays.
What it is not: the last visible delay, taken for the origin.
Reflex: check: if I treat it, does the problem return?
- Reframing
- Precisely stating the real problem (without slipping in a disguised solution).
Simple example: « how to meet deadlines? » instead of « we need more staff ».
What it is not: a statement already containing the imposed answer.
Reflex: hunt the hidden solution in the statement and remove it.
- Wrong problem
- A misidentified problem tackled out of haste, leading to useless solutions.
Simple example: hiring urgently when the process is what blocks.
What it is not: the right problem, verified as cause not consequence.
Reflex: check you target THE problem, not another's consequence.
In practice — Defining the problem well
- Resist rushing to solutions: start by framing the problem precisely.
- Distinguish cause and symptom: what is visible/bothersome (symptom) vs what produces it (cause to treat).
- Reframe the real problem without slipping in a disguised solution (« we need more staff » presupposes the answer).
- Check that you're tackling the RIGHT problem (is it THE problem, or the consequence of another?).
Ready-to-say script — frame before seeking (30s)
« Before seeking solutions: the problem is our deadlines have slipped for two months — complaints are the symptom. I rephrase with no hidden solution: how do we meet our deadlines? We check the cause before deciding. »
Say at the start of the meeting: freeze the real problem before any solution idea.
Copy-paste template — framing card
PROBLEM IN 1 SENTENCE (factual): _______________
SYMPTOM (visible, bothersome): _______________
ASSUMED CAUSE (what produces it): _______________
DISGUISED SOLUTION TO REMOVE: _______________
SOLUTION-FREE REPHRASE: how _______________ ?Small business / tight budget
With no formal workshop: one sentence on the board (« how to meet deadlines? ») suffices to prevent drift.
Algerian SME
Complaints received on messaging and at the counter: reread them to separate the symptom (unhappiness) from the cause (process, supplier, schedule).
Team / workshop
Have the team validate the rephrase: if everyone describes a different problem, framing isn't shared.
Project / freelance
Before any corrective quote: have the client write the problem with no solution (« what happens? », not « add this feature »).
✓ Best practices
- Before any solution, write the problem in one clear, factual sentence.
- Ask yourself: « is this the problem, or just its manifestation? ».
- Hunt down the hidden solution in the statement and remove it.
✗ Common pitfalls
- Rushing to solutions without framing the problem.
- Treating the symptom (a patch) instead of the cause (durable).
- Stating the problem with the answer already in it.
Key takeaways
- A well-posed problem is half-solved: framing is the most often botched step.
- Distinguish cause and symptom: treating the symptom without the cause fixes nothing durably.
- Reframe the real problem without embedding a disguised solution.
- Check you're tackling the RIGHT problem, not a consequence of another.
48h Challenge — apply tomorrow
Take 1 real problem and write its framing card (template above): symptom, assumed cause, solution-free rephrase. Test: would the « solved » problem return?
- I tell cause and symptom apart on a real case.
- I rephrase a problem with no disguised solution.
- I did the 48h challenge or planned its date.
Frequently asked questions
Why not rush straight to solutions?
Because it's the best way to solve the wrong problem or treat a symptom that will return. If the problem is poorly defined, all solutions will miss; if you tackle the symptom, the problem reappears; if the statement contains a disguised solution, you lock in. Framing well first (reframe, distinguish cause and symptom, verify the right problem) ensures the effort targets what matters. That time « not looking for a solution » actually speeds up the resolution.
How to know if I'm treating the cause or the symptom?
The symptom is what is visible and felt (complaints, falling sales); the cause is what produces it (a failing process, lack of recognition). The most telling test: if the « solved » problem returns, you treated the symptom. To go up to the cause, use the 5 whys (2.2) or map with Ishikawa (2.3). A symptom is an effect (« X happens »), a cause is a mechanism (« X happens because… »). Digging to the root cause enables durable solutions.
What happens if you treat the symptom and not the cause?