Best for
Recurring issues, org behavior, growth dynamics, and system diagnosis.
Systems thinking · iceberg-model
Move from events to patterns, structures, and mental models.
Recurring issues, org behavior, growth dynamics, and system diagnosis.
Event, pattern, structure, mental model, and intervention map.
Use the Iceberg Model to analyze this recurring problem.
Demo Gallery
Each demo maps to a real paid deliverable: a Markdown report, Mermaid diagram, or PDF-ready file. Users can inspect examples before spending their 3 free generations.
The surface issue is scheduling chaos, but the deeper issue may be structure and mental models.
Sample input
Almost every two weeks an 'important customer request' jumps the queue, disrupting the roadmap, increasing engineering context switching, and creating PM-sales frustration. Everyone says we will control it next time, then it repeats. Use the Iceberg Model to analyze events, patterns, structures, mental models, and intervention points.
Generated output includes
Full Markdown demo
# Iceberg Model: Classic Generation Example ## Input Summary Almost every two weeks an 'important customer request' jumps the queue, disrupting the roadmap, increasing engineering context switching, and creating PM-sales frustration. Everyone says we will control it next time, then it repeats. Use the Iceberg Model to analyze events, patterns, structures, mental models, and intervention points. ## Classic Case Context Almost every two weeks an 'important customer request' jumps the queue, disrupting the roadmap, increasing engineering context switching, and creating PM-sales frustration. Everyone says we will control it next time, then it repeats. Use the Iceberg Model to analyze events, patterns, structures, mental models, and intervention points. ## Skill Used - Iceberg Model - Move from events to patterns, structures, and mental models. - Best for: Recurring issues, org behavior, growth dynamics, and system diagnosis. - Can generate: Event, pattern, structure, mental model, and intervention map. ## Situation Judgment This is a classic situation for Iceberg Model: the input contains a goal, constraints, stakeholder judgments, and a need for action. ## Executive Summary Separate facts, assumptions, constraints, and actions first, then use Iceberg Model to turn the material into a deliverable. The output should make an actionable judgment, not merely explain the framework. ## Framework Analysis | Module | Typical output | Purpose | | --- | --- | --- | | Facts | Verifiable information from the input | Avoid intuition-only judgment | | Assumptions | Unknowns that can change the conclusion | Guide validation | | Framework analysis | Structure through Iceberg Model | Create shared language | | Action | Owner, time, metric | Drive execution | ## Reusable Diagram This is a Markdown-only output. Switch to diagram or PDF-ready output to generate Mermaid. ## Recommendation Use this as the first decision or workshop artifact, then add real evidence, owners, and dates. ## Risks And Unknowns - If the input lacks real evidence, ranking and recommendations remain working assumptions. - The framework cannot replace stakeholder alignment on goals and constraints. - The diagram is a communication surface, not final truth. ## Next Actions 1. Confirm the goal and non-negotiable constraints. 2. Add the 2-3 pieces of evidence most likely to change the conclusion. 3. Share the output, collect objections, and update the version.
The surface issue is scheduling chaos, but the deeper issue may be structure and mental models.
Sample input
Almost every two weeks an 'important customer request' jumps the queue, disrupting the roadmap, increasing engineering context switching, and creating PM-sales frustration. Everyone says we will control it next time, then it repeats. Use the Iceberg Model to analyze events, patterns, structures, mental models, and intervention points.
Generated output includes
Full Markdown demo
# Iceberg Model: Classic Generation Example ## Input Summary Almost every two weeks an 'important customer request' jumps the queue, disrupting the roadmap, increasing engineering context switching, and creating PM-sales frustration. Everyone says we will control it next time, then it repeats. Use the Iceberg Model to analyze events, patterns, structures, mental models, and intervention points. ## Classic Case Context Almost every two weeks an 'important customer request' jumps the queue, disrupting the roadmap, increasing engineering context switching, and creating PM-sales frustration. Everyone says we will control it next time, then it repeats. Use the Iceberg Model to analyze events, patterns, structures, mental models, and intervention points. ## Skill Used - Iceberg Model - Move from events to patterns, structures, and mental models. - Best for: Recurring issues, org behavior, growth dynamics, and system diagnosis. - Can generate: Event, pattern, structure, mental model, and intervention map. ## Situation Judgment This is a classic situation for Iceberg Model: the input contains a goal, constraints, stakeholder judgments, and a need for action. ## Executive Summary Separate facts, assumptions, constraints, and actions first, then use Iceberg Model to turn the material into a deliverable. The output should make an actionable judgment, not merely explain the framework. ## Framework Analysis | Module | Typical output | Purpose | | --- | --- | --- | | Facts | Verifiable information from the input | Avoid intuition-only judgment | | Assumptions | Unknowns that can change the conclusion | Guide validation | | Framework analysis | Structure through Iceberg Model | Create shared language | | Action | Owner, time, metric | Drive execution | ## Reusable Diagram ```mermaid flowchart TD A["Input context"] --> B["Facts"] A --> C["Assumptions"] A --> D["Constraints"] B --> E["Iceberg Model"] C --> E D --> E E --> F["Recommendation"] E --> G["Risks"] E --> H["Next actions"] ``` ## Recommendation Use this as the first decision or workshop artifact, then add real evidence, owners, and dates. ## Risks And Unknowns - If the input lacks real evidence, ranking and recommendations remain working assumptions. - The framework cannot replace stakeholder alignment on goals and constraints. - The diagram is a communication surface, not final truth. ## Next Actions 1. Confirm the goal and non-negotiable constraints. 2. Add the 2-3 pieces of evidence most likely to change the conclusion. 3. Share the output, collect objections, and update the version.
Mermaid demo
flowchart TD A["Input context"] --> B["Facts"] A --> C["Assumptions"] A --> D["Constraints"] B --> E["Iceberg Model"] C --> E D --> E E --> F["Recommendation"] E --> G["Risks"] E --> H["Next actions"]
The surface issue is scheduling chaos, but the deeper issue may be structure and mental models.
Sample input
Almost every two weeks an 'important customer request' jumps the queue, disrupting the roadmap, increasing engineering context switching, and creating PM-sales frustration. Everyone says we will control it next time, then it repeats. Use the Iceberg Model to analyze events, patterns, structures, mental models, and intervention points.
Generated output includes
Full Markdown demo
# Iceberg Model: Classic Generation Example ## Input Summary Almost every two weeks an 'important customer request' jumps the queue, disrupting the roadmap, increasing engineering context switching, and creating PM-sales frustration. Everyone says we will control it next time, then it repeats. Use the Iceberg Model to analyze events, patterns, structures, mental models, and intervention points. ## Classic Case Context Almost every two weeks an 'important customer request' jumps the queue, disrupting the roadmap, increasing engineering context switching, and creating PM-sales frustration. Everyone says we will control it next time, then it repeats. Use the Iceberg Model to analyze events, patterns, structures, mental models, and intervention points. ## Skill Used - Iceberg Model - Move from events to patterns, structures, and mental models. - Best for: Recurring issues, org behavior, growth dynamics, and system diagnosis. - Can generate: Event, pattern, structure, mental model, and intervention map. ## Situation Judgment This is a classic situation for Iceberg Model: the input contains a goal, constraints, stakeholder judgments, and a need for action. ## Executive Summary Separate facts, assumptions, constraints, and actions first, then use Iceberg Model to turn the material into a deliverable. The output should make an actionable judgment, not merely explain the framework. ## Framework Analysis | Module | Typical output | Purpose | | --- | --- | --- | | Facts | Verifiable information from the input | Avoid intuition-only judgment | | Assumptions | Unknowns that can change the conclusion | Guide validation | | Framework analysis | Structure through Iceberg Model | Create shared language | | Action | Owner, time, metric | Drive execution | ## Reusable Diagram ```mermaid flowchart TD A["Input context"] --> B["Facts"] A --> C["Assumptions"] A --> D["Constraints"] B --> E["Iceberg Model"] C --> E D --> E E --> F["Recommendation"] E --> G["Risks"] E --> H["Next actions"] ``` ## Recommendation Use this as the first decision or workshop artifact, then add real evidence, owners, and dates. ## Risks And Unknowns - If the input lacks real evidence, ranking and recommendations remain working assumptions. - The framework cannot replace stakeholder alignment on goals and constraints. - The diagram is a communication surface, not final truth. ## Next Actions 1. Confirm the goal and non-negotiable constraints. 2. Add the 2-3 pieces of evidence most likely to change the conclusion. 3. Share the output, collect objections, and update the version.
Mermaid demo
flowchart TD A["Input context"] --> B["Facts"] A --> C["Assumptions"] A --> D["Constraints"] B --> E["Iceberg Model"] C --> E D --> E E --> F["Recommendation"] E --> G["Risks"] E --> H["Next actions"]
PDF-ready HTML demo
<!doctype html>
<html>
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<title>Iceberg Model: Classic Generation Example</title>
<style>
body { font-family: Inter, ui-sans-serif, system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif; margin: 48px; color: #161a1d; line-height: 1.6; background: #fbfcf8; }
h1 { font-size: 34px; line-height: 1.1; margin: 0 0 18px; }
h2 { font-size: 20px; margin-top: 28px; }
pre { white-space: pre-wrap; background: #fff; border: 1px solid #dfe3de; border-radius: 8px; padding: 18px; overflow-wrap: anywhere; }
.meta { color: #2563eb; font-size: 12px; text-transform: uppercase; font-weight: 800; letter-spacing: .08em; }
.sheet { max-width: 940px; margin: 0 auto; background: #fff; border: 1px solid #dfe3de; border-radius: 8px; padding: 32px; }
@media print { body { margin: 18px; background: #fff; } .sheet { max-width: none; border: 0; padding: 0; } }
</style>
</head>
<body>
<main class="sheet">
<p class="meta">ThinkOps AI PDF-ready output</p>
<h1>Iceberg Model: Classic Generation Example</h1>
<pre># Iceberg Model: Classic Generation Example
## Input Summary
Almost every two weeks an 'important customer request' jumps the queue, disrupting the roadmap, increasing engineering context switching, and creating PM-sales frustration. Everyone says we will control it next time, then it repeats. Use the Iceberg Model to analyze events, patterns, structures, mental models, and intervention points.
## Classic Case Context
Almost every two weeks an 'important customer request' jumps the queue, disrupting the roadmap, increasing engineering context switching, and creating PM-sales frustration. Everyone says we will control it next time, then it repeats. Use the Iceberg Model to analyze events, patterns, structures, mental models, and intervention points.
## Skill Used
- Iceberg Model
- Move from events to patterns, structures, and mental models.
- Best for: Recurring issues, org behavior, growth dynamics, and system diagnosis.
- Can generate: Event, pattern, structure, mental model, and intervention map.
## Situation Judgment
This is a classic situation for Iceberg Model: the input contains a goal, constraints, stakeholder judgments, and a need for action.
## Executive Summary
Separate facts, assumptions, constraints, and actions first, then use Iceberg Model to turn the material into a deliverable. The output should make an actionable judgment, not merely explain the framework.
## Framework Analysis
| Module | Typical output | Purpose |
| --- | --- | --- |
| Facts | Verifiable information from the input | Avoid intuition-only judgment |
| Assumptions | Unknowns that can change the conclusion | Guide validation |
| Framework analysis | Structure through Iceberg Model | Create shared language |
| Action | Owner, time, metric | Drive execution |
## Reusable Diagram
```mermaid
flowchart TD
A["Input context"] --> B["Facts"]
A --> C["Assumptions"]
A --> D["Constraints"]
B --> E["Iceberg Model"]
C --> E
D --> E
E --> F["Recommendation"]
E --> G["Risks"]
E --> H["Next actions"]
```
## Recommendation
Use this as the first decision or workshop artifact, then add real evidence, owners, and dates.
## Risks And Unknowns
- If the input lacks real evidence, ranking and recommendations remain working assumptions.
- The framework cannot replace stakeholder alignment on goals and constraints.
- The diagram is a communication surface, not final truth.
## Next Actions
1. Confirm the goal and non-negotiable constraints.
2. Add the 2-3 pieces of evidence most likely to change the conclusion.
3. Share the output, collect objections, and update the version.
</pre>
<h2>Mermaid diagram source</h2><pre>flowchart TD
A["Input context"] --> B["Facts"]
A --> C["Assumptions"]
A --> D["Constraints"]
B --> E["Iceberg Model"]
C --> E
D --> E
E --> F["Recommendation"]
E --> G["Risks"]
E --> H["Next actions"]</pre>
</main>
</body>
</html>Go back to the generator, paste meeting notes, requirements, customer feedback, or team context, and produce a deliverable.
Start generating