Capacity Allocation
Breakdown of engineering capacity across new features, maintenance, and tech debt — typically reported as a three-way split summing to 100%. The execution-level view of where engineering hours are actually going (vs. `innovation_capacity_pct` which is a single percentage for new-capabilities work, and vs. `offensive_roadmap_pct` which is a roadmap-classification percentage). Common pitfall: capacity allocation reported in plan rather than actuals. The plan can say 60% new features but the actuals can be 30% new features and 50% support work — the gap is the operating signal. Boards should require both planned and actual splits, at least quarterly. — Product KPI, I'mBoard-authored (editorial tier).
I'mBoard-authored (editorial tier)
No public third-party standard anchors this KPI yet, so I'mBoard authors and maintains the definition — transparently labeled as editorial tier. See the ontology methodology for the published vs editorial tier system and the back-attribution workstream.
Rogue ID: product.capacity_allocation_pct
Type: Percentage (%)
Domain: Product
Definition
Breakdown of engineering capacity across new features, maintenance, and tech debt — typically reported as a three-way split summing to 100%. The execution-level view of where engineering hours are actually going (vs. innovation_capacity_pct which is a single percentage for new-capabilities work, and vs. offensive_roadmap_pct which is a roadmap-classification percentage). Common pitfall: capacity allocation reported in plan rather than actuals. The plan can say 60% new features but the actuals can be 30% new features and 50% support work — the gap is the operating signal. Boards should require both planned and actual splits, at least quarterly.
Formula
Three-way breakdown: new_features_pct + maintenance_pct + tech_debt_pct = 100%. Measured in the same unit as capacity (eng-weeks, story points, or sprint capacity). Report planned vs actual split — the gap is the operational signal.Why it matters
Names where engineering hours actually go. The plan-versus-actual gap is one of the highest-signal operational metrics for the board — a persistent 20+ point gap between planned and actual new-feature allocation is the loudest possible flag that the company is under-investing in platform health (the missing hours are going to firefighting).
How to interpret
Industry folk-wisdom, not citation-grade: a healthy steady-state split at growth-stage SaaS is roughly 50–70% new features, 15–30% maintenance, 10–20% tech debt. Companies in platform-investment cycles will skew toward maintenance and tech debt. Pair with innovation_capacity_pct and delivery_predictability — capacity allocation tells you where time goes, predictability tells you whether commitments hold, innovation capacity tells you the available headroom for offense.
Related KPIs
product.innovation_capacity_pctproduct.offensive_roadmap_pctproduct.defensive_roadmap_pctproduct.delivery_predictabilityproduct.total_engineers
Source
I'mBoard editorial — authored and maintained by I'mBoard, first published 2026-04-01. No third-party standard is cited for this KPI; when one emerges, the definition is back-attributed and promoted to the published tier (a minor version bump). Read the ontology methodology for the published vs editorial tier system, attribution rules, and dispute process.
Stage relevance
| Company stage | Priority |
|---|---|
| Series A | Recommended |
| Series B | Recommended |
| Series C+ | Recommended |
| Public | Recommended |
Suggested for stages: Series A, Series B, Series C+, Public.
Default owning functions
- Product
Machine-readable
- This KPI as JSON:
/api/ontology/product/capacity_allocation_pct.json - All Product KPIs:
/api/ontology/product.json - Full catalog:
/api/ontology/index.json
Product KPIs
Roadmap, delivery, R&D efficiency, quality. 16 KPIs in this domain — 1 anchored to third-party standards, 15 editorial.
Revenue Protection %
Percentage of the planned roadmap allocated to defensive work — platform reliability, security/compliance, scalability rearchitecture, table-stakes parity with competitors, customer-retention features. The complement of `offensive_roadmap_pct`. Common pitfall: defensive work is chronically under-funded (less visible to customers, harder to demo) until a quality-churn or scalability event forces a reactive surge. Boards should treat sustained zero or near-zero defensive allocation in a maturing product as a leading indicator of future quality issues — per the standard product-management argument (Marty Cagan and similar product-leadership writing), a healthy roadmap pays both growth and platform-health rent. — Product KPI, I'mBoard-authored (editorial tier).