🏗️ Platform as a Product Language

"Platform as a product" is the practice of treating an internal developer platform with the same product discipline applied to external customer products. This means defining an internal customer (the developer), measuring adoption and satisfaction, maintaining a product roadmap, and iterating based on feedback. The phrase signals a shift from viewing platforms as purely technical infrastructure to seeing them as products that must earn adoption.

Developer experience (DX) refers to how easy, productive, and satisfying it is for engineers to use a platform or tool. For internal platforms, poor DX leads to shadow IT — developers building their own workarounds rather than adopting the platform. Key DX metrics include time-to-first-deployment (how quickly a new team ships their first service using the platform) and developer NPS (Net Promoter Score collected from internal platform users).

Team Topologies (by Skelton and Pais) defines four team types: stream-aligned teams deliver value directly to customers; platform teams build internal platforms that reduce cognitive load; enabling teams help stream-aligned teams adopt new capabilities; and complicated-subsystem teams own components requiring specialist knowledge. In conversation you might say: "Our infra team functions as a platform team — we build and maintain the deployment platform that stream-aligned teams use."

"Dogfooding" (from "eating your own dog food") means using your own product internally before releasing it to external customers. For platform teams, dogfooding means the platform team itself uses the platform to deploy its own services. You might say: "We dogfood our CI/CD platform — every pipeline we run goes through the same tooling we give to product teams." It signals commitment to quality and surfaces issues before external users encounter them.

A golden path (also called paved road) is the opinionated, well-supported set of tools and workflows a platform team recommends engineers follow. Rather than mandating a single approach, the golden path lowers the cost of doing the right thing. Platform teams say: "We don't block you from using other tools, but the golden path gives you templates, documentation, and first-class support out of the box." High adoption of the golden path is a key platform health metric.

Deprecation communication typically follows a sunset timeline: announce deprecation with a migration guide, set a hard end-of-life date, and provide migration tooling. Standard language includes: "We are deprecating v1 of the deployment API. Support ends on [date]. Please migrate to v2 using the migration guide linked in the developer portal. The platform team is available for office hours every Tuesday if you need help." Giving adequate notice and providing active support is essential for internal customer trust.

DORA (DevOps Research and Assessment) metrics are four key measures of software delivery performance: deployment frequency, lead time for changes, change failure rate, and time to restore service. Platform teams reference them to demonstrate platform value: "Since migrating to our new CI/CD platform, the stream-aligned teams using it have improved their deployment frequency by 40% and reduced their lead time from 3 days to 4 hours." These metrics frame platform investment in business-outcome language.

An internal developer portal (IDP) is a centralised web interface that aggregates platform services, documentation, service catalogs, and self-service tooling for developers. Key vocabulary: service catalog (a registry of all services and their ownership), scaffolding (generating new service templates), software templates, and tech radar (a visual guide to approved/experimental/deprecated technologies). Backstage by Spotify is the most widely used open-source IDP framework.

Platform adoption language in stakeholder meetings focuses on business outcomes: "We currently have 18 of 24 stream-aligned teams onboarded to the platform, representing 75% adoption. Time-to-first-deployment for new teams has dropped from 2 weeks to 3 days. Our developer NPS is +42, up from +18 last quarter." Using concrete percentages, before/after comparisons, and developer satisfaction scores translates platform work into language executives understand.

This phrase describes the cultural positioning of a platform team. A gatekeeper platform mandates its use, controls access, and creates bottlenecks — engineers must wait for the platform team to do things for them. An enabler platform provides self-service capabilities and documentation so engineers can move independently. Platform teams prefer the enabler framing: "Our goal is to reduce your cognitive load, not to add approval steps. Everything on the platform is self-service."