Owning Platform Delivery Across Concurrent Customer Accounts

What this is

As a technical producer on the platform-vendor side, I was assigned as the delivery owner — the point of contact — for a standing portfolio of external studio and publisher customer accounts at once, spanning indie through AAA scale, across titles in active development and titles already live. My team built and operated the platform capabilities each customer integrated into their own product; my responsibility was owning the delivery of that platform work to each account, not building the customer’s game itself. This ran for more than two years, and several of these relationships continued into a later release-and-launch ownership role.

How I operated

• Owned the delivery relationship with each customer account individually — four significant accounts held at once in one period: scope discussion on which platform capabilities to prioritize, through build and integration, to launch and post-launch support — not one shared plan applied uniformly across every account.
• Worked directly with customer-side product leadership — up to director and head of product — to define which platform capabilities to prioritize, then carried that scope through delivery.
• Worked primarily through internal engineering leads across the teams building each platform capability, coordinating directly with engineers when a delivery risk needed faster resolution than the lead-to-lead channel could provide.
• Owned the customer’s request end to end rather than passing it along: the conversations with the customer about what they wanted to build and why, the breakdown of that into small internal tasks against the specific service teams whose scope it touched, an estimate and a delivery roadmap per slice, and an estimate of the engineering resource each slice would need before it was committed.
• Held more than one service team on the same customer programme at once, so the account’s delivery depended on several teams whose work had to land in a particular order — sequencing agreed with each team rather than assigned to it.
• When a slice slipped, the status came out of the standup and the sprint rather than out of a deadline: which items were blocked, what the blocker actually was, and what it would take to clear it. That evidence is what went to the customer — a renegotiation with a stated reason, not an apology after the date had already passed.
• Maintained ongoing status, risk, and progress reporting to both my own organization’s leadership and each customer’s stakeholders throughout the engagement.

Outcome and value

This mattered in practice, not just in principle. Two accounts running similar-sounding platform work could still need completely different handling — one customer’s operation couldn’t absorb surprises, so their releases needed conservative, heavily-validated rollout; another had more tolerance for risk and moved faster because their setup allowed it. Tracking each account on its own terms meant I could match the level of caution to what that specific account actually needed, instead of defaulting to whichever approach the most recent or loudest account required. When one account’s timeline slipped, I could tell my own leadership exactly which other accounts were unaffected and why — not a guess, an answer — instead of one relationship’s delay creating uncertainty across the whole portfolio.

The professional outcome I can stand behind: none of my concurrent customer accounts ever had to inherit another account’s delay, risk, or operating style, because I never let the convenience of a single shared plan collapse them into one.

What this shows about how I operate

Concurrency is not the same as uniformity. Owning several customer accounts at once means resisting the shortcut of treating them as one workstream — each account gets its own scope, its own cadence, and its own risk picture, and I stay accountable for keeping those distinct even under pressure to simplify status reporting. I default to working through internal engineering leads, and step in directly only when the delivery risk justifies it — not as a standing operating mode.