A performance measure is a defined indicator used to judge whether a platform initiative delivers its intended outcome. Choose it alongside the outcome, not after building the capability: a platform can be technically sound yet fail to improve delivery, adoption, or business value. section 3.2.2 section 10.1.1
Build a useful set of measures in stages:
- State the intended outcome and the assumptions behind it; revisit those assumptions as conditions change. section 3.2.2
- Select indicators for adoption, delivery friction, reliability, and autonomy where they match the goal. Track them over time rather than treating one reading as proof of value. section 10.1.1
- Measure cost as well as benefit, including engineering, infrastructure, and licensing costs when assessing an investment. section 3.2.2
- Add domain-level and software-delivery-lifecycle measures to locate where progress or improvement is needed. section 3.5.4 section 3.6
A delivery-speed outcome
Suppose a platform capability is intended to shorten the path from a first environment to production. A 30% reduction in average elapsed time is a concrete success measure. Pair it with adoption data to check whether teams actually use the capability, and assess its cost before claiming net value. section 3.2.2 section 10.1.1
Do not confuse a success measure with every metric a system emits. CPU usage, HTTP errors, logs, and traces help reveal or diagnose system behavior; a platform KPI tests progress toward a chosen outcome. Use objective and subjective evidence, including developer satisfaction, rather than relying on revenue alone. Set business-aligned measures early, then use the results to guide incremental improvement. section 5.1.1 section 3.6 section 10.8
