A product team is missing deadlines. Morale is low. Two engineers are quietly disengaged. The PM is escalating more than usual. The instinct from leadership arrives quickly: someone is the problem. Maybe replace the PM. Maybe the senior engineer needs feedback. Maybe the team needs different people.
This instinct is wrong about 80% of the time. The team's problem is almost never primarily about individuals. It is structural, systemic, and rooted in conditions the individuals did not create. The Waterline Model, developed by Molly Graham and shared on Lenny's Newsletter, is the diagnostic framework that walks through the real causes in the right order. This article distills how to apply it to product teams specifically.
Why blaming people fails so often
Blaming people for problems that are actually structural is one of the biggest leadership traps there is.
When a team underperforms in a poorly designed structure, replacing the people changes nothing. The new people inherit the same structure and start underperforming within a quarter. The pattern repeats. The leader concludes that good talent is hard to find. The real conclusion is that the structure was the problem all along.
The Waterline Model fixes this by forcing diagnosis in a specific order: start with what is hardest to see and most likely to be wrong (structure), and only after ruling that out, work down toward the visible (individuals).
The four layers, in order
Layer 1: Structure (above the waterline, most visible cause)
Structural problems include: unclear ownership of areas, mismatched team composition for the work, conflicting incentives across teams, no clear decision-making authority, dependencies on teams that have different priorities.
Common product team structural issues:
- The PM is responsible for outcomes but does not control the engineering capacity needed
- Two teams own overlapping product areas with no defined boundary
- Design is shared across teams and always over-allocated
- The team is asked to deliver platform-quality work with feature-team capacity
- Goals are set at the team level but rewards are individual
Snorkel before you scuba: start at the top. If you cannot articulate the team's clear charter, the boundary of their responsibilities, and the resources they control, the problem is structural. Fixing the structure usually fixes 60-70% of what looked like a people problem.
Layer 2: Dynamics (teams behaving rationally inside bad systems)
Once structure is sound, look at dynamics: how the team interacts, decides, and resolves conflict.
People adapt quickly to what is rewarded, punished, tolerated, or ignored.
Common product team dynamic issues:
- The team has standups but no one challenges decisions, so bad ideas ship
- The PM makes all the decisions, so engineers stop offering opinions
- Conflict gets routed through 1:1s with the manager instead of resolved in the team
- Retros happen but no commitments are tracked, so nothing changes
- The team celebrates shipping, not learning, so risky bets are avoided
Dynamics are about implicit incentives. If you want a behavior, you need to make it rewarded, supported, or at least normal. If unwanted behavior keeps appearing, the system is implicitly tolerating or rewarding it.
Layer 3: Interpersonal (real but often misdiagnosed)
Genuine interpersonal conflict exists. Two team members who fundamentally do not get along, a clash of working styles that creates friction, a piece of unaddressed tension from a past incident. These are real and need to be addressed.
The trap is jumping here first. Most apparent interpersonal conflict is actually structural or dynamic conflict expressed through individuals. Two engineers who keep clashing might genuinely dislike each other, or they might be carrying tension from a structural problem nobody named (overlapping responsibilities, unclear ownership).
The test: if you addressed the interpersonal directly, would the underlying issue resolve? If yes, it is interpersonal. If the same dynamic would re-emerge between different people, it is structural or dynamic dressed as interpersonal.
Layer 4: Individual (only after the above is sound)
Some performance issues are genuinely individual. The wrong person for the role, a skill gap that needs addressing, a personal situation impacting work. These are real and need to be handled.
The discipline is making sure the structure, dynamics, and interpersonal layers are sound first. A talented engineer in a broken structure will look underperforming. The same engineer in a clear structure with healthy dynamics will look strong. The data you collect about individuals is only reliable if the layers above are functioning.
How to apply the model
The diagnostic walkthrough
When a team is stalled, run through the layers in order. For each, ask specific questions:
| Layer | Key questions |
|---|---|
| Structure | What is this team's charter? What do they own? What resources do they control? Who do they depend on? |
| Dynamics | How are decisions made? How is conflict surfaced? What gets rewarded? What gets tolerated? |
| Interpersonal | Where is there active tension? Is it between specific people or roles? Has it been named? |
| Individual | Are there specific people whose contribution is below expectation? Is the cause visible from the above layers, or genuinely individual? |
Resist the temptation to start at Individual. The model only works if you discipline yourself to start at the top.
The intervention sequence
Fix in the same order you diagnose:
- Fix structure first. Clarify ownership, allocate resources, remove conflicting incentives. Give the team a clear charter on paper. Let them sit with it for two weeks.
- Then address dynamics. Surface the implicit incentives. Make the desired behaviors explicit. Hold team retros that actually change things.
- Then resolve interpersonal. The remaining tensions are now visible. Address them with clarity.
- Last, individual feedback or changes. By the time you get here, you have evidence that the issue is genuinely individual.
What this looks like for product teams specifically
Product teams have predictable structural failure modes worth checking first:
- PM accountable for outcomes without authority over the engineering team's priorities (extremely common)
- Design as a shared resource across multiple product teams (creates implicit prioritization the PM cannot see)
- Engineering managers who report up a different chain than the PM (creates dual reporting tensions)
- OKRs at the team level but bonuses at the individual level (incentive misalignment)
- Cross-team dependencies with no defined SLAs (creates random unblocking work)
Most product team underperformance traces back to one of these structural patterns, not to the people involved.
The risk of skipping the model
Leaders who skip the diagnostic and jump to individual interventions pay three costs:
- Lost good people. Replacing performers who were trapped in bad structures means losing accumulated context.
- Pattern repetition. The structural problem recreates the underperformance with new people in 6-12 months.
- Damaged trust. The team notices when people get blamed for systemic issues. Future engagement drops.
The takeaway
When a product team is stalled, the most expensive instinct is to start with the people. The Waterline Model forces the right diagnostic order: structure first (charter, ownership, resources), then dynamics (incentives, decision-making), then interpersonal, then individual. Most underperformance is structural. Fix that and most of the symptoms disappear. Snorkel before you scuba, always.
