The problem behind the problem

Teams arrive with solutions already chosen. Slow reporting needs a new BI tool. Customer churn needs AI. Handoffs need a workflow platform. The symptom is real. The proposed category is often wrong. Investment follows the symptom. The underlying problem — definition, ownership, incentive, capacity — remains, now with a larger bill.

Finding the problem behind the problem is not philosophy. It is a discipline that saves quarters. Constrange uses a simple ladder: surface symptom, intermediate cause, root constraint. You climb until moving down one more level would change the category of solution — or reveal that no technology is required.

This framework is for rooms where budget and attention are finite. It produces a named problem, a non-goal, and a first move small enough to test whether you climbed far enough.

Three layers of problem

Surface symptom: what people feel day to day — slow, wrong, manual, risky. Intermediate cause: structural reasons the symptom persists — data in three places, no owner, conflicting metrics. Root constraint: what will not move this year without a political or design choice — definition of customer, decision rights, stop list.

How to climb the ladder

Questions that go deeper

1. If we fixed this tomorrow with a perfect tool, what would still stall?
2. Who benefits if the symptom stays?
3. What unofficial path exists because the official one fails?
4. What definition are we arguing about without naming it?
5. What would we stop doing if this were truly solved?

Stop climbing when the next answer implies a non-technology move you are willing to make — or when technology is clearly the bottleneck with owned data and agreed rules.

• Symptom language uses adjectives: slow, messy, siloed.
• Intermediate language uses nouns without owners: data, handoff, policy.
• Root language uses choices: we will not agree, we will not stop, we will not fund.

Common traps

Category trap: every problem becomes 'we need AI' or 'we need a platform'. Vendor trap: the demo defines the problem. Hero trap: one expert carries the join — removing them reveals there was no process. Measurement trap: you optimise what is easy to count, not what matters.

Testing whether you found the root

A root problem passes four tests. Operations recognises it without translation. A constraint is visible in the sentence. Non-goals are writable. A first move exists that does not require the whole estate to change.

Run a thirty-day move against the root. If the symptom barely moves, climb again or admit the constraint is immovable and choose risk explicitly.

First move design

• One team, one object, one definition change.
• Measure reconciliation time or error rate, not slide count.
• Owner with weekly forum accountability.
• Document what you will not fund while this runs.

“Solve the problem behind the problem, or fund the symptom again next year under a new vendor logo.”Constrange

Using the framework in procurement

Require a problem ladder in every business case. Ask vendors to respond to the root, not only the symptom. If they cannot, they are selling category. Reject RFPs that skip non-goals.

Constrange facilitates this climb in the first conversations, before signature. The problem behind the problem is where spend becomes honest — or stops.

Workshop format that works

Two hours, right people: operations, finance, technology, one sponsor. Write symptom on wall. Ask 'what would still break if tool were perfect?' Repeat until constraint language appears. End with one first move and non-goals. No vendor in room one.

Short workshops beat long discovery phases when the goal is investment honesty, not documentation volume.

When to stop climbing

Stop when the next layer is immovable politics you are not willing to fund, or when technology is clearly the bottleneck with agreed rules and owners. Climbing forever is avoidance dressed as rigour.

Document the layer you stopped at and the risk accepted. That is adult decision-making.