You solve the problem you were given, and nothing changes.

A company asks for a new CRM configuration. Adoption is low. A team asks for a new quoting process. Reps go back to the old way within a month. A client asks for better reporting. Nobody looks at the dashboards. The work was good. The solution addressed the stated problem. The stated problem was not the actual problem.

This isn’t because people are dishonest. The real problem is usually invisible, even to the person experiencing it. What they can articulate is the surface. What’s blocking progress is something deeper, something they haven’t named yet.

Two types of problems

Surface problems are visible and feel solvable: “Our quoting process is too slow.” “Our CRM data is unreliable.” Real problems with real impact. Shadow problems are hidden beneath them — the reason the surface problem keeps coming back.

A company says the problem is quote turnaround. The shadow problem is that three senior reps have built their value around being the only ones who know the pricing rules, and a CPQ system threatens their position. A team says the problem is low CRM adoption. The shadow problem is that the sales manager never looks at the CRM, so there’s no consequence for not using it. A client says the problem is poor handoff between sales and delivery. The shadow problem is that the two teams fundamentally distrust each other after a failed project two years ago that nobody has talked about since.

Shadow problems share a common trait: they involve people’s fears, sense of identity, or loss of something they haven’t consciously named.

flowchart TD
    S["<b>Surface problem</b><br/>Visible, acceptable<br/>to discuss"] --> F["Obvious fix"]
    F --> X{"Does the problem<br/>come back?"}
    X -->|"No"| Done["You solved<br/>the real issue"]
    X -->|"Yes"| Clues["Look for clues<br/>repetition, emotion,<br/>missing loss"]
    Clues --> Shadow["<b>Shadow problem</b><br/>Fear, identity,<br/>control, trust"]
    Shadow --> Real["Solve at<br/>the real depth"]

Why we keep solving the wrong problem

Surface problems are socially acceptable to discuss. Nobody gets uncomfortable when you say “our quote turnaround is too slow.” People get very uncomfortable when you say “your team hoards knowledge because they’re afraid of becoming replaceable.”

The result is predictable. Organizations cycle through the same crises. Projects go live and silently fail. The surface problem gets “solved” and comes back wearing a different name. Last year it was “we need a new CRM.” This year it’s “we need better data.” Next year it’ll be “we need AI.” The shadow problem hasn’t moved.

How to find the shadow problem

The first clue is repetition. A company on its third CRM implementation in ten years doesn’t have a CRM problem. The question isn’t “which CRM is right?” It’s “why doesn’t any CRM stick?”

The second is disproportionate emotion. When a rational discussion produces an irrational reaction, you’ve probably touched the shadow problem. I once presented a straightforward process redesign and watched the room go cold. What I’d unknowingly done was suggest removing the step that one senior person had spent five years building and that defined their role.

The third is the missing loss. Shadow problems almost always involve something that has ended or is about to end — a way of working, a role, a sense of control. Ask: what has this person had to give up that nobody has acknowledged?

The diagnostic question I keep coming back to: “What would need to be true for the obvious solution to not work?” The answers are rarely technical. They’re political, emotional, or cultural. “It wouldn’t work if the sales director doesn’t actively support it.” Those are shadow problems — and now they’re on the table.

The skill isn’t just problem definition. It’s problem depth — asking whether what you’re looking at is the real problem, or its more visible proxy.

When things don’t move despite good analysis and clear solutions, that’s the signal. Something important is hiding just below the surface. The shadow problem doesn’t show up in the project brief. But it determines whether the project brief matters.