A platform team builds capabilities that teams do not adopt. What does treating the platform as a product actually require, and how is adoption measured without mandates?

Why mandates fail

A mandated platform has captive users, no feedback signal and no competitive pressure. Teams comply minimally, work around it where they can, and the platform team learns nothing about whether it is useful — because usage no longer indicates value.

Mandates also invert the incentive: the platform team optimises for compliance reporting rather than for developer outcomes, and the platform's quality becomes disconnected from its adoption.

What product thinking actually requires

• Users who could choose otherwise, at least in principle, so adoption is evidence.
• Understanding the job to be done. Not "teams should use our deployment pipeline" but "teams need to get a change to production safely in under an hour" — which may or may not be best served by the thing that was built.
• A defined user and a defined non-user. A platform serving every possible case serves none well; saying who it is not for is what makes it good for someone.
• A roadmap driven by user research — actually talking to engineers about their friction — rather than by the platform team's architectural preferences.
• Documentation, onboarding and support as first-class deliverables. An undocumented platform capability does not exist, and this is the single most common reason good platform work goes unadopted.
• SLOs on the platform itself, published, so teams can depend on it and know what they are depending on.
• A migration path off, which sounds counterproductive and is what makes adoption safe: a platform that cannot be left is a risk, and teams evaluate it as one.

The paved road, properly understood

The paved road is the path that is easier than the alternatives, not the only permitted path.

• Genuinely easier: a new service with pipeline, observability, alerting, secrets and deployment in minutes versus days of assembly. If the paved road is not faster than doing it yourself, it will not be taken.
• Off-road is permitted and costs more — the team assembles it themselves, operates it themselves, and carries the compliance obligations themselves. The cost is real and it is not a punishment.
• What is off-road today informs the roadmap. Repeated deviation in the same direction is a requirement the platform has not met, and it is the most valuable input the platform team receives.

Measuring adoption honestly

• Voluntary adoption rate, and its trend. The number that matters.
• Time from zero to a running service, which is the platform's core value proposition made measurable.
• The proportion of teams that tried it and left, which is a much stronger signal than the proportion that never tried.
• Developer satisfaction, surveyed regularly, segmented by team so that a dissatisfied minority is visible.
• Support burden per adopting team, which should fall as the platform matures — a rising figure means complexity is being pushed onto users.
• Lead time and change failure rate for adopting versus non-adopting teams, which is the outcome the platform exists to improve and is rarely measured.

What not to measure: the number of capabilities shipped. It is the metric most platform teams report and it correlates with nothing users care about.