Elvis OkenwaBack to home

Notes · Platform products

What a platform product manager actually does

I've spent most of my career as a platform product manager — on a global CDN and edge platform at Akamai, on compute infrastructure at Google Cloud, and on connectivity platforms at Vodacom. The role looks like product management from the outside. From the inside, it's a different job.

Your customer builds things with your product

A customer-facing PM optimizes for someone completing a task. A platform product manager optimizes for someone building on top of the product — an engineer configuring delivery behaviour through policies and APIs, or a team shipping faster because the platform absorbs work they would otherwise do themselves. The measure of the platform is the leverage it gives them, not the features it has.

You need enough technical depth to make real trade-offs

Platform decisions are architecture decisions with a price tag. Owning delivery and policy products on a global edge network, or a high-availability product in Google Compute Engine, means going deep enough into the system to argue honestly with engineering about what a reliability number costs, what a policy model constrains, and what you're giving up. You don't have to write the code, but you have to understand the system well enough to simplify it — and to keep that complexity on the platform's side, not the customer's.

Adoption is your honest metric

Builders always have an alternative — another provider, another internal tool, or building it themselves. So a platform product manager watches who enabled the capability, who kept it on, and who routed around it. When I took a dedicated high-availability product to general availability at 99.95% reliability, the launch was the beginning of the work, not the end: a feature only matters once customers can find it, understand it and get value from it.

The skills that transfer — and the ones that don't

The core product skills still apply: a clear problem statement, a roadmap, launch criteria, a point of view on what you will not build. What changes is the evidence you rely on. Less usability testing, more API design reviews, adoption data and conversations with the engineers who build on you. And the stakeholders multiply — on a connectivity platform across South Africa and Nigeria, the "customer" was simultaneously the enterprise buyer, the carrier go-to-market team and the developers integrating the service.

If you're moving into a platform PM role from customer-facing product work: the job is the same discipline, pointed at a builder instead of a user, with the technical depth turned up. The technology can be hard. The customer experience has to feel simple.

← Back to elvishimself.com