Platform Product Management

The philosophy of treating an internal developer platform as a product — with a defined set of customers (engineering teams), a roadmap, a backlog, user research, and success metrics — rather than as a cost centre or shared service.

"Adopting 'platform as product' changed everything: we started running quarterly developer surveys to identify friction, prioritising features by adoption impact rather than technical elegance, and tracking developer NPS as our primary success metric."

Net Promoter Score applied to the internal developer experience — a single-question survey ("How likely are you to recommend this platform/tool to a colleague, on a scale of 0–10?") used to track platform satisfaction and identify friction points.

"Developer NPS for the deployment platform was +8 (out of a possible +100) in Q1. After shipping the self-service rollback feature and reducing deployment time from 25 to 7 minutes, dNPS rose to +44 in Q3. We quote both numbers in our board deck."

A pre-approved, templated, and well-documented development path that embeds organisational best practices — CI/CD, security scanning, observability, service templates — allowing teams to go from idea to production without custom toolchain decisions.

"The golden path for a new microservice is: run the scaffolding CLI tool → get a repo with pre-configured GitHub Actions, Dockerfile, Helm chart, SLO dashboards, and PagerDuty integration → push to main → service is live in the staging environment. First deploy in under an hour."

A team organisation framework defining four team types (stream-aligned, platform, enabling, complicated subsystem) and three interaction modes (collaboration, X-as-a-service, facilitating). Provides a shared vocabulary for discussing organisational design for fast software delivery.

"Using Team Topologies language helped the architecture review: Platform team provides Kubernetes and CI/CD X-as-a-service. The data pipeline team is a complicated subsystem team collaborating with stream-aligned product teams on integration interfaces. Three interaction modes, clearly documented."

A framework for measuring how engineering teams progress through stages of platform adoption: awareness → trial → active use → advocacy. Used to identify where teams drop off and which interventions improve adoption.

"Our adoption funnel shows 90% of teams aware of the new deployment platform, 70% have trialled it, 45% use it for at least one service, but only 20% have fully migrated. The drop from trial to active use is the biggest gap — exit interviews revealed missing Windows build support is the blocker."

The practice of a team using their own product — an internal development platform team using their own platform to deploy the platform itself. Provides firsthand experience of developer pain points and builds empathy with users.

"The platform team dogfoods all releases on the deployment system itself before shipping to other teams. When we deployed the new logging pipeline using our own tools, we immediately discovered the secret rotation flow had a 40-second delay that we'd never noticed in automated tests."

Objectives and Key Results applied to platform engineering — with objectives typically framed around developer productivity and platform reliability, and key results expressed as measurable improvements to DORA metrics, onboarding time, or developer NPS.

"Platform OKR for Q3: Objective: Reduce time for new teams to reach first production deployment. KR1: Onboarding time from 3 days → 4 hours (measured via golden path usage). KR2: Developer NPS for onboarding experience → +50. KR3: 80% of new services use the golden path (vs. 30% today)."

A synonym for golden path — an opinionated, supported default set of tools and practices that eliminates bikeshedding for common decisions. Teams can go off the paved road, but doing so is explicit and they accept responsibility for their tooling.

"'Off the paved road' is an explicit state in our architecture decision record template. A team choosing an unsupported database must document their reasoning and accept that the platform team does not support migrations, backup policies, or SLO dashboards for it."

The cognitive overhead, compliance requirements, and workflow constraints imposed on engineering teams by a mandatory internal platform — the cost of standardisation that must be outweighed by the efficiency gains the platform provides.

"Product teams complained about platform tax: 7 mandatory approval steps before a new microservice could be created. We reduced it to 2 automated gates and 1 architect review, cutting the 'new service' setup from 3 days to 4 hours. dNPS for platform onboarding improved immediately."

A self-service web interface that provides discovery, documentation, and provisioning capabilities for a developer platform — enabling teams to find services, request infrastructure, and access runbooks without going through a ticketing system.

"The internal developer portal runs on Backstage. Developers can see all services, their owners, SLO status, and documentation in one place, and can provision a new microservice using the golden path template without raising a ServiceNow ticket."