Software product health is measurable with about ten numbers across four dimensions: delivery, reliability, usage and cost. Reviewed quarterly against the previous quarter, they tell you whether a product is improving or decaying long before anyone feels it, which is the point, because by the time decay is obvious it is expensive.
This guide covers the scorecard, what good looks like for each measure, and the review cadence that makes it useful rather than another report.
Key takeaways
- Trend beats absolute value: Direction over three quarters matters more than any single reading.
- Four dimensions, or you optimise one at the cost of others: Delivery, reliability, usage, cost.
- Lead time is the best single indicator: How long a small change takes captures most underlying health.
- A scorecard nobody reviews is worse than none: It creates the impression of oversight.
The four dimensions
| Dimension | Measures | What it reveals |
|---|---|---|
| Delivery | Lead time for a small change, deployment frequency, change failure rate | Whether the system is getting harder to change |
| Reliability | Uptime, incident count, mean time to recovery, error rate | Whether it works |
| Usage | Active users, activation rate, feature adoption, task completion | Whether it is worth running |
| Cost | Infrastructure spend, cost per active user, maintenance share of capacity | Whether the economics hold |
Any one dimension alone can be improved at the expense of the others. Delivery speed rises when testing is skipped; reliability rises when nothing ships; cost falls when maintenance stops. Reviewing all four together is what prevents optimising the number rather than the product.
What good looks like
| Measure | Healthy | Investigate |
|---|---|---|
| Lead time for a small change | Days | Weeks and growing |
| Deployment frequency | Weekly or more | Monthly or less |
| Change failure rate | Under 15% | Above 30% |
| Mean time to recovery | Under a day | Days |
| Crash-free sessions (mobile) | Above 99.5% | Below 99% |
| Maintenance share of capacity | 15–25% | Above 40% |
| Infrastructure cost per active user | Stable or falling | Rising with flat usage |
These are orientation rather than universal targets, a regulated system with formal change control will deploy less often by design. What matters is whether your own numbers are moving in the right direction.
Lead time is the number to watch
If you track only one thing, track how long a small, well-understood change takes from request to production.
It captures almost everything: test coverage, deployment automation, architectural coupling, team knowledge and approval overhead all show up in it. When lead time grows steadily while the team stays the same size, the system is charging interest, and that is the earliest reliable signal of accumulating technical debt.
Measure a genuinely small change: a label, a validation rule, a configuration value. Averaging across all work sizes hides the signal.
Include the cost dimension
Product health is not only technical. A product whose infrastructure cost rises faster than its usage has an economic problem that will eventually become a product decision.
Track infrastructure and third-party spend, and cost per active user. A rising cost per user with flat usage means something is inefficient and nobody has looked; it is the most commonly missing dimension in engineering scorecards and the one finance asks about first.
Also track the maintenance share of engineering capacity. Below 10% the product decays; above 40% you are servicing debt rather than building, and the underlying cause needs addressing rather than the symptom.
Score it, but keep the numbers visible
A single health score is useful for a portfolio view and dangerous on its own, because it hides which dimension is failing.
Where you need one, weight the dimensions explicitly and always show the components alongside. A product scoring amber overall because cost is rising needs a completely different response from one scoring amber because reliability is falling.
Review quarterly, with a defined response
Quarterly is the right cadence for a product scorecard: often enough to catch a trend, rare enough that the numbers move meaningfully between readings.
Agree in advance what triggers action. A measure crossing a threshold should produce a named owner and a date rather than a discussion. Scorecards decay into reporting when nothing is required to happen as a result.
Review the trend, not the reading. Three quarters of direction tells you far more than one quarter of absolute value, and it is much harder to argue with.
Use it to decide investment
The scorecard's real purpose is allocating next quarter's capacity. Poor delivery numbers argue for tooling and test investment; poor reliability argues for stabilisation; poor usage argues for product work or for retiring something; poor cost argues for optimisation.
Without it, that allocation is decided by whoever advocates most persistently, which is how products end up with an extensive feature set, a slow release cycle and an infrastructure bill nobody can explain.
Know when to stop measuring something
Retire measures that have not changed a decision in a year. A scorecard accumulates numbers the way a codebase accumulates debt, and a page of green metrics nobody acts on gives false comfort.
Four dimensions, two or three measures each, reviewed quarterly with a defined response. That is enough to run a product and small enough that it will actually happen.
Related guides
- Before committing to any of it, read AI Workflow Automation: Use Cases, Risks, and Roadmap.
- The same trade-off from the other side appears in Admin Dashboard Development: Features, Architecture, and Cost Drivers.
When the legacy problems in Software Product Health: Metrics, Scorecard, and Review Cadence need a sequenced plan, Discuss Your Modernization Plan.
Ali Boran Gazel