Imagine this: your car battery goes dead one morning. You call a tow truck, get the battery replaced, and drive away feeling like you have solved the problem. Two weeks later, the same thing happens again. And again. After the third replacement, your mechanic finally looks deeper and discovers the real culprit—a faulty alternator that was slowly draining every new battery you installed. You were not solving a problem. You were repeatedly treating a symptom.
This is one of the most common and expensive mistakes humans make—in everyday life, in business, and especially in engineering. We rush to fix what is visible and painful without ever pausing to ask: what is actually causing this? Problem identification, done properly, is the discipline of slowing down long enough to find the right answer to that question before you start spending time, money, and effort on solutions.
What Is a Problem, Really?
In engineering and design, a problem is defined as the gap between the current state and the desired state. It is not simply “something is broken.” It is the measurable, specific difference between where you are and where you need to be.
A common trap is confusing a symptom with the problem itself. Symptoms are the observable effects of an underlying cause. They are what you see, hear, or feel. The actual problem is buried deeper. Consider these examples:
Symptom (what you see)
- Car battery keeps dying
- Students scoring poorly on exams
- A pipe is leaking water
- Factory production line stops frequently
Root Cause (the real problem)
- Faulty alternator draining the battery
- Confusing teaching method, not student laziness
- Corrosion from unfiltered sediment in the water supply
- Inadequate lubrication schedule causing bearing wear
If you only ever address the symptom column, you are on a treadmill—busy, exhausted, and going nowhere.
The Power of Asking “Why?” Five Times
One of the most elegant and widely used tools in problem identification is the 5 Whys technique, developed by Sakichi Toyoda and made famous by the Toyota Production System. The concept is beautifully simple: when you encounter a problem, you ask “Why did this happen?” and then—critically—you ask why again for the answer you just received. You keep going until you reach the root cause. Most of the time, five iterations is enough.
Let us walk through a real-world example. Say you are a maintenance engineer at a manufacturing plant, and one of your machines has just broken down on the production floor.
| Why # | Question | Answer |
|---|---|---|
| Why 1 | Why did the machine break down? | Because a bearing seized up. |
| Why 2 | Why did the bearing seize up? | Because it was not lubricated properly. |
| Why 3 | Why was it not lubricated properly? | Because the technician skipped that step during maintenance. |
| Why 4 | Why did the technician skip the step? | Because the maintenance checklist was incomplete and did not include it. |
| Why 5 | Why was the checklist incomplete? | Because the standard operating procedure was never updated after the machine was upgraded two years ago. |
Look at where we started versus where we ended. If you had simply replaced the bearing and re-lubricated it (fixing the symptom), the machine would have seized again within months. The real fix is updating the standard operating procedure—a systemic, permanent solution. That is the difference between a firefighter and an engineer.
The 5 Whys are not always exactly five. Sometimes you find the root cause at the third why. Other times, a complex problem might need seven or eight iterations. The number is a guide, not a rule. The principle is: keep digging until you hit something actionable and fundamental.
The Fishbone Diagram: When One Why Leads to Many
The 5 Whys works beautifully for problems with a single chain of cause and effect. But many real-world problems are more like a tangled web—several different contributing causes all feeding into the same nasty outcome. This is where the Fishbone Diagram (also called an Ishikawa Diagram, after its inventor, Professor Kaoru Ishikawa) comes in.
The structure looks like the skeleton of a fish. The head of the fish is your problem statement. The spine runs horizontally toward it, and branching off the spine like ribs are the major cause categories. The most common categories in an engineering context are:
Each branch forces you to think systematically about all the possible contributors to a problem, rather than jumping to the most obvious one. It is a remarkably effective team exercise because it externalises assumptions—things one person takes for granted might be exactly what another person identifies as the real issue.
Writing a Problem Statement That Actually Means Something
Once you have identified your root cause, you need to articulate it clearly. A good problem statement is the foundation on which your entire design or research project is built. It must be specific, verifiable, and honest about the gap it describes. A weak problem statement produces vague solutions. A precise one guides every decision that follows.
A useful framework is to build your problem statement around five anchoring questions:
-
Who is affected? Identify the people, systems, or processes experiencing the problem. Not just “users,” but specifically which users, under which conditions.
-
What is the problem? State the gap. What is happening that should not be, or what is not happening that should be? Quantify it whenever possible.
-
When does it occur? Is the problem constant or intermittent? Under what conditions does it appear? Timing often reveals causation.
-
Where does it happen? Is it localized to a specific machine, process, location, or system component? Boundary conditions matter enormously in engineering.
-
Why does it matter? Quantify the impact. What are the costs—in downtime, safety risk, money, efficiency loss—if this problem is left unsolved? This is what justifies the investment in a solution.
Compare these two problem statements for the same situation:
Weak: “The cooling system is not working well and causes problems.”
Strong: “The heat exchanger in Unit 3 of the cooling loop loses 18% of its rated thermal efficiency during peak summer operation (ambient > 35°C), causing the downstream compressor to overheat and trip the safety interlock, resulting in an average of 4.2 hours of unplanned downtime per week and an estimated RM 12,000 in lost production monthly.”
Both describe the same cooling system. But only the second one gives an engineer—or a grant reviewer—enough to actually do something about it.
Why Engineers Must Do This First
In engineering design, this is not just a nice intellectual exercise. It is the mandatory first step. The engineering design process begins with problem identification because everything else—conceptual design, prototyping, testing, optimization—is predicated on having the right target. Building the most elegant solution to the wrong problem is not engineering. It is expensive art.
Consider the history of engineering failures that were actually problem identification failures. The Challenger Space Shuttle disaster—at its root—was not an O-ring failure. It was a failure to correctly identify and act on a known risk at low temperatures. Engineers had raised concerns. The root cause was a systemic problem in organizational decision-making, not just a rubber seal.
Closer to home and to everyday experience: how many campus projects, business initiatives, or even personal decisions have failed not because the execution was poor, but because the team spent months solving a problem that was never actually the core issue?
A Habit of Mind, Not a One-Time Tool
The 5 Whys, the Fishbone Diagram, and the structured problem statement are not checklists to tick before moving on to the “real” work. They are habits of mind. The best engineers, researchers, and designers I have encountered share a common trait: a deep and genuine reluctance to accept the first explanation they are given. They probe. They question comfortable assumptions. They are comfortable sitting in uncertainty a little longer than most, because they know that clarity at the problem-definition stage saves enormous pain downstream.
The next time something goes wrong—whether it is a leaking pipe, a failed experiment, a project that keeps running over schedule—resist the urge to fix the first thing you can touch. Ask why. Then ask why again. You might be surprised how far down the rabbit hole the real answer lives.