Platform as a Product

Platform as a product means building and operating an internal platform around identified users and their work: understanding needs, maintaining a roadmap, and evaluating task success, time, reliability, and support burden. Voluntary adoption provides additional evidence when teams have a meaningful choice.

Evan Bottcher’s discussion of digital platforms emphasizes organizing reusable capabilities as an internal product that helps teams deliver with less coordination. Whether a platform is optional or mandated, its value still needs to be tested against users’ tasks and viable alternatives. A mandate alone establishes neither usefulness nor failure.

An internal developer platform needs continuing product management even when its initial delivery is organized as a project or its use is mandated. 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 one particular feedback signal — usage stops indicating preference — which is why a mandated platform has to work harder to learn: task success rates, time to complete common work, how often teams leave the supported path, and asking users directly.

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 worth watching for a specific reason: it is a preference expressed in behavior rather than in an answer. It is not automatically more reliable than the other signals, and it is not the only way to find out. Asking teams to compare the internal option against the alternative they would otherwise have chosen, or offering two supported paths and seeing which gets picked, are evidence about preference too.

An adoption figure is as movable as any metric: count trials as adoptions, or draw the population around the teams who were coming anyway, and it improves on its own. And teams choose the internal option for reasons that are not preference at all, such as a previous tool losing its budget or switching back being expensive. So an adoption figure means something only when you state the population and how free it was to decide otherwise.

The awkward question — how many teams have built their own version of this? — is worth asking regularly alongside adoption. Use of the golden path is one observable signal; interpret it alongside task outcomes and the reasons teams choose alternatives.

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

References

• Evan Bottcher, What I Talk About When I Talk About Platforms (2018)