Platform Product Metrics: How to Tell Whether Your Internal Platform Is Helping
A measurement framework for internal platforms: adoption, golden paths, delivery friction, service health, developer trust and cost to serve.
A platform team told its executive sponsor that adoption had doubled. That sounded like progress until someone asked a basic question: adoption of what? The portal had twice as many logins. The golden path had fewer completed deployments. Developers were still filing tickets to get an environment.
A platform is not a product because it has a UI. It is a product because it makes a defined customer journey easier, faster or safer. If the measurement system cannot distinguish a login from a successful journey, it is measuring attention rather than value.
Atlassian’s internal developer platform guidance is useful here because it frames an IDP as a self-service interface for the tools, services and knowledge developers need to deliver software. It emphasises component information, scorecards, integrations and golden paths rather than a dashboard alone. (opens in a new tab) The right metric stack follows the same logic: measure the journeys that the platform is meant to improve.
Start with the platform promise
Before choosing a metric, write down the promise in one sentence. Examples:
- “A new service can reach a compliant production path without a platform ticket.”
- “An on-call engineer can identify an owned service and its runbook in under five minutes.”
- “A team can discover the approved deployment path and use it by default.”
Each promise has a user, a journey and an observable outcome. That is your measurement boundary. Without it, every platform team ends up measuring whatever their tooling makes easy: page views, API calls and the number of templates created.
The scorecard has six dimensions
| Dimension | What it asks | Useful measures | Bad proxy to avoid |
|---|---|---|---|
| Reach | Can the intended customers access the platform? | Eligible teams onboarded; services catalogued; active users by role | Total accounts created |
| Adoption | Do they choose the platform path? | Golden-path completion rate; self-service versus ticket route | Portal logins |
| Friction | Is the journey materially easier? | Time to first PR; environment lead time; failed setup rate | Average page load time alone |
| Reliability | Does the platform keep its promises? | Path success rate; platform SLOs; recovery time | Infrastructure uptime without user outcome |
| Trust | Do developers believe the platform helps? | Task-level satisfaction; repeat use; documented escape hatches | Annual sentiment survey only |
| Economics | Is the platform a better use of capacity? | Cost to serve; hours avoided; support demand; marginal cost per new team | Total platform spend without a denominator |
The dimensions are deliberately balanced. A platform that is reliable but unused has not succeeded. A platform that is popular but forces users through a fragile bottleneck has merely centralised the pain.
Measure a journey end to end
Take service creation. The typical journey starts before the platform: a developer needs a repository, deployment baseline, ownership record, security controls, observability and a way to get help. The platform succeeds when the developer reaches a usable, governed service with fewer handoffs.
| Journey stage | Evidence to measure | Decision if it deteriorates |
|---|---|---|
| Discover | Time to find the correct path; search failure rate | Improve information architecture or deprecate duplicate routes |
| Start | Template-start rate; time to first commit | Simplify defaults and preconditions |
| Configure | Required manual fields; policy exceptions | Move repeated configuration into the golden path |
| Deploy | Successful deployment rate; lead time | Fix integration and environment bottlenecks |
| Operate | Ownership, runbook and SLO coverage | Enforce catalogue completeness before production |
| Learn | Repeat use; task-level satisfaction; support contacts | Interview users, not just platform champions |
This is more useful than a single DORA-style metric because it tells the platform team where the platform is failing the customer. Delivery metrics remain valuable. They are not a substitute for product instrumentation.
Keep a leading and lagging measure together
The most common reporting mistake is to select a lagging business metric and wait. “Developer productivity improved” is a claim you may only be able to prove after quarters. Pair it with a leading behaviour that the platform directly controls.
| Platform goal | Leading indicator | Lagging confirmation |
|---|---|---|
| Faster safe service creation | Golden-path completion without ticket | Reduced time to first production deployment |
| Better operational ownership | Service records with owner, runbook and SLO | Lower time to identify owner during incidents |
| Lower cognitive load | Self-service task completion and task-level satisfaction | Higher engineering retention or delivery confidence |
| Better guardrails | Policy checks passed through the path | Fewer late-stage security or compliance rework events |
| Efficient platform spend | Marginal cost to onboard a team | Lower support burden per team |
Do not claim causation from the lagging number alone. Platform teams influence delivery alongside architecture, staffing, product scope and organisational change. The honest story is a chain of evidence: the platform path was used, it removed a known friction point, and the relevant outcome moved in the expected direction.
The metric that exposes performative platforms
Track self-service completion rate for the journeys the platform claims to own. Count a completion only when the user reaches the intended state without a manual platform intervention.
That metric is uncomfortable because it exposes the difference between a portal and a service. A catalogue page that sends people to a Slack channel has reach but not self-service. A template that requires three tickets has adoption but not autonomy. Measure the handoffs and make their removal a backlog item.
What to do on Monday morning
Download the platform product scorecard. Choose one journey that hurts — service creation, production access or incident ownership — and instrument its end state. Populate the six dimensions with a named baseline, owner and review date.
Then revisit the Platform Operating Model insight and the Developers as Customers framework. They explain the organisational premise. This scorecard makes it measurable.
Your platform does not need more KPIs. It needs a small set of measures that force an honest answer to one question: did a developer complete a useful journey more easily because the platform existed?
I'm speaking on this — The Compute Infrastructure Questions Every AI Buyer Should Ask →