A platform team is funded as a cost centre and is being asked to justify itself. What changes if it is funded as a product?
Show the full answer Hide the answer
What changes
Cost centres optimise for cost; product teams optimise for adoption. That single difference determines what gets built.
A cost-centre platform team invests in efficiency and consolidation, because those reduce the number they are measured on. Documentation, onboarding, support and developer experience look like overhead — and they are exactly what turns a platform from something teams are made to use into something they choose.
A product-funded team invests in adoption, which requires all four.
What justification should look like either way
Not the platform's cost, but the counterfactual. The question is what teams would spend building and operating these capabilities themselves — which is measurable by looking at what teams did before the platform existed, and at what teams outside it still do.
Plus flow metrics compared between teams on and off the platform, which is the only comparison that tests the value proposition directly.
The measurement trap to avoid
Coverage as the headline number. A service can be "on the platform" while the team still maintains its own deployment tooling and observability, and coverage counts registrations rather than usage.
Voluntary adoption of new capabilities is the honest signal: when the platform ships something and teams adopt it without being asked, it is a product.
The specific risk in a fast-growing company
A platform team formed too early builds for imagined needs. With four product teams there is not enough commonality to abstract, and the platform's assumptions come from the first team's requirements.
The trigger worth waiting for is repeated duplication: the same capability built independently three times is evidence that a shared version would be used. Building before that is speculation, and the resulting platform is generic along the wrong axes.
The framing that gets it funded
"Teams currently spend N weeks per service on capabilities we could provide once." That is a number the business can evaluate, and it is available by asking the teams — which is a day of work and is more persuasive than any architectural argument.