Platform Team Product Model
Running an internal platform team with product management disciplines — users, roadmap, support, metrics — rather than as an infrastructure function.
The distinction that determines whether a platform team succeeds: is it reducing cognitive load for product teams, or is it a gate they must pass?
The product model requires the things a product has: identified users and research into what actually slows them down; a roadmap consumers can plan against; documentation and self-service onboarding, where the measure is time from arriving to first successful use; a support model; and adoption and satisfaction metrics, which are the platform's equivalent of revenue.
The justification is cognitive load, not reuse. A product team can only hold so much; the platform's job is to reduce what each team must understand in order to ship safely. Framing it as reuse leads to building shared components nobody wanted.
The failure modes this model names precisely:
The gatekeeper platform, which reintroduces the queue it was created to remove — usually because it is under-resourced relative to demand rather than through intent.
The platform built on assumptions, where the team built what it found interesting.
The undemonstrated platform, defunded at the first cost review because its benefit is diffuse and its cost is a visible line item — which is why the metrics are not optional.