Notes · Platform products
Platform as a product
The platforms I've worked on — content delivery, cloud compute, connectivity — all share one trait: their customers are other builders. That changes how you manage them.
A platform rarely gets the luxury of a captive audience. The teams and developers who build on it always have an alternative: another provider, another internal tool, or building it themselves. So the first question I ask about any platform is the same one I'd ask about a consumer product — who is the customer, and what are they trying to get done?
Your customer is a builder, not a user
On a delivery platform, the "user" is often an engineer configuring behaviour through policies and APIs, or a product team trying to ship faster. They don't want features; they want leverage. Every capability you add either removes work from their plate or adds to it. When I owned delivery and policy products, the most valuable work was rarely the new capability itself — it was making an existing capability easier to understand, configure and trust.
Adoption is the metric that tells the truth
Platforms can look healthy on paper while builders route around them. Usage and adoption data — who enabled the feature, who kept it on, who turned it off — is where the honest signal lives. A feature only matters once customers can find it, understand it and get value from it. If adoption stalls, the problem is usually not the technology; it's that the complexity leaked onto the customer's side.
Keep the complexity on your side
Infrastructure is genuinely hard — global delivery networks, high-availability compute, carrier connectivity. The job of a platform product manager is to go deep enough into that complexity to make real trade-offs with engineering, and then absorb it, so the customer sees something simple: a policy, an API, a reliability number they can plan around. The technology can be hard. The customer experience has to feel simple.
A platform without a roadmap is just plumbing
Treating a platform as a product means it gets the same discipline as anything customer-facing: a clear problem statement, a roadmap, launch criteria, and a point of view on what you will not build. The moment a platform becomes a queue of internal requests, it stops compounding value and starts accumulating cost.
That's the lens I bring to platform work, whether the builders are developers on a global CDN, teams inside a hyperscale cloud, or carriers launching connectivity products across new markets.