Lead Principal Technical Program Manager

Opening Statement (~60 sec)

As the Technical Program Manager driving new ad-product incubation across Amazon's streaming portfolio, I owned the launch of pre-roll video ads on Amazon Freevee — a free, ad-supported streaming service with 30M+ monthly viewers — where pre-roll CPMs ran 30–50% higher than the mid-roll-only model Freevee was running, but the Freevee Content and Product teams, who reported into a completely separate VP org I had no authority over, actively opposed the change, backed by their own data showing higher ad load increased session drop-off. Rather than mandate a governance model, I earned it: a two-week stakeholder discovery sprint, a jointly-authored problem statement, and a five-part guardrail framework — including an automated kill-switch the other team could trigger without my sign-off. We launched to 100% of U.S. traffic within six weeks, ad revenue per viewer hour rose ~38%, and the guardrail-and-governance model became the template two subsequent programs adopted.

Situation

1. Amazon Ads identified a strategic revenue gap: Freevee ran ads exclusively as mid-roll breaks, carrying lower CPMs than industry-standard pre-roll formats used by competitors. 2. The Freevee Content and Product teams optimized for a different metric entirely — viewer engagement and retention — and had internal data showing ad load above a threshold historically correlated with session abandonment. 3. This wasn't a data disagreement, it was two orgs with genuinely competing north-star metrics, and I had no reporting line into either team I needed to align.

Task

1. I was asked to own the end-to-end program to design, align, and launch the pre-roll unit, including whatever KPIs, guardrails, and review cadence would govern it going forward. 2. My mandate was to build genuine cross-org buy-in — not compliance — with a team that had real, data-backed reasons to resist, and no reporting relationship obligating them to say yes.

Action

1. 1.Ran a two-week stakeholder discovery sprint before proposing any governance mechanism — arriving with questions instead of a pitch, and openly acknowledging the other team's session-abandonment data instead of disputing it.
2. 2.Co-authored a joint problem statement with the resisting team, reframing the KPI conversation from "what we want to measure" to a shared metric both orgs would defend.
3. 3.Converted their objections into binding, measurable guardrails — a duration cap, a frequency limit, a weekly joint KPI review where the other team held escalation veto, and an automated kill-switch that paused the change with no approval required from me.
4. 4.Proposed a time-boxed pilot with pre-committed exit criteria, so the other team was agreeing to a controlled test of the new operating cadence, not a permanent mandate.
5. 5.When pilot data surfaced a real problem, surfaced it to the other team within 24 hours myself, before they had to escalate it, and proposed a targeted fix rather than waiting to be asked.

Result

1. The program launched to 100% of U.S. traffic within six weeks of the pilot, on the original two-quarter target. 2. Revenue per viewer hour rose ~38%, while the guardrail metric moved only -0.2% against an 8% threshold — proof the governance model held under real traffic. 3. The team that started as the most vocal opponent became the program's public advocate, and the guardrail-and-governance structure was adopted as the template for two subsequent launches.

Closing Statement (~60 sec)

What made this a governance problem rather than a launch problem was that every KPI, every review cadence, and every guardrail had to be something the other team chose to accept, since I had zero formal authority to mandate any of it. The pattern I'd bring to establishing governance mechanisms, SLAs, and operating cadences at OCI is the same one: let the team that would otherwise resist co-author the standard, give them a real veto on the guardrail that protects their concern, and let pilot evidence — not a mandate — do the persuading.