Platform as a Product

Platform as a product is the stance that an internal platform should be built and run the way a product is: with identified users, a roadmap driven by their needs, and success measured by whether they choose to use it.

Evan Bottcher’s much-quoted formulation puts the emphasis on the last part, describing a digital platform as a foundation of self-service APIs, tools, services, knowledge, and support arranged as a compelling internal product. The operative word is compelling. Teams adopt it because it is the better option, not because a policy requires it.

The contrast is with an internal developer platform run as a project or a mandate. A project has a completion date and a scope agreed in advance, which suits work whose requirements are known; a platform’s requirements arrive continuously from teams doing things nobody anticipated. A mandate removes the feedback that would reveal the platform is wrong, because usage no longer signals anything.

Three practical consequences follow. There is someone accountable for what gets built next, which is a product role whether or not it is titled that way. There is a way for users to raise needs that does not depend on knowing someone on the team. And there is a deprecation practice, because a product that never removes anything accumulates every decision it has ever made — and every option it keeps is cognitive load someone has to carry.

It is worth being clear about the limit of the analogy. Internal users are colleagues, not a market: they usually cannot leave, and the cost of a bad platform lands on the same organization that funded it. That makes voluntary adoption a better signal than satisfaction surveys, and it makes the awkward question — how many teams have built their own version of this? — the one worth asking regularly. Adoption of the golden path is the measurable form of it.

What this looks like for a data platform, where the users are analytics and product teams, is examined in Data Platforms and Developer Platforms.