Innovation Capacity %
Percentage of R&D capacity (typically measured in engineering-weeks or story points over a quarter) allocated to net-new capabilities, as opposed to maintenance, bug fixes, internal tooling, or customer-support engineering. The "available bandwidth for offense" view. Common pitfall: confusing innovation capacity (input — how much team-time is available for new work) with `offensive_roadmap_pct` (output — what proportion of the planned roadmap is growth-oriented). A team can have 60% innovation capacity allocated entirely to defensive work if the roadmap demands it. Boards should look at both together. — 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.innovation_capacity_pct
Type: Percentage (%)
Domain: Product
Definition
Percentage of R&D capacity (typically measured in engineering-weeks or story points over a quarter) allocated to net-new capabilities, as opposed to maintenance, bug fixes, internal tooling, or customer-support engineering. The "available bandwidth for offense" view. Common pitfall: confusing innovation capacity (input — how much team-time is available for new work) with offensive_roadmap_pct (output — what proportion of the planned roadmap is growth-oriented). A team can have 60% innovation capacity allocated entirely to defensive work if the roadmap demands it. Boards should look at both together.
Formula
innovation_capacity_pct = (engineering_capacity_on_new_capabilities / total_engineering_capacity) × 100. Define "new capabilities" explicitly — typically excludes bug fixes, performance work, internal tooling, support engineering, and tech-debt paydown. Measured in the same unit as capacity allocation (eng-weeks, story points, or sprint capacity).Why it matters
Surfaces structural friction. A team with only 20% innovation capacity is being eaten by maintenance and reactive work — the board should be asking why (platform debt, support load, headcount mismatch) before approving new feature commitments.
How to interpret
Industry folk-wisdom, not citation-grade: 50–70% innovation capacity is typical for healthy growth-stage product engineering; below 40% suggests the team is operating in firefighting mode; above 80% suggests under-investment in platform health (will eventually pay back in quality_churn_pct and scalability_headroom compression). Trend matters most — a steady decline quarter-over-quarter is a leading indicator of accumulating maintenance debt.
Related KPIs
product.capacity_allocation_pctproduct.offensive_roadmap_pctproduct.defensive_roadmap_pctproduct.rd_efficiencyproduct.delivery_predictability
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
- R&D
- Product
Machine-readable
- This KPI as JSON:
/api/ontology/product/innovation_capacity_pct.json - All Product KPIs:
/api/ontology/product.json - Full catalog:
/api/ontology/index.json
Weighted Feature Adoption
Percentage of customers (weighted by ARR) actively using a defined set of strategic features within a measurement window. The "ARR-weighted" framing matters: a feature used by 30% of customers covering 70% of ARR is a different signal than 30% of customers covering 5% of ARR. Common pitfall: defining adoption as "ever used" rather than "actively using" (returning use in the measurement window) — the first metric only goes up and tells the board nothing. Boards should require an active-use definition (e.g. used in 2 of the last 4 weeks) and a per-feature breakdown for the strategic feature set. — Product KPI, I'mBoard-authored (editorial tier).
Key Initiatives
Container handle for the field-array of strategic product initiatives committed for the current quarter / half — each entry tracks the initiative name, status (on-track / at-risk / blocked / shipped / cut), owner, target date, and a one-line explanation or mitigation plan. The structured, per-initiative companion to the `product.key_initiatives_status` narrative: the narrative gives the execution-pulse story, this gallery makes each initiative individually trackable with its own owner and status. Renders via the CollapsibleFormItemCardGallery widget (the reused gallery pattern shared with sales pipeline deals and HR key hires / openings). Common pitfall: every initiative defaults to "on-track" until two weeks before its deadline — require an explicit at-risk state with a mitigation plan, not a re-label at the deadline. — Product KPI, I'mBoard-authored (editorial tier).