Platform as Product
Running an internal platform with a product manager, a roadmap, identified users and measured adoption, rather than as a project with an end date.
The distinction is operational, not rhetorical. A project is funded to build a thing and then disbands; a product is funded to serve users continuously and is judged on whether they are served. Platforms funded as projects reliably reach a state where the capability exists, the team has moved on, nobody owns the roadmap, and the platform decays into a legacy dependency within two years.
Product thinking imports specific practices: users who can decline, discovery before building, a roadmap negotiated against demand, deprecation handled with notice and migration support, and success measured by adoption and user outcomes rather than by delivery of scope.
The hardest part is funding, since a platform's benefit is diffuse — it shows up as other teams being faster, which no single budget line captures. Platforms funded from a central engineering budget with a mandate to serve, and measured on adoption and on the delivery metrics of consuming teams, survive. Platforms cross-charged per unit of consumption tend to get gamed, since teams optimise for the chargeback metric rather than for good engineering.