Platform as a Product
Running an internal platform with users, a roadmap and adoption metrics — because a platform that must be mandated is one that has not earned its use.
Definition
Treating an internal platform as a product: it has users (engineers), a value proposition (reduced cognitive load and time to production), competitors (building it themselves, or a cloud service), and a success measure (voluntary adoption).
Why the framing matters
A platform that must be mandated is one that would not survive adoption on its merits — and mandating it destroys the only reliable signal about whether it is good.
Teams under deadline pressure will use a genuinely better path without being told. If they are routing around it, that is a product finding, and it is far more useful than a compliance conversation.
What it requires
- Discovery. Talk to the engineers who will use it. Their most painful problem is frequently not the one the platform team assumed.
- A roadmap, prioritised by user value rather than by technical interest.
- Adoption as the primary metric, alongside time to first deploy, lead time and incident rate for teams using it.
- Documentation and onboarding treated as features, because they determine adoption more than capability does.
- Support, with a defined response expectation. A platform whose users cannot get help is one they will abandon.
- Deprecation done properly, with notice and migration support, because the platform's users have the same problems its consumers do.
The paved road
The strongest form: a paved road that is the easiest path, carrying compliance, security and operational best practice as side effects. Teams may leave the road, at their own cost — which keeps the platform honest and provides the signal.
That is materially different from a mandate: compliance becomes a consequence of choosing the convenient option rather than an obstacle to be routed around.
The failure to avoid
A platform team as a ticket queue. Teams file requests; the platform team performs work. That is a functional team with a new name, it preserves the handoff it was meant to remove, and it becomes the organisation's delivery bottleneck.
The distinction is self-service: the platform provides capability that teams use themselves, not work performed on request.
Failure scenarios
- Built on assumptions, launched, unadopted.
- Adoption mandated, so the quality signal is lost and the team never learns.
- No documentation, so the platform is only usable by people who can read its source.
- Success measured in features shipped rather than in teams' outcomes.
- A platform that constrains more than it enables, which teams correctly resist.
Interview question
"Teams are avoiding the internal platform and building their own tooling. What do you conclude?"