“Sales are down because the Sales team is underperforming.”
“Complaints are up because Service quality is worse.”
“Profit is down because costs are too high.”
These statements sound like explanations.
Sometimes, however, they simply connect a visible outcome with the first plausible cause that comes to mind.
If the supposed Cause is actually another Symptom, the chosen solution may provide temporary relief or solve nothing.
If Sales decline because products are out of stock, for example, increasing Advertising may generate more Traffic while customers remain unable to purchase.
Before asking: “How do we fix it?”
ask: “What exactly is the problem, and where does it sit in the cause-and-effect chain?”

What happened is not necessarily what caused it
If Sales decline, the first confirmed fact is simply:
Sales declined. You do not yet know whether the reason is:
1. Fewer New Customers
2. Lower Repeat Purchase
3. Lower Average Order Value
4. Price or Promotion changes
5. Stock Availability
6. Competitor activity
7. Seasonality or weaker market demand
Avoid moving directly from: Observation → Solution
Use: Observation → Problem Definition → Possible Causes → Evidence → Root / Contributing Causes → Action
And remember that complex business problems can have more than one meaningful cause.

What is the difference between a Symptom, Cause and Root Cause?

A Symptom is an observable sign that something is wrong.
Examples:
Sales decline
Conversion falls
Complaints increase
Delivery slows
Employee Turnover rises
‍
A Cause is a factor contributing to that outcome.
For example, lower Conversion could be related to:
Traffic Quality
Price
Landing Page Performance
Stock Availability
Payment Failure
A Root Cause is a deeper issue that initiates or sustains the cause-and-effect chain and whose correction has a reasonable chance of preventing recurrence.
ASQ defines a Root Cause as the core issue that sets the cause-and-effect sequence in motion and notes that complex problems can have multiple Root Causes.
Do not assume every problem must have one single ultimate cause.

First, write the Problem Statement without inserting an unproven explanation

Compare:
Avoid: “Sales are falling because the Sales team cannot close.”
The explanation has already been embedded inside the Problem Statement.
Better: “June Revenue declined 15% compared with the previous three-month average, with the largest decline among New Customers from the Online Channel.”
Now the statement contains:

• Metric
• Magnitude
• Time
• Comparison
• Segment

without pretending the Cause is already known.
ASQ's problem-solving guidance similarly emphasizes defining and narrowing the problem before Root Cause Analysis.

An Observation is not an Explanation

Suppose a Dashboard shows:
Sales -20%
Website Traffic -5%
Conversion Rate -18%
You can state:
FACT: Conversion Rate and Sales both declined.
You cannot yet state: “Conversion caused the Sales decline.”
Conversion itself may be a Symptom of:
Price
Out-of-stock items
Poor Traffic Mix
Checkout Errors
Competitor Promotions
Product Mix changes
BEE Research Knowledge makes the same distinction in Driver Analysis: an observed association is not automatic causation.
When one metric moves with another, ask: “What changed upstream of this metric?”

Use the 5 Whys to dig deeper, but do not stop simply because you reached five

Example:
Problem: Orders declined.
Why?
→ Conversion declined.
Why did Conversion decline?
→ Checkout abandonment increased.
Why did abandonment increase?
→ Payment failures increased.
Why did Payment Failure increase?
→ One payment gateway was producing errors.
Why was the issue not detected earlier?
→ Monitoring did not generate an alert.
Here:
Orders declining is a Symptom.
Conversion declining is also a Symptom.
Even Payment Failure may be an Intermediate Cause.
The actionable Root Cause may sit in the payment infrastructure or monitoring process.
ASQ describes the 5 Whys as a technique for peeling through layers of symptoms and explicitly notes that a problem may require fewer or more than five Why questions.

But 5 Whys has a limitation: One person can easily reason toward the Cause they already believe

The simplicity of 5 Whys is useful.
It can also create false confidence.
A weak process looks like:
Ask Why
Invent an answer
Ask Why again
Declare the last answer the Root Cause
‍
ASQ has highlighted Confirmation Bias in Root Cause Analysis and the need to consider system complexity, alternative causes and evidence at each step.
For the same Sales decline:
Marketing may blame slow Sales follow-up.
Sales may blame Lead Quality.
Operations may blame Stock.
Each team begins with a different Mental Model.
Use 5 Whys to generate Candidate Causes. Then test them.

If something is truly causal, the observed pattern should be consistent with it

Suppose the hypothesis is: “Sales declined because of the Price Increase.”
Check:

• Did the decline begin after the Price Change?
• Did SKUs with larger increases fall more?
• Did Price-sensitive Segments decline more?
• Did Conversion fall when customers encountered the new Price?
• Did competitor pricing change at the same time?
• How did Units, Revenue and Margin change together?

If Sales began falling two months before the Price Increase, the hypothesis becomes weaker.
A basic requirement is: A Cause must occur before its Outcome.
Temporal ordering does not prove causality by itself, but a factor occurring after an outcome cannot have caused that earlier outcome.

Segment the problem before trying to explain it

An overall average can make a problem look broader than it is. Suppose Total Sales fall 10%.
Segment:
Existing Customers = stable
New Customers = -25%
Segment again:
Organic = stable
Referral = stable
Paid Search = -40%
The problem is now much narrower.
Instead of: “Company Sales are broken.”
the team can investigate: “New Customer acquisition from Paid Search has declined.”
Narrowing the problem dramatically reduces the number of plausible causes, which is why ASQ's advanced problem-solving guidance emphasizes narrowing before causal analysis.

Do not stop at the Cause that is easiest to fix

Imagine complaints rise sharply.
The team discovers long Call Center waiting times.
It hires more agents.
Complaints fall temporarily.
Three months later, they increase again.
A deeper analysis finds:
Customers call because invoices are wrong
Invoices are wrong because Pricing Rules are complex
Pricing Rules are complex because multiple Promotions overlap
Adding Call Center staff addressed a Capacity Symptom.
It did not remove the source creating the calls.
Ask: “If we fix this factor, will the mechanism producing the problem disappear or will we simply handle the consequences better?”

The Root Cause is not necessarily the deepest possible explanation

A 5 Whys exercise sometimes ends with:
“Company culture.”
“Management.”
“The system.”
Those explanations may be so broad that they cannot be tested or acted on.
A useful Root Cause should be:

• Supported by evidence
• Logically connected to the problem
• Specific enough for action
• Capable of reducing recurrence
• Clear enough to test

“Root” does not mean digging indefinitely. It means reaching a causal level that is useful for solving the problem.

Build a Cause Tree instead of searching for one explanation

Business problems are often multi-causal.
Suppose:
Gross Profit declines
Possible branches include:

Revenue Side

Price ↓
Discount ↑
Low-margin Product Mix ↑

Cost Side

Supplier Cost ↑
Waste ↑
Freight ↑

Data / Accounting Side

COGS allocation error
Inventory error
Period mismatch
Instead of asking: “What is the Cause?”
ask: “Which Cause Categories are plausible, and which does the evidence support?”
This reduces the risk of anchoring on the first explanation.

Correlation can identify a Candidate Cause, but it does not confirm a Root Cause

Suppose employees with more Training Hours have higher Sales.
You might hypothesize:
Training improves Sales.
But alternative explanations include:
High performers receive more Training
Better Managers create both more Training and higher Sales
Senior Staff receive more Training
Territories differ
Correlation is useful for identifying a:
Candidate Driver
not automatically a:
Confirmed Cause
For important decisions, stronger evidence may require:
Experiments
Natural Experiments
Before–After with a comparison
Regression with appropriate controls
Or several evidence sources pointing in the same direction

If the problem improves after the fix, have you definitely found the Root Cause?

That is stronger evidence, but still not automatic proof.
Suppose Checkout is redesigned and Conversion improves.
At the same time:
A Promotion launches
Traffic Quality improves
Seasonality changes
The improvement may have several contributors.
ASQ includes verification of corrective-action effectiveness as part of Root Cause Analysis.
After implementation, check:

• When did the metric improve?
• Did it improve in the Segment expected to be affected?
• What happened in a comparison group?
• Did the improvement persist?
• Did the original problem recur?

Example: Are rising customer complaints a Cause or a Symptom?

Suppose:
Complaints +40%
Jumping directly to:
“The Service team is underperforming.”
is premature.
Break the data down:
Complaint Topic:
Delivery 55%
Payment 15%
Product 10%
Other 20%
Delivery Complaints:
Late delivery 80%
Late Delivery:
Concentrated in Bangkok East
Operations Data:
On-time Delivery fell after a Route Planning change
The investigation now points toward a Routing Process hypothesis rather than a general Service Attitude problem.
The path becomes: Complaints ↑ → Delivery Issue → Bangkok East → Route Change → Test Routing Hypothesis
not: Complaints ↑ → Train everyone

Employee Turnover can also be a Symptom

High Turnover can have several causes:
Compensation
Manager
Workload
Career Path
Shift Schedule
Location
Hiring Fit
Seasonality
Raising salaries immediately may increase Cost while leaving Turnover unchanged.
Investigate:
Turnover by Team
Tenure
Manager
Role
Shift
Exit Reasons
Engagement
Absence before departure
Then generate competing hypotheses.
The same logic applies to Sales, CX, Operations and People problems.

Seven practical questions for separating Cause from Symptom

When you see a problem, ask:

1. Is what we see an Outcome or already an Explanation?
2. Is the problem defined clearly by Metric, Time, Segment and Comparison?
3. Do we have at least two or three plausible alternative causes?
4. Did the candidate Cause occur before the problem?
5. Is the problem worse where that Cause is stronger?
6. Which Alternative Explanations have not yet been ruled out?
7. If we change this Cause, which metric should change, and how will we verify it?

If several of these questions remain unanswered, avoid calling the factor a Root Cause.
Call it a: Hypothesis until the evidence is stronger.

Good Problem Framing should end with hypotheses, not an immediate solution

Instead of:
Problem: Sales are declining
Solution: Increase Promotions
write:
Observation: New Customer Revenue declined 18%.
Where: Paid Search.
When: Beginning in Week 2.
Possible Causes:

• Traffic Quality changed
• Competitor Promotion
• Landing Page Conversion declined
• Product Availability
• Tracking Error

Evidence Needed:
Search Query Mix
Conversion by Landing Page
Stock Availability
Competitor Price
Tracking QA
Now the team knows what to investigate before spending money.
This mirrors BEE's Insight Framework: Observation → Pattern → Tension → Why → Business Implication → Further Test

The takeaway: Do not fix what you see until you know where it sits in the Cause Chain

Symptoms are useful.
They tell you where to start looking.
They should not automatically become the Root Cause.
When you observe:
Sales declining
Complaints rising
Margins falling
Churn increasing
Turnover increasing
first ask:
What exactly happened?
Where did it happen?
When did it begin?
Who or which Segment is affected?
What are the plausible causes?
What evidence supports or contradicts each one?
Then decide what to fix.
The more useful question is not only:
“How do we solve this problem?”
It is: “How confident are we that the thing we are about to fix is actually helping create the problem?”
Answering that question well reduces the risk of spending money treating Symptoms while leaving the underlying mechanism intact.