Introduction
I have been managing OTT platform delivery for a few years now – coordinating releases across Android Mobile, iOS, Web, Smart TVs, and Fire TV. Most days, the work is rhythm: sprint cycles, release sign-offs, stakeholder syncs. But every once in a while, something breaks that rhythm, and how you respond in that moment defines more than the immediate outcome. It defines how much the client trusts you going forward.
A few months ago, I received an escalation from a leading OTT streaming platform client flagging KPI degradation – specifically crash-free rate metrics and what appeared to be response time issues. The client had numbers. They had screenshots. And they were understandably concerned.
What followed taught me something I’ve carried into every client communication since: knowing the root cause is only half the job. Explaining it in a way that restores confidence – that’s the other half, and it’s harder than it sounds.
What the Data Said vs. What Was Actually Happening
My first reaction was calm — escalations are part of the job, and I’ve learned not to treat every alert as a fire. But calm doesn’t mean comfortable. When I saw the client’s screenshots, I felt the familiar pull to respond immediately with reassurances and I had to consciously stop myself, because reassurance without understanding is just noise.
Within 24 hours, we had a clear picture:
- The crash-free rate dip was real, but isolated — it was confined to a specific app version that had rolled out to a subset of users. It was not a platform-wide or systemic failure.
- The response time concern turned out to be a data interpretation issue. The monitoring dashboard was configured to show the Maximum response time rather than the Mean. One outlier request was skewing the entire picture.
In other words: one issue was a real but contained bug, and the other wasn’t an issue at all — it was a misconfiguration in how the data was being read.
We understood the situation. The client only saw the symptoms. And the gap between what we knew and what they understood was where the real problem lived.
The Mistake Most PMs Make in This Moment
The instinctive PM response to an escalation is to send a fix-forward update: here’s what went wrong, here’s what we’re doing, here are the owners and dates. It’s clean. It’s structured. And it’s incomplete.
The problem is that the client still doesn’t know why it happened, whether it’s isolated or systemic, or whether the proposed fix actually addresses the right problem. Without that context, even a good action plan reads as damage control rather than diagnosis.
Looking back, I realised the real problem wasn’t just the bug. It was the gap between what we understood and what the client understood. That’s the gap I now think of as the “explanation vacuum.”
The Observation Layer: Diagnose Before You Prescribe
After this escalation, I formalised something I had been doing informally in retrospectives and monthly communication: an Observation Layer.
The Observation Layer sits between the issue statement and the action plan. Its purpose is to explain why the issue happened, what it means, and whether it represents an isolated incident or a systemic risk.
Here’s what the same situation looks like with and without it:
Without the Observation Layer:
“Crash-free rate dipped in v4.2. Fix deployed in v4.3. Closed.”
With the Observation Layer:
“The crash-free rate dip was isolated to v4.2 on Android Mobile, affecting users in the 12–18% rollout cohort. Root cause was a version-specific initialisation bug introduced during the feature merge — not present in prior versions. The distribution pattern confirms this is not a systemic issue. v4.3 resolves it cleanly with the fix validated across the full device matrix. The response time concern was a separate matter: the monitoring dashboard was showing Max rather than Mean — a single outlier request was skewing the view. We’ve corrected the configuration so future readings reflect actual user experience.”
The second version is longer, but it removes uncertainty instead of simply reporting progress. The client doesn’t need to ask “was this isolated?” or “is the dashboard still showing the wrong thing?” — because both questions are already answered.
What I’d Do Differently
Solving the issue was satisfying. Looking back, though, I realised there were several communication decisions I would change if the same escalation happened tomorrow.
- Earlier proactive flagging on version fragmentation risk. We knew the rollout was phased; we should have surfaced the monitoring configuration discrepancy before the client saw it.
- Named owners and milestone dates in the first response, not after a follow-up ask. Clients interpret vague timelines as uncertainty, even when the team is moving confidently.
- Separating the two issues in the initial communication. Bundling a real bug and a dashboard misconfiguration in the same update created unnecessary confusion about severity.
What I would keep: the structured RCA format, the explicit separation of Observation from Action Items, and the habit of addressing the client’s implied questions alongside their stated ones.
The Real Job in an Escalation
When a client escalates, they’re rarely just reporting a bug. They’re signalling anxiety — about whether the platform is stable, whether the team is in control, whether they made the right call trusting you with their product.
Fixing the bug addresses the symptom. The Observation Layer addresses the anxiety.
A client who receives a diagnosis — not just a prescription — walks away with something more durable than a closed ticket. They walk away with confidence that the PM on the other side of the screen understands the platform, sees what they see, and can be trusted to tell them the truth even when the truth is uncomfortable.
That’s the communication standard I try to hold myself to now. It came from an escalation that reminded me a PM’s job isn’t just to solve problems, it’s to help clients understand them.