Systems thinking · iceberg-model

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.

Good input

Use the Iceberg Model to analyze this recurring problem.

Demo Gallery

What this skill can generate

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.

Markdown report1 credits

Recurring roadmap interruption · Complete Markdown report

The surface issue is scheduling chaos, but the deeper issue may be structure and mental models.

Generate this format

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

  • Input summary and classic case context
  • Framework analysis table
  • Conclusion, risks, and next actions
  • Ready for Notion, Docs, or internal wikis

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.
Diagram + report2 credits

Recurring roadmap interruption · Mermaid diagram + report

The surface issue is scheduling chaos, but the deeper issue may be structure and mental models.

Generate this format

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

  • Complete Markdown report
  • Classic Mermaid diagram source
  • Visual preview on page
  • Downloadable .mmd file

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 file3 credits

Recurring roadmap interruption · PDF-ready HTML file

The surface issue is scheduling chaos, but the deeper issue may be structure and mental models.

Generate this format

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

  • Complete Markdown content
  • Diagram source
  • Printable HTML
  • Ready to save as PDF for clients or executives

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"] --&gt; B["Facts"]
  A --&gt; C["Assumptions"]
  A --&gt; D["Constraints"]
  B --&gt; E["Iceberg Model"]
  C --&gt; E
  D --&gt; E
  E --&gt; F["Recommendation"]
  E --&gt; G["Risks"]
  E --&gt; 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"] --&gt; B["Facts"]
  A --&gt; C["Assumptions"]
  A --&gt; D["Constraints"]
  B --&gt; E["Iceberg Model"]
  C --&gt; E
  D --&gt; E
  E --&gt; F["Recommendation"]
  E --&gt; G["Risks"]
  E --&gt; H["Next actions"]</pre>
  </main>
</body>
</html>

Generate a file with this skill

Go back to the generator, paste meeting notes, requirements, customer feedback, or team context, and produce a deliverable.

Start generating