The Iceberg
Why You Are Rewarding Failure
Welcome to Episode 3.
In the last episode, we talked about Whack-a-Mole and the danger of confusing motion with progress. Today, we are going to go deeper. We are going to talk about The Iceberg.
But first, let me take you back to my time as a Head of Product at a very large organization.
My team shared a workspace with the product team that managed the organization’s flagship consumer product. We interacted very often. This was the crown jewel of the portfolio. And looking at that team, you would think they were at war.
They always looked worn out. They were the “first in, last out” crew. Every other week, there was a “Critical Severity” bug or a massive outage. The team was constantly scrambling, patching, and apologizing. They were often called into executive meetings to explain why the “Flagship” didn’t feel like a flagship.
But here is the crazy part.
At the end of the year, during the keynote session, that team was called out. They were generously hyped as the organisation saviour. They were praised for their “resilience,” their “hard work,” and their “dedication to putting out fires.”
I sat there clapping, but in my head, I realized the truth: We were rewarding them for bailing water out of a boat they forgot to plug.
They were slaving away on surface issues, ignoring the deep structural fractures. And because the business didn’t understand Systems Thinking, it rewarded Effort instead of Results.
A mature business does not reward you for sweating. It rewards you for fixing the system so you don’t have to sweat.
To understand this, you need to understand the Iceberg Model.
The 4 Levels of Reality
Most Product Managers live their entire careers at the tip of the iceberg. They see what happens, and they react. But Systems Thinkers dive to the bottom.
Level 1: Events (The Firefighter)
The Question: What just happened?
The Behavior: Reacting.
The Trap: This is the domain of the “Hero.” It feels good to save the day. But if you are saving the day every day, you aren’t a hero; you are a hostage. This is where the “Flagship Team” lived, addicted to the adrenaline of the fix but blind to the cause.
“The site crashed.” → Reboot it and high-five.
“A customer complained.” → Offer a discount and apologize.
“Sales missed quota.” → Yell at Sales and demand “more intensity.”
The Outcome: You survive the day, but you are doomed to repeat it forever. You are running on a treadmill, sweating profusely, but going nowhere.
Level 2: Patterns (The Analyst)
The Question: What has been happening over time?
The Behavior: Anticipating.
The Shift: You stop reacting to the noise and start looking at the signal. You move from “What happened?” to “What always happens?” You become a weather reporter; you can predict the storm, but you can’t stop it.
“The site crashes every time Marketing sends a push notification greater than 50k users.”
“Users churn exactly 3 months after onboarding when their trial expires.”
The Outcome: You can predict the failure, but you are powerless to prevent it. You just buy better umbrellas and brace for impact.
Level 3: Structures (The Architect)
The Question: What is causing the pattern?
The Behavior: Designing.
The Shift: This is where the Product Architect lives. You stop blaming “bad luck” or “dumb users” and look at the physics of the system. Structures are the rules of the game—both physical (code/servers) and intangible (incentives/org charts).
Physical Structure: “The site crashes because the marketing server and the production database share the same load balancer. They are structurally fighting for the same resource.”
Incentive Structure: “Sales misses quota because they are paid commission on ‘booked revenue’ regardless of retention. The structure incentivizes them to sell bad deals that churn.”
The Outcome: You change the structure (Rewrite the Org chart, decouple the Tech stack, Change the Compensation plan). The pattern stops immediately. The fire goes out forever because the fuel is gone.
Level 4: Mental Models (The Visionary)
The Question: What beliefs hold the structure in place?
The Behavior: Transforming.
The Shift: This is the bedrock. This is the water we swim in. Structures don’t appear out of thin air; they are built by people with specific beliefs. If you change the structure but not the belief, the structure will eventually grow back.
“We believe that ‘Move Fast and Break Things’ is better than ‘Reliability’.” (This belief built the shared load balancer).
“We believe that Sales owns the customer relationship, and Product is just a factory.” (This belief built the commission structure).
The Outcome: The entire organization shifts its identity. You don’t just solve the problem; you change the DNA of the company so that problem cannot exist here.
The Descent: A Case Study in Retention
Let’s watch a product team try to solve a Retention Crisis (Churn spikes to 15%) at these different levels.
The Level 1 Manager (The Firefighter):
Reaction: “Call the customers! Offer them a 20% discount to stay! Quick, send an email blast!”
Result: They save 5% of customers this month. Next month, churn is 15% again. They are stuck.
The Level 2 Manager (The Analyst):
Reaction: “I looked at the data. Churn spikes specifically with ‘Small Business’ clients who sign up via ‘Self-Serve’. Large Enterprises are fine.”
Result: They stop panicking about Enterprise clients. They adjust their revenue forecast down for Small Biz. They are “data-driven,” but they are still losing money.
The Level 3 Manager (The Architect):
Reaction: “Why do Small Businesses churn? Let’s look at the structure. Ah, our onboarding requires a dedicated ‘Customer Success Manager’ to configure the API. Small Business plans don’t get a Success Manager. Therefore, they are structurally doomed to fail.”
Result: They change the structure. They build a “Self-Serve Wizard” that automates the API setup.
The Impact: Churn drops permanently.
The Level 4 Leader (The Visionary):
Reaction: “Why did we build a product that requires a human to set it up in the first place? It’s because we view ourselves as a ‘Service Company’ that happens to sell software. We need to shift our Mental Model. We are a Product-Led Growth company.”
The Impact: They don’t just fix churn; they change the trajectory of the company for the next 5 years.
The Veteran’s Discipline: Managing the Waterline
The hardest part of Systems Thinking is not understanding the Iceberg; it is the discipline to dive when everyone else is screaming at the surface.
When a crisis hits, the pressure to “Do Something!” (Level 1) is immense. Your CEO wants a status update. Sales wants a fix. If you say, “I am analyzing the Mental Models that caused this,” you will get fired.
The Veteran Product Leader knows how to manage the Waterline.
Contain the Event: Apply the tourniquet. Fix the bug. Pacify the CEO. (Level 1).
Don’t Celebrate: Refuse to call the hotfix a “win.” It is a failure of the system that we had to fix it at all.
Schedule the Dive: Once the smoke clears, book the meeting that matters. “The Incident Review.”
The Monday Morning Exercise
Meeting: The Post-Mortem (or “Incident Review”)
Time: 30 Minutes
Take the last “Crisis” your team faced (a bug, a missed deadline, a bad release). Draw an Iceberg on the whiteboard.
The Event: Write down what happened. (”The mobile app crashed on launch.”)
The Pattern: Has this happened before? (”Yes, every time we update the library dependencies.”)
The Structure: What in our system allows this? (”We don’t have automated regression tests. We rely on manual QA, and manual QA is incentivized to check ‘New Features’, not ‘Old Code’.”)
The Mental Model: What belief defends this structure? (”We believe that ‘Automated Testing slows us down’.”)
The Verdict:
If you leave that room promising to “Test harder next time,” you have failed.
You only succeed if you change the Structure (Invest in CI/CD pipeline) or the Mental Model (Redefine “Speed” to mean “Speed without crashing”).
Stop fighting the fire. Re-wire the building.
The distinction between rewarding effort versus fixing systems is something I've struggled with in organizatons that celebrate heroics over prevention. The four-level iceberg framework makes explicit what most PMs intuitively know but can't articulate. I've seen teams change their org chart and tech stack only to revert back becuase the underlying beliefs never shifted. The retention case study is a perfect example of how thinking at different levels produces dramatically different outcomes.