Contents
Use this when two sides of a decision seem locked in direct opposition — when "we can either do A or B, but not both" feels like an iron law. The Conflict Resolution Diagram, also called the Evaporating Cloud, maps the hidden assumptions beneath each position and systematically invalidates them, turning apparent either/or deadlocks into solvable problems.
Section 1
What This Tool Does
Every organisation has conflicts that feel permanent. Ship fast or ship quality. Invest in growth or protect margins. Centralise for efficiency or decentralise for speed. These dilemmas recur in strategy meetings, board discussions, and founder arguments with a grinding regularity that suggests they're structural features of the business — tradeoffs baked into the physics of the situation. Most teams respond by compromising: split the difference, give each side half of what it wants, revisit in six months. The compromise satisfies nobody, solves nothing, and the same argument resurfaces at the next offsite with slightly different vocabulary.
Eliyahu Goldratt saw this pattern everywhere he looked. A physicist by training who wandered into manufacturing consulting in the 1980s, Goldratt had an outsider's impatience with the way business people accepted contradictions. In physics, when two models predict contradictory outcomes, at least one model contains a flawed assumption. The contradiction isn't real — it's a signal that your understanding is incomplete. Goldratt applied this logic to organisational conflicts and built a tool he called the Evaporating Cloud, later formalised as the Conflict Resolution Diagram within his Theory of Constraints framework. The name is precise: the conflict doesn't get resolved through negotiation or compromise. It evaporates — ceases to exist — once you find and invalidate the assumption that was making it appear real.
The mechanism is elegant. You map five elements: a shared objective both sides actually agree on, two necessary conditions (the needs each side is trying to protect), and two prerequisites (the specific actions each side insists on, which are in direct conflict). Then — and this is where the tool earns its keep — you surface the assumptions connecting each element to the next. Why does Need A require Action D? What would have to be true for that link to hold? The assumptions are usually unstated, often unconscious, and frequently wrong. The core insight: conflicts between intelligent people almost never stem from incompatible goals. They stem from unexamined assumptions about the only way to achieve those goals. When you find the faulty assumption and invalidate it, the conflict doesn't need to be managed. It disappears.
This is fundamentally different from negotiation, which accepts the conflict as real and seeks an acceptable distribution of losses. It's different from compromise, which gives each side less than it needs. And it's different from escalation, which lets a senior leader pick a winner. The Evaporating Cloud is the only common decision tool that treats the existence of the conflict itself as a diagnostic signal — evidence that someone, somewhere, is operating on a false premise.
The tool works because organisational conflicts are almost never about values. They're about logic chains. Two people who both want the company to succeed have constructed different causal models of how to get there, and at least one of those models contains an assumption that doesn't survive scrutiny. The diagram makes those models visible, comparable, and testable. That's the whole trick.
Section 2
How to Use It — Step by Step
Instructions on the left. Worked example — a SaaS company where the VP of Product and VP of Sales are deadlocked over whether to build custom enterprise features or maintain a standardised product — on the right.
Step 1 — State the Conflict
Identify the two actions that appear mutually exclusive
Start with the surface-level clash. What are the two things people are arguing about? These should be specific actions or policies, not abstract values. "We should invest in innovation" vs. "We should cut costs" is too vague. "We should allocate 40% of engineering to custom enterprise integrations" vs. "We should freeze all custom work and ship only standardised features" is concrete enough to work with. Write these as D and D' (D-prime) — the two prerequisites in direct conflict. If you can't articulate both positions clearly enough that each side would say "yes, that's what I'm arguing for," you haven't understood the conflict yet.
Worked example
SaaS product vs. sales conflict
D: "Build custom integrations and workflows for our top five enterprise prospects" (VP Sales position). D': "Freeze all custom work; ship only features that serve the entire customer base" (VP Product position). These are genuinely incompatible — the same engineering team can't do both simultaneously. The conflict is real at the action level.
Step 2 — Identify the Needs
Surface the legitimate need each action is trying to protect
This is where the conversation shifts from positional to structural. Ask each side: "What need are you trying to meet with this action? What bad thing happens if we don't do it your way?" These needs (B and C) are almost always legitimate. Neither side is being irrational — they're protecting something real. Write the needs as conditions that must be met, not as actions. "We need to close enterprise deals to hit revenue targets" is a need. "We need to build custom features" is an action masquerading as a need. Keep pushing until you reach the underlying requirement.
Worked example
Surfacing the real needs
B (Sales need): "We must win enterprise contracts to achieve the revenue growth required for our Series C." C (Product need): "We must maintain a scalable, maintainable codebase to ship reliably and serve our 200+ existing customers." Both legitimate. Both necessary. The VP of Sales isn't being greedy; without enterprise revenue, the company runs out of runway. The VP of Product isn't being precious; a codebase riddled with one-off customisations becomes unmaintainable within 18 months.
Step 3 — Define the Shared Objective
Find the common goal both sides agree on
This is element A — the objective that both needs serve. It should be something both parties would immediately endorse. If you can't find a shared objective, either the conflict is between people with genuinely different goals (rare in a functioning organisation) or you haven't gone high enough in the goal hierarchy. "Build a successful company" is too generic. "Achieve $15M ARR by Q4 2025 while maintaining product quality that supports 95%+ retention" is specific enough to anchor the diagram.
Worked example
The shared objective
A: "Build a sustainable, high-growth SaaS business that reaches Series C milestones (revenue, retention, and product velocity)." Both VPs agree on this instantly. They've never disagreed about the destination — only about the route. Writing it down makes that agreement visible and changes the emotional temperature of the conversation.
Step 4 — Surface Assumptions
List every assumption behind each arrow in the diagram
This is the step that does the actual work. For each connection (A→B, A→C, B→D, C→D', and the D↔D' conflict itself), ask: "What must be true for this link to hold?" Generate as many assumptions as possible. The B→D link is usually the richest vein. "In order to win enterprise contracts (B), we must build custom integrations (D)" — what assumptions make that true? That enterprise buyers won't buy without customisation. That no configuration layer could substitute for custom code. That the specific integrations requested can't be productised. Write every assumption down, no matter how obvious it seems. The obvious ones are often the ones nobody has questioned.
Worked example
Assumption mining
B→D assumptions (need enterprise revenue → must build custom): (1) Enterprise prospects require bespoke integrations to sign. (2) No existing integration platform or middleware could meet their needs. (3) The customisations requested are unique to each prospect. (4) Enterprise buyers won't accept a phased approach where core product ships first and integrations follow. C→D' assumptions (need maintainable codebase → must freeze custom work): (5) Custom code always creates technical debt. (6) Engineering can't build custom features in a modular way that doesn't compromise the core. (7) Any custom work will consume the entire team's bandwidth. D↔D' conflict assumption: (8) The same engineering resources must be used for both custom and standardised work — there's no way to separate the two.
Step 5 — Invalidate and Inject
Find the weakest assumption and design a solution that breaks it
Review every assumption. Which ones are actually false, or could be made false with a specific intervention? You're looking for the assumption whose invalidation dissolves the conflict entirely. This is the "injection" — a new idea, policy, or action that makes the previously impossible combination possible. Often the breakthrough comes from an assumption so deeply embedded that nobody recognised it as an assumption at all. Test your injection: if this were true, would both needs be met simultaneously? If yes, the cloud has evaporated.
Worked example
The assumption that breaks
Assumption (3) — "The customisations requested are unique to each prospect" — turns out to be false. When the team actually maps the five enterprise prospects' requirements, four of the five need the same three integrations (Salesforce, SAP, and a specific SSO provider). Assumption (6) — "Engineering can't build custom features modularly" — is also questionable. Injection: Build a configurable integration layer as a standardised product feature, not as custom code. The three most-requested integrations become first-class product capabilities available to all customers. The fifth prospect's truly unique requirement gets scoped as a paid professional services engagement, isolated from the core codebase. Both needs are met. Enterprise deals close. Codebase stays clean. The conflict evaporates.
Section 3
When It Works Best
✓
Ideal Conditions for the Conflict Resolution Diagram
| Dimension | Best fit |
|---|---|
| Conflict type | Binary deadlocks where two intelligent parties hold opposing positions and neither will budge. The tool is specifically designed for situations where compromise feels unsatisfying to both sides — a signal that the real solution isn't somewhere between the two positions but orthogonal to them entirely. |
| Relationship between parties | Most powerful when both sides share a genuine common objective but disagree on how to achieve it. Co-founders, cross-functional leadership teams, business units within the same company. The tool struggles when the parties have truly adversarial goals — it assumes a shared A exists. |
| Assumption density | Excels when the conflict rests on unstated assumptions that have never been examined. Long-running organisational conflicts accumulate assumptions like sediment — "we've always done it this way" beliefs that nobody questions because they feel like facts. The older and more entrenched the conflict, the more likely a false assumption is hiding in it. |
| Stakes | Worth the 60–90 minutes when the conflict is blocking a significant decision — a strategic direction, a resource allocation, a go/no-go on a major initiative. Not worth deploying for low-stakes disagreements where a coin flip would suffice. |
| Emotional temperature | Paradoxically effective when emotions are running high. The diagram's structure forces participants to articulate each other's needs as legitimate, which de-escalates the conversation from "you're wrong" to "we're both right about the need, but one of us is wrong about the assumption." That reframe changes everything. |
| Solution space | Works best when the solution space is broader than the parties realise. If the constraint is genuinely physical — you have one server and two applications that each need 100% of its capacity — the tool won't help. But most organisational conflicts aren't physical constraints. They're logical constraints built on assumptions, and assumptions can be broken. |
Section 4
When It Breaks Down
⚠
Failure Modes
| Failure pattern | What goes wrong | What to use instead |
|---|---|---|
| Genuinely incompatible values | The tool assumes both parties share a common objective. When the conflict is truly about values — one founder wants to build a lifestyle business, the other wants to build a unicorn — no amount of assumption-surfacing will dissolve it. The disagreement isn't logical; it's existential. | Hard Choice Model to clarify what each party actually values; then an honest conversation about whether the partnership should continue |
| Premature closure on the "wrong" assumption | Teams find the first questionable assumption and declare victory. The injection they design addresses a real but secondary assumption while the primary false assumption — the one actually sustaining the conflict — goes unexamined. The conflict returns within weeks. | Generate at least 8–10 assumptions per link before evaluating any of them; use 5 Whys to test whether each assumption is truly foundational |
| Power asymmetry | When one party has significantly more organisational power, the "shared objective" and "legitimate needs" framing can become performative. The senior person goes through the motions but has already decided. The diagram becomes a tool for manufacturing consent rather than surfacing truth. | Have a neutral facilitator run the session; consider Delphi Method for anonymous assumption generation |
| Physical or regulatory hard constraints | Some conflicts are real. You cannot simultaneously comply with EU data residency requirements and store all data in a single US data centre. The constraint isn't an assumption — it's a law. The Evaporating Cloud can waste time when the conflict is genuinely structural rather than logical. | Decision Matrix or Cost-Benefit Analysis to evaluate which constraint to satisfy and at what cost |
| Vague problem framing | If D and D' are stated at too high a level of abstraction ("invest in growth" vs. "protect profitability"), the assumptions generated will be equally abstract and unfalsifiable. The tool needs concrete, specific actions to generate testable assumptions. | Abstraction Laddering to move the conflict statement to the right level of specificity before building the cloud |
| Multi-party conflicts | The diagram is built for two-party, binary conflicts. When three or more factions hold different positions, or when the conflict has more than two dimensions, the five-element structure can't capture the full picture. Forcing a multi-dimensional disagreement into a binary frame distorts it. | Six Thinking Hats for multi-perspective exploration; Issue Trees to decompose the conflict into its component sub-conflicts, then run separate clouds for each |
The most dangerous failure mode is premature closure — and it's dangerous precisely because it feels like success. The team finds an assumption that's clearly questionable, designs a clever injection, and leaves the room energised. But the assumption they invalidated was a supporting beam, not the foundation. The real load-bearing assumption — the one both parties have held so long it's become invisible — never gets examined. Three months later, the same conflict resurfaces in a slightly different form, and the team concludes that "the Evaporating Cloud doesn't work." It worked fine. They just stopped digging too early.
The protection is simple but requires discipline: generate assumptions exhaustively before evaluating any of them. Goldratt himself recommended listing every assumption behind every arrow, no matter how obvious or absurd. The assumption that feels most like a fact — "of course enterprise buyers require custom integrations" — is often the one most worth questioning.
Section 5
Visual Explanation
Conflict Resolution Diagram (Evaporating Cloud) — populated with the SaaS product vs. sales worked example. The red dashed line marks the invalidated assumption that dissolves the conflict.
Section 6
Pairs With
The Evaporating Cloud is a precision instrument for a specific moment: the binary deadlock. It needs other tools to prepare the ground before it and to execute the injection after it.
Use before
Reframing
Before building the cloud, verify that you're framing the conflict correctly. Many apparent binary conflicts are actually symptoms of a deeper, differently shaped problem. Reframing can reveal that the "real" conflict is between two different elements entirely — and building the cloud around the wrong pair of actions wastes everyone's time.
Use before
Abstraction Laddering
The cloud requires the conflict to be stated at the right level of specificity. Too abstract and the assumptions are unfalsifiable. Too granular and you miss the structural pattern. Abstraction Laddering helps you move up and down the specificity scale until you find the level where the conflict is both concrete enough to analyse and general enough to matter.
Use after
5 Whys
Once you've identified a suspicious assumption, 5 Whys helps you drill into why that assumption exists. "Enterprise buyers require custom integrations" — why? Because our sales team has been told that by procurement. Why does procurement say that? Because their IT team evaluated us against an RFP written for on-premise software. Now you're at the real issue.
Use after
Second-Order Thinking
The injection that dissolves the conflict will have consequences of its own. Building a configurable integration layer solves the immediate deadlock — but what does it do to your product complexity? Your support burden? Your positioning? Second-Order Thinking maps the downstream effects of your injection before you commit to it.
Mental model
First Principles Thinking
The Evaporating Cloud is, at its core, a first-principles exercise applied to organisational conflict. It decomposes positions into needs, needs into assumptions, and then tests those assumptions against reality. First Principles Thinking provides the philosophical backbone: don't accept inherited constraints without verifying them.
Mental model
Nonviolent Communication
NVC and the Evaporating Cloud share a structural insight: conflicts escalate when people argue about strategies (actions) instead of surfacing needs. NVC provides the interpersonal language — observations, feelings, needs, requests — that makes the cloud's assumption-surfacing step emotionally safe enough to actually work in a room full of frustrated executives.
Section 7
Real-World Application
Amazon — the free shipping conflict that became Prime
The scenario
In the early 2000s, Amazon faced a conflict that its leadership team had been circling for years. The retail operations group argued that shipping costs were destroying margins — every free shipping promotion accelerated order volume but bled money. The growth team argued that shipping fees were the single largest source of cart abandonment and that eliminating them was essential to achieving the scale economics that Amazon's entire model depended on. Charge for shipping and protect margins, or offer free shipping and protect growth. The positions seemed irreconcilable. Compromise — free shipping on orders over $25 — existed but satisfied neither camp. It was too high a threshold to eliminate abandonment and too generous to protect margins.
How the tool appliedWhile Amazon's internal process wasn't labelled as an Evaporating Cloud exercise, the logic Jeff Bezos and his team applied maps precisely onto Goldratt's structure. The shared objective (A): build the world's most customer-centric company at scale. Need B: drive order frequency and customer lifetime value through frictionless purchasing. Need C: achieve sustainable unit economics on every shipment. Action D: offer free shipping universally. Action D': charge shipping fees that cover fulfilment costs. The critical assumptions behind B→D included: "The only way to remove shipping friction is to make each individual shipment free." And behind C→D': "Shipping costs must be recovered per-transaction."
What it surfacedThe assumption that shipping cost recovery had to happen per-transaction was the false premise. What if customers paid for shipping in advance, in aggregate, through an annual subscription? That injection — which became Amazon Prime in February 2005 — dissolved the conflict entirely. Customers perceived shipping as free (satisfying Need B and eliminating cart abandonment). Amazon recovered shipping costs through the $79 annual fee and, critically, through the dramatic increase in order frequency that the subscription created (satisfying Need C through volume economics rather than per-unit recovery). Prime members ordered roughly twice as often as non-members in the programme's first year.
The non-obvious factorThe assumption that nearly killed Prime was the most deeply held one: "shipping cost recovery is a per-transaction problem." Every retail business in history had treated it that way. The insight wasn't that free shipping was good for growth — everyone knew that. The insight was that the mechanism of cost recovery could be restructured from transactional to subscription-based, which simultaneously changed customer behaviour (more orders, higher lifetime value) and financial structure (predictable revenue, amortised fulfilment costs). The conflict between margin protection and growth acceleration didn't require a compromise. It required a business model innovation that made both positions obsolete. That's the Evaporating Cloud at its most powerful: not finding the middle ground, but finding the ground that neither side knew existed.
Section 8
Analyst's Take
Faster Than Normal — Editorial View
The Evaporating Cloud is the most underused tool in the Theory of Constraints toolkit — which is saying something, given that most of Goldratt's thinking tools are underused outside manufacturing. The reason is structural: the tool requires you to take your opponent's position seriously. Not "I understand your concern" seriously, which is negotiation theatre. Actually seriously — mapping their need as legitimate, their logic as internally coherent, and locating the flaw not in their reasoning but in the shared assumptions both sides have been operating on. That's a psychologically expensive move. Most leaders would rather win the argument than dissolve it. The Evaporating Cloud asks you to stop being right and start being curious, and that's a harder sell than any five-step framework should be.
The failure mode I see most often isn't premature closure on assumptions — though that's common. It's something subtler: teams that build the cloud correctly, find a genuine injection, and then fail to implement it because the injection requires a structural change that nobody has the authority or appetite to make. The SaaS team discovers that a configurable integration layer would solve everything, but building it requires six months of engineering investment that neither VP can authorise alone. The cloud evaporated the logical conflict but exposed a resource constraint or a governance gap that's harder to solve. The tool is honest about what's really in the way. Sometimes what's really in the way is more uncomfortable than the original argument.
The highest-leverage modification: run the assumption-surfacing step with people who aren't party to the conflict. The two sides have been staring at their own logic chains so long that their assumptions have calcified into facts. Bring in a board member, an advisor, a senior IC from a different department — someone who can look at the B→D link and say "wait, why does that have to be true?" with genuine naivety. Goldratt called this "verbalising the assumptions," but the real trick is verbalising them to someone who has no emotional investment in their truth. Fresh eyes don't just find false assumptions faster. They find the assumptions that the insiders can't even see as assumptions anymore.
Section 9
Top Resources
01
It's Not Luck — Eliyahu Goldratt (1994)
Primary sourceGoldratt's novelised introduction of the Evaporating Cloud (and the other Thinking Processes). Where The Goal introduced the Theory of Constraints for production, It's Not Luck applies the same logic to strategic and interpersonal conflicts. The fictional format makes the tool's application visceral in a way that no textbook achieves. Chapters 7–12 contain the clearest worked examples of the cloud in action. Read this before any secondary source.
02
Book
Horowitz doesn't reference Goldratt explicitly, but nearly every chapter describes a conflict that maps onto the Evaporating Cloud structure — the tension between keeping a struggling product alive and cutting losses, between transparency with employees and protecting morale, between founder vision and board pragmatism. Read it as a casebook of conflicts that were either dissolved (when someone found the false assumption) or endured (when nobody did).
03
Book
The cognitive science behind why the Evaporating Cloud works. Kahneman's research on anchoring, the focusing illusion, and "what you see is all there is" (WYSIATI) explains why intelligent people get locked into binary conflicts: the brain constructs a coherent story from available information and resists evidence that would complicate it. The cloud is a structured intervention against WYSIATI — it forces you to see the assumptions your brain has rendered invisible.
04
The Goal — Eliyahu Goldratt (1984)
BookThe foundational Theory of Constraints text. While The Goal focuses on production bottlenecks rather than the Evaporating Cloud specifically, it establishes the core principle that the cloud depends on: every system's performance is limited by a small number of constraints, and those constraints are often not where you think they are. Understanding the TOC worldview makes the cloud's logic feel inevitable rather than counterintuitive.
05
Book
Lafley and Martin's strategy framework — built around five cascading choices — is structurally complementary to the Evaporating Cloud. Their concept of "integrative thinking" (holding two opposing models in mind simultaneously and synthesising a superior alternative) is the strategic equivalent of Goldratt's injection. Chapter 8 on "reverse-engineering" strategic choices provides a practical bridge between the cloud's conflict-dissolution logic and real corporate strategy work.
Decision Tools Library — Browse by phase
Why this matters next
mental modelsSecond-Order Thinking
Reframing applied the Second-Order Thinking mental model
mental modelsFirst Principles Thinking
Reframing applied the First Principles Thinking mental model
mental modelsLeverage
Reframing applied the Leverage mental model
mental modelsTechnical Debt
Reframing applied the Technical Debt mental model
mental models5 Whys
Reframing applied the 5 Whys mental model
mental modelsTheory of Constraints
Reframing applied the Theory of Constraints mental model
Continue exploring
PRSTLI
Decision tool
Pre-Mortem
Imagine the decision has already failed — work backward to find out why
Decision tool
Second-Order Thinking
Map the consequences of consequences — what happens after the first effect?
Decision tool
Ladder of Inference
Trace your reasoning from raw data to conclusion to find where assumptions crept
More like this, in your inbox
I send a newsletter every week — free, no spam, unsubscribe anytime.