Operators like solvable problems. That is both a strength and a trap.

When a messy problem appears, the instinct is to translate it into something actionable. A customer trust issue becomes “write better docs.” A strategic uncertainty becomes “ship the requested feature.” A morale problem becomes “add a process.” A recurring incident becomes “fix the bug.” A cross-functional conflict becomes “schedule a weekly sync.”

Sometimes the translation is useful. Sometimes it shrinks the problem until the organization can solve the wrong thing with confidence.

Problem definition is the discipline of making the problem actionable without making it false.

The shrinking pattern

Problems get shrunk in predictable ways.

They get shrunk to the team that noticed them. If support hears the complaint, support owns the fix. If engineering sees the incident, engineering owns the issue. If sales hears the objection, sales owns the narrative. The real problem may cross all of them.

They get shrunk to the available tool. If the company likes process, the answer is a process. If it likes product work, the answer is a feature. If it likes analytics, the answer is a dashboard. If it likes management pressure, the answer is accountability.

They get shrunk to what is politically safe. “We need better handoffs” is easier to say than “the executive team has not chosen between enterprise customization and roadmap focus.”

They get shrunk to what can be solved this quarter. A deeper positioning problem becomes a campaign tweak. A broken architecture becomes another patch. A capability gap becomes a heroic sprint.

The result is activity with low truth content: tickets close, customers receive explanations, dashboards update, and the original operating failure remains intact.

Definition needs both symptom and system

A useful problem definition has two layers: the visible symptom and the suspected system.

The symptom is what happened. “Three enterprise customers escalated implementation delays.” “The deployment caused a data mismatch.” “Sales is discounting outside policy.” “The team missed the launch date.”

The system is the context that may be producing it. “Implementation scope is being sold before technical validation.” “Our test environment does not cover this data path.” “Pricing exceptions have unclear decision rights.” “The launch plan had dependencies the owner could not control.”

Do not pretend the system diagnosis is certain too early. But do not ignore it.

A good first definition sounds like: “We have a customer escalation about onboarding delays. The immediate symptom is delayed implementation. The possible deeper issue is a mismatch between what sales promises, what product supports, and what implementation can deliver.”

That definition is actionable without being tiny.

Avoid abstraction as the opposite failure

Do not confuse not shrinking with inflating.

Some operators avoid small definitions by turning every issue into a grand theory. A missed handoff becomes “culture.” A bug becomes “engineering excellence.” A customer complaint becomes “go-to-market alignment.” These may be relevant, but if the definition gets too abstract, no one can act.

The right definition lives at the lowest level that still explains the meaningful pattern.

If one customer misunderstood a setting, fix the docs. If twenty customers misunderstand the setting, inspect product design and onboarding. If enterprise customers repeatedly misunderstand the offering, inspect positioning, sales qualification, implementation, and product promise.

Depth should follow evidence.

Use the “not just” test

A practical way to prevent shrinking is to complete this sentence:

“This is not just ___; it may also be ___.”

This is not just a bug; it may also be a test coverage gap.

This is not just a customer complaint; it may also be a product promise gap.

This is not just a missed deadline; it may also be unclear decision rights.

This is not just low performance; it may also be a role-design problem.

The “not just” test does not mean the larger frame is true. It keeps it visible long enough to inspect.

Define the decision separately

Many problem definitions fail because they mix problem, solution, and decision.

“We need to build feature X” is not a problem. It is a proposed solution.

“The problem is customers cannot complete workflow Y without manual support” is better.

“The decision is whether to fix this with product changes, onboarding changes, services capacity, or narrower customer qualification” is even better.

Separating problem from decision prevents solution lock-in. It also exposes whether the organization is avoiding a tradeoff.

Preserve customer reality

Customer problems are especially easy to shrink into internal categories.

A customer does not care that the issue belongs to product, support, implementation, or legal. They experience one company. If the company defines the problem only according to internal ownership, it may optimize the handoff while missing the customer reality.

Sanjit Biswas’s customer-loop lesson is relevant here: start with the customer’s world, not the technology or internal structure. What is the customer trying to accomplish? Where are they blocked? What did they believe would happen? What made that belief reasonable?

Then map the internal cause.

The definition checkpoint

Before solving, ask:

  • What happened?
  • Who is affected?
  • What is the cost if it continues?
  • Is this isolated or patterned?
  • What are we assuming?
  • What would be the too-small definition?
  • What would be the too-grand definition?
  • What decision does this definition imply?

The output should be a problem statement, not a manifesto. A practical format is: symptom, affected population, suspected system, decision needed, immediate containment, reopen trigger.

Example: “Enterprise onboarding is slipping for complex customers because implementation scope is being committed before product and services validate feasibility. Immediate containment: review the five active accounts. Deeper decision: define who can approve non-standard implementation commitments.”

That is a problem you can operate on.

Good definition does not make problems smaller. It makes them true enough to solve.