The fastest way to solve the wrong problem is to skip classification.
A signal appears: a customer is angry, a dashboard moves, a project slips, a leader complains, a bug escapes, a team feels blocked. The organization immediately starts solving. Someone opens a ticket. Someone writes a plan. Someone escalates. Someone proposes a meeting. Someone declares the cause.
This feels efficient because motion starts quickly. It is often waste.
Before asking “what should we do?” ask “what kind of problem is this?” The answer changes everything: who should own it, how much analysis it deserves, whether speed matters, what evidence is needed, and whether the next step is a fix, a decision, research, an experiment, or escalation.
Common problem types
A problem can be an incident. Something is broken right now. The priority is containment, restoration, communication, and then learning. The first move is not philosophical clarity. It is stopping damage.
A problem can be a decision. The facts may be good enough, but the organization is avoiding a tradeoff. More analysis will not help if no one owns the call.
A problem can be an unknown. The team lacks evidence. A solution would be mostly confidence theater. The next step is research or discovery, not commitment.
A problem can be an execution gap. The plan is right, the owner is clear, the work is understood, but follow-through is weak. This needs management, standards, capacity, or accountability.
A problem can be a process failure. Work is falling between functions, handoffs are unclear, decision rights are foggy, or the operating cadence does not surface reality early enough.
A problem can be a people problem. Trust is broken, incentives are misaligned, a leader is avoiding conflict, or a team cannot say the true thing safely.
A problem can be a strategy question. The company may be doing the wrong work, serving the wrong segment, betting on a weak assumption, or optimizing a local metric that no longer matters.
A problem can be a customer escalation. It may need immediate service recovery, but it may also reveal a product promise the company cannot keep.
These are not academic categories. They determine the work.
The classification error
Companies often classify problems according to the team that first receives the signal.
If support hears it, it becomes a support problem. If engineering sees it, it becomes a bug. If product hears it, it becomes roadmap input. If sales feels it, it becomes urgency. If finance notices it, it becomes budget discipline. If executives hear it, it becomes strategic.
The first receiver is not always the right classifier.
A customer complaining about onboarding may not be a customer success problem. It may be a product complexity problem, a sales qualification problem, an implementation capacity problem, or a pricing-packaging problem that attracts the wrong buyer.
A missed launch may not be an engineering execution problem. It may be unclear scope, weak decision rights, late executive changes, or a dependency no one owned.
A performance issue may not be an individual issue. It may be a role-design issue, a manager issue, or a goal that no capable person could have delivered.
Classification prevents the organization from shrinking the problem into the nearest available tool.
The operator should explicitly mark the first classification as provisional. “Initial classification: customer escalation with possible product-promise gap.” That phrasing leaves room for evidence without letting the first receiving team silently own the entire problem.
A five-minute classification pass
For most problems, the first classification pass can be quick. Ask:
- Is something currently broken or at risk of immediate damage?
- Is the problem mainly a decision, an unknown, an execution gap, a process failure, a people issue, a strategy question, or a customer escalation?
- What is the visible symptom?
- What would be dangerous to assume?
- Who is closest to the evidence?
- Who has authority to act?
- What happens if we do nothing for 24 hours?
If there is immediate customer, security, legal, revenue, or trust risk, contain first. Classification does not mean standing around while the building burns.
But even during containment, name the likely category. “We are treating this as an incident now; after restoration we need to determine whether it is a repeated architecture issue.” That sentence saves a lot of confusion later.
Classification changes ownership
A decision problem needs a decision owner. A research problem needs an investigator. An experiment needs a designer and a learning loop. An incident needs an incident commander. A process problem needs someone with authority over the handoffs. A people problem needs the accountable manager, not a passive working group.
Misclassification creates fake ownership.
If a cross-functional decision is assigned to a project manager with no authority, they can coordinate forever and still not solve it. If a strategy question is assigned to a team as an execution task, they will produce activity while the real tradeoff remains unmade. If a people problem is converted into process, the company gets more rules and less honesty.
The owner should match the problem type.
Classification also changes pace
Incidents move fast. Strategic bets move slower. Known bugs can move fast. Unknown failure modes need diagnosis. Reversible process changes can be tried. Expensive-to-reverse org changes deserve more care.
One of the reasons companies feel chaotic is that everything receives the same urgency language. Every problem is “critical.” Every request is “ASAP.” Every customer escalation is “strategic.” Every executive concern becomes a priority.
When everything is urgent, nothing is classified.
A useful operator creates different lanes:
- restore now;
- decide by Friday;
- investigate this week;
- experiment for two cycles;
- escalate today;
- stop or park.
Each lane should carry a visible artifact: incident channel and rollback owner, decision memo, research brief, experiment plan, escalation note, or stop record. The lane matters as much as the task.
Classification is not delay
The objection is predictable: “We do not have time to classify. We need to solve.”
Sometimes true. Usually incomplete.
Classification is not a two-day workshop. It is the discipline of not confusing the first plausible fix with the real work. The smaller the problem, the lighter the classification. The bigger the blast radius, the more dangerous it is to skip.
A good operator can classify in motion. “This looks like a known failure mode. We will rollback now. If it recurs, we open a deeper investigation.” Or: “This looks like a decision-rights issue, not a lack-of-effort issue. I am going to get the two accountable leaders in a room and force the tradeoff.”
That is not bureaucracy. That is speed with aim.
The test
After the first classification, state the problem type out loud:
“This is an incident with a known rollback.”
“This is a repeated customer escalation that may expose a product promise gap.”
“This is a decision masquerading as analysis.”
“This is an execution gap caused by unclear ownership.”
“This is an unknown, and we need evidence before we commit.”
“This is a people problem hiding inside process complaints.”
If the room cannot agree on the type, that disagreement is useful. It means the organization was about to start solving different problems under the same label.
Classify first. Then solve at the right depth.
