Contents
What This Tool Does
How to Use It — Step by Step
State the specific, observable event that triggered the analysis
Enterprise SaaS churn
Look for trends, recurring behaviours, and repeated sequences
Patterns beneath the churn
Map the systems, policies, incentives, and resource allocations that produce the patterns
Structures driving enterprise churn
Identify the beliefs, assumptions, and values that created and sustain those structures
Mental models beneath the structures
Decide where to intervene based on leverage, not urgency
Intervention strategy
When It Works Best
Ideal Conditions for the Iceberg Model
| Dimension | Best fit |
|---|---|
| Problem type | Recurring problems that resist event-level fixes. If the same type of failure keeps happening despite repeated interventions, the Iceberg Model is precisely the right diagnostic — it's designed to explain why your solutions aren't working by revealing that you've been solving at the wrong depth. |
| Organisational maturity | Teams willing to examine their own assumptions. The model's deepest layer — mental models — requires a degree of psychological safety and intellectual honesty that not every culture possesses. If the leadership team treats structural critique as personal attack, the analysis will stall at the pattern level. |
| Time horizon | Situations where you need durable change, not a quick patch. The model is slow medicine. It won't help you respond to a crisis in the next 48 hours. It will help you understand why you keep having the same crisis every six months. |
| Complexity | Problems embedded in organisational systems — incentive misalignments, cultural drift, process debt, strategic contradictions. Less useful for purely technical failures with clear mechanical causes. If a server crashed because of a memory leak, you don't need four layers of analysis. If servers keep crashing because the engineering culture deprioritises infrastructure, you do. |
| Stakeholder diversity | Most powerful when the analysis includes people from different levels and functions. Frontline employees often see structural problems that executives have normalised. Executives understand the mental models that frontline staff have never been exposed to. The iceberg is best excavated from multiple vantage points simultaneously. |
| Decision stage | Early diagnosis — before committing to a solution. The Iceberg Model is a sense-making tool, not an action-planning tool. Use it to understand the system before you redesign it. Deploying it after you've already committed to a fix is an exercise in confirmation bias. |
When It Breaks Down
Failure Modes
| Failure pattern | What goes wrong | What to use instead |
|---|---|---|
| Analysis paralysis at depth | Teams become so fascinated by the mental model layer that they never act. The philosophical discussion about "what we believe" becomes an end in itself. Meanwhile, the fourth enterprise customer churns. Deep understanding without timely intervention is an expensive form of therapy. | Set a time-box. Use the Eisenhower Matrix to separate urgent event-level responses from important structural work. Do both. |
| Pseudo-depth | The team labels surface-level observations as "structures" and obvious truisms as "mental models." "We don't have enough resources" is not a structural insight — it's a complaint. "We believe growth is more important than retention" might be a mental model, but only if it's actually driving resource allocation decisions. Depth requires specificity. | Apply the 5 Whys at each layer to test whether you've actually gone deeper or just rephrased the same observation. |
| Single-event application | Using the Iceberg Model on a genuinely one-off event that has no pattern beneath it. Not everything is systemic. Sometimes a customer churns because their budget got cut. Sometimes a launch fails because of bad timing. The model assumes recurring patterns exist — if they don't, the analysis manufactures false depth. | Start with pattern verification. If you can't find at least three instances of the event recurring, the Iceberg Model may be overkill. Use an Ishikawa Diagram for isolated incidents. |
| Blame laundering | The mental model layer gets weaponised: "The real problem is that leadership believes X." This is often true. It's also often used to deflect accountability upward while avoiding structural changes that the team could implement without executive permission. The iceberg becomes a sophisticated way to say "it's someone else's fault." | Require each layer to include at least one intervention the team can own directly. Structural changes don't always require executive approval. |
| Missing feedback loops | The Iceberg Model presents layers as a static hierarchy. In reality, events reinforce mental models ("see, I told you enterprise customers are demanding"), mental models shape structures, and structures generate events. The model doesn't capture these circular dynamics. | Pair with Causal Loop Diagrams or Connection Circles to map the feedback loops between layers. |
| Unfalsifiable mental models | The "mental model" layer can become a repository for unfalsifiable assertions. "We believe speed matters more than quality" — how would you test that? If the mental model can't be observed in specific decisions and policies, it's speculation, not diagnosis. | Require every mental model to be linked to at least two observable structural decisions it explains. If you can't point to the structure it created, you haven't found a mental model — you've found a narrative. |
Visual Explanation
Pairs With
Real-World Application
NHS England — understanding persistent A&E waiting time failures
Analyst's Take
Top Resources
Why this matters next
5 Whys applied the Incentives mental model
5 Whys applied the Second-Order Thinking mental model
5 Whys applied the Confirmation Bias mental model
5 Whys applied the Leverage mental model
5 Whys applied the 5 Whys mental model
5 Whys applied the Systems Thinking mental model
Continue exploring
Decision tool
5 Whys
Drill vertically into a single causal chain by asking why repeatedly until you h
Decision tool
Ishikawa Diagram
Map all potential causes of a problem across categories to see the full landscap
Decision tool
Pareto Analysis
Identify the 20% of causes responsible for 80% of the impact — know where to foc
Decision tool
Issue Trees
Break a complex problem into smaller, mutually exclusive, collectively exhaustiv
Decision tool
First Principles Thinking
Strip away assumptions and inherited wisdom to rebuild understanding from fundam
More like this, in your inbox
I send a newsletter every week — free, no spam, unsubscribe anytime.