An internal platform team's tools are avoided by product teams who build their own. What does treating the platform as a product change?

The diagnosis

The platform is being built as infrastructure and consumed as a product, and the gap is the adoption problem.

Infrastructure is mandated; products are chosen. When teams can route around a platform, they will unless it is genuinely better than the alternative — and "better" is judged by the consumer, not the builder.

What changes when it is treated as a product

1. Adoption is the success metric, not delivery. A capability nobody uses has not been delivered. This single change in metric reorients everything else.

2. Users are researched, not assumed. Talk to product teams about what they actually do, watch them use the platform, and find where they struggle. Platform teams frequently build for a workflow nobody has.

3. The paved road must be faster than the alternative. Not merely compliant, not merely recommended — faster. A team that can provision a compliant environment in an hour will use it; a team facing a six-week intake will build their own and will be right to.

4. Documentation and onboarding are the product, not an afterthought. If getting started takes a day of reading, adoption suffers regardless of the platform's quality.

5. Migration is the platform team's job. Telling teams to migrate is a request that competes with their roadmap and loses. Providing tooling, doing the work, or making the migration trivial is what actually moves adoption.

6. Backward compatibility and deprecation policy, because internal consumers are as broken by a breaking change as external ones, and a platform that breaks its users loses them permanently.

The measurement

• Adoption rate and time-to-first-success for a new team.
• The proportion of teams on the paved road versus building their own — the honest measure of whether the platform is winning.
• Support burden per consuming team, which indicates whether it is genuinely self-service.
• Platform SLOs, published and met, because consumers taking a dependency need to know what they are depending on.

The uncomfortable finding

If teams are building their own, the platform is losing on some dimension its team is not measuring — usually speed of onboarding, flexibility for a legitimate case, or reliability.

The response is to find that dimension, not to mandate adoption. Mandating a platform teams do not want produces compliance and resentment, and the workarounds move underground where they are harder to see and support.