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.<\/p>\n
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.<\/p>\n
What followed taught me something I\u2019ve carried into every client communication since: knowing the root cause is only half the job. Explaining it in a way that restores confidence – that\u2019s the other half, and it\u2019s harder than it sounds.<\/p>\n
My first reaction was calm \u2014 escalations are part of the job, and I\u2019ve learned not to treat every alert as a fire. But calm doesn\u2019t mean comfortable. When I saw the client\u2019s 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.<\/p>\n
Within 24 hours, we had a clear picture:<\/p>\n
In other words: one issue was a real but contained bug, and the other wasn\u2019t an issue at all \u2014 it was a misconfiguration in how the data was being read.<\/p>\n
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.<\/p>\n
The instinctive PM response to an escalation is to send a fix-forward update: here\u2019s what went wrong, here\u2019s what we\u2019re doing, here are the owners and dates. It\u2019s clean. It\u2019s structured. And it\u2019s incomplete.<\/p>\n
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.<\/p>\n
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.”<\/p>\n
After this escalation, I formalised something I had been doing informally in retrospectives and monthly communication: an Observation Layer.<\/p>\n
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.<\/p>\n
Here\u2019s what the same situation looks like with and without it:<\/p>\n
Without the Observation Layer:<\/strong><\/p>\n \u201cCrash-free rate dipped in v4.2. Fix deployed in v4.3. Closed.\u201d<\/em><\/p>\n With the Observation Layer:<\/strong><\/p>\n \u201cThe crash-free rate dip was isolated to v4.2 on Android Mobile, affecting users in the 12\u201318% rollout cohort. Root cause was a version-specific initialisation bug introduced during the feature merge \u2014 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 \u2014 a single outlier request was skewing the view. We\u2019ve corrected the configuration so future readings reflect actual user experience.\u201d<\/em><\/p>\n The second version is longer, but it removes uncertainty instead of simply reporting progress. The client doesn\u2019t need to ask \u201cwas this isolated?\u201d or \u201cis the dashboard still showing the wrong thing?\u201d \u2014 because both questions are already answered.<\/p>\n Solving the issue was satisfying. Looking back, though, I realised there were several communication decisions I would change if the same escalation happened tomorrow.<\/p>\n What I would keep: the structured RCA format, the explicit separation of Observation from Action Items, and the habit of addressing the client\u2019s implied questions alongside their stated ones.<\/p>\n When a client escalates, they\u2019re rarely just reporting a bug. They\u2019re signalling anxiety \u2014 about whether the platform is stable, whether the team is in control, whether they made the right call trusting you with their product.<\/p>\n Fixing the bug addresses the symptom. The Observation Layer addresses the anxiety.<\/em><\/p>\n A client who receives a diagnosis \u2014 not just a prescription \u2014 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.<\/p>\n 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.<\/p>\n","protected":false},"excerpt":{"rendered":" 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 […]<\/p>\n","protected":false},"author":2291,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":1},"categories":[5878],"tags":[5624,8582,8669,3116,5986,8670],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/80330"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/2291"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=80330"}],"version-history":[{"count":3,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/80330\/revisions"}],"predecessor-version":[{"id":80528,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/80330\/revisions\/80528"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=80330"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=80330"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=80330"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}What I\u2019d Do Differently<\/h2>\n
\n
The Real Job in an Escalation<\/h2>\n