How would you know whether an internal platform is succeeding?
Show the full answer Hide the answer
What is being tested
Whether you apply product thinking to internal software, where it is most often absent.
Why voluntary adoption is the measure
An internal platform has users with alternatives — including building their own. If teams under deadline pressure choose the platform, it is genuinely better. If they route around it, that is a product finding, and it is more useful than any capability assessment.
Mandating adoption destroys the signal. A platform that must be mandated is one that would not survive on its merits, and the mandate hides that fact from the team that most needs to know it.
The measures that follow
- Adoption rate, and its trend.
- Delivery outcomes for teams on the platform versus off it: lead time, deployment frequency, change failure rate, time to restore. This comparison is the evidence that justifies the team's existence.
- Time to first deploy for a new service. The clearest single number for developer experience.
- Support burden, which should fall as documentation and self-service improve.
- Exception requests, which are the roadmap: a pattern of teams leaving for the same reason identifies the next thing to build.
Why the other options mislead
Features shipped is output, not outcome. A platform team can ship steadily and improve nothing.
Compliance with a mandate measures enforcement, not value.
The team's own assessment is the least reliable input available, and it is what discovery exists to replace.
What product thinking changes in practice
- Discovery. Talk to the engineers who will use it. Their most painful problem is frequently not the one the platform team assumed, and this is the cheapest correction available.
- Documentation and onboarding as features, because they determine adoption more than capability does.
- A roadmap prioritised by user value rather than by technical interest.
- Deprecation done properly, with notice and migration support — platform users have the same problems any API consumer does.
The distinction that determines success
Self-service, not request-based. A platform team that performs work on request is a functional team with a new name: it preserves the handoff it was meant to remove and becomes the organisation's delivery bottleneck.
The nuance worth adding
Some things are genuinely not optional — identity, audit logging, encryption in transit. Treating a mandatory control as a product to be adopted voluntarily is a category error.
The resolution: embed mandatory controls inside enabling capabilities, so compliance is a side effect of using the convenient path. That is what a paved road is.