Technical Program Manager

Opening Statement (~60 sec)

I built and scaled Amazon's API-first publisher integration platform for the ads business — the system that let publishers like Prime Video, Fire TV, and Freevee plug into Amazon's advertising marketplace. The starting point was a 9–12 month, fully manual onboarding process that could not scale, with no existing architecture and no organizational consensus on how to fix it. I owned it end-to-end: I built the financial case that secured VP-level alignment across all seven orgs, made the core architectural bet — a canonical API "Exchange Mesh" instead of bilateral, exchange-by-exchange integrations — sequenced a risk-validated rollout through a tiered publisher framework, and ran five parallel engineering workstreams against it. The result: onboarding dropped from 9–12 months to 5 days, self-serve adoption hit 81%, publisher throughput grew 4x with zero headcount growth, and the platform delivered $50M+ in annualized revenue at 99.99% availability.

Situation

Publisher onboarding — how publishers plugged into Amazon's advertising marketplace — was manual, fragmented, and structurally broken. • Onboarding a new publisher took 9–12 months: each one integrated individually with 15+ ad exchanges, each with its own SDK, and even a small settings change took 3–4 months, since it had to be coded and released like a full software update. • Every improvement had to be built separately for each exchange instead of just once. And since Ad Ops (the team that set up each publisher's account by hand) had to manually enter hundreds of settings per publisher, the team had to keep growing just to keep up with new publishers. LEADERSHIP HAD MANDATED ABSTRACTING EXCHANGE COMPLEXITY AWAY FROM PUBLISHERS ENTIRELY — and the business had already set a target of $50M+ in annualized revenue, mathematically impossible under this model.

Task

1. I was given the mandate to build the integration platform from the ground up — no existing foundation, no defined architecture, and no organizational consensus on the right approach. 2. The program needed three foundational layers: an API-first canonical abstraction (the "Exchange Mesh") so publishers integrate once and reach every demand source; a self-serve publisher portal exposing that API with documentation and automated configuration; and provisioning automation to replace the 9–12 month manual setup with API-driven seat activation. 3. My targets were sub-30-day onboarding, 80%+ self-serve completion, and 4x publisher throughput — with zero headcount growth. 4. I owned program strategy, cross-org alignment across seven organizations, the technical architecture decisions, executive communication, and delivery end-to-end.

Action

1. 1.Built the financial case for the platform investment — quantifying the fully loaded cost of the manual model (ops labor, engineering overhead, $2M/yr in legacy-system maintenance, cost of delayed revenue) against the projected return — and translated the same data into seven different stakeholder narratives to win VP-level sign-off across Commercial, Operations, Engineering, Legal, Product, Finance, and the sponsoring VPs.
2. 2.Made the core architectural bet: an API-first canonical schema ("Exchange Mesh") with independently deployable per-exchange adapters, instead of bilateral SDK integrations or a client-side header-bidding wrapper — both of which I evaluated and rejected for failing to solve the underlying scaling problem.
3. 3.Designed a risk-sequenced, four-phase roadmap (Phase 0 architecture validation → Phase 1 closed beta with high-complexity publishers → Phase 2 assisted self-serve → Phase 3 full self-serve), with each phase gated by a measurable exit criterion tied to a specific risk, not just a feature ship date.
4. 4.Resolved a structural three-way prioritization conflict between Commercial, Operations, and Product over which publishers to onboard first by building a tiered prioritization framework that scored publishers on complexity and revenue potential, replacing opinion-driven sequencing with shared, quantified logic.
5. 5.Ran five parallel engineering workstreams (Publisher Platform, Auction Core, Exchange Mesh, Provisioning Automation, Reporting & Observability), each with its own PM/SDM and North Star metric, while I personally owned the cross-workstream dependency map and the architectural trade-off authority.
6. 6.Managed the program's two highest risks (a new architectural single point of failure, and the loss of manual quality review at scale) and three explicit, VP-approved trade-offs (yield optimization vs. abstraction, privacy vs. signal quality, and API flexibility vs. backward compatibility) through to launch.

Result

1. The platform launched against every target: onboarding dropped from 9–12 months to 5 days (89% reduction), self-serve completion hit 81%, and publisher throughput grew 4x with zero headcount growth. 2. The platform sustained 99.99% availability, including Prime Day, at 72ms p99 auction latency. 3. It delivered $50M+ in annualized revenue, a +12–15% eCPM lift on the 1P portfolio, and $2M/yr in savings from retiring three legacy systems. 4. Publisher NPS rose from 31 to 67 (+36 points). 5. Beyond the metrics, the governance model — the RACI structure, the dependency mapping, and the tiered prioritization framework — was adopted as a reference model by other large-scale initiatives across the Ads organization.

Closing Statement (~60 sec)

What made this a program-management problem rather than a pure engineering one was that the architecture, the rollout sequencing, and the cross-org trade-offs all had to be decided before a single line of code shipped — and none of those decisions had a clean 'right' answer, only a better trade-off given the constraint. Engineering could tell me whether the canonical schema was technically sound; they couldn't tell me how to sequence a phased rollout across seven organizations, or how to get Commercial to accept that fast-tracking one high-complexity publisher cost three Tier 2 publishers ten days. That's the gap I closed: I turned a platform thesis into a risk-sequenced roadmap, a scoring framework that took prioritization out of the loudest-voice-wins dynamic, and a dependency map that surfaced conflicts before they became delivery blockers. The pattern I'd bring here is the same: validate the riskiest architectural assumption first, make trade-offs explicit and quantified rather than negotiated by authority, and design the operating model to scale without linear headcount growth.