Time to Capacity Limit
Months of system capacity remaining at the current growth rate before the platform requires major (not incremental) infrastructure investment — typically driven by the binding bottleneck (database, message bus, single-tenant compute ceiling, regional capacity, or compliance-driven re-architecture). Surfaces the "scale runway" alongside the financial runway. Common pitfall: a single number hides which bottleneck binds. Boards should require the bottleneck to be named ("database shard hot-spot binds at ~150K accounts at current growth, ~4 months out"), not just the headline months — a named bottleneck makes the investment decision concrete. — 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.scalability_headroom
Type: Number (months)
Domain: Product
Definition
Months of system capacity remaining at the current growth rate before the platform requires major (not incremental) infrastructure investment — typically driven by the binding bottleneck (database, message bus, single-tenant compute ceiling, regional capacity, or compliance-driven re-architecture). Surfaces the "scale runway" alongside the financial runway. Common pitfall: a single number hides which bottleneck binds. Boards should require the bottleneck to be named ("database shard hot-spot binds at ~150K accounts at current growth, ~4 months out"), not just the headline months — a named bottleneck makes the investment decision concrete.
Formula
Engineering-attested estimate: months_until_binding_bottleneck_at_current_growth_rate. Recompute when growth-rate assumption changes or when capacity work lands. Always surface the binding bottleneck name alongside the months number — `12 months (database write throughput)` not just `12`.Why it matters
Sequences major infrastructure work against revenue growth. A 6-month scalability headroom against a 9-month financial runway is a foreseeable crisis the board should be addressing now. Pairs naturally with defensive_roadmap_pct (which funds the work).
How to interpret
Industry folk-wisdom, not citation-grade: 12+ months of headroom is comfortable; 6–12 months means the rearchitecture project should be in flight; under 6 months means the project is critical-path and may already be late. Compare against finance.runway_months — financial runway shorter than scalability headroom means the company will hit the cash wall first; the inverse means the company will hit the scale wall first and should be planning the rearchitecture into the current operating plan.
Related KPIs
product.defensive_roadmap_pctproduct.capacity_allocation_pctproduct.quality_churn_pctfinance.runway_monthssales.growth_rate_yoy
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.
Industry benchmark
A reference distribution sourced from imboard Editorial (2026):
| Percentile | Value |
|---|---|
| 25th | 4months |
| Median | 9months |
| 75th | 18months |
Higher is better.
Stage relevance
| Company stage | Priority |
|---|---|
| Series A | Core |
| Series B | Core |
| Series C+ | Recommended |
| Public | Recommended |
Suggested for stages: Series A, Series B, Series C+, Public.
Default owning functions
- R&D
Machine-readable
- This KPI as JSON:
/api/ontology/product/scalability_headroom.json - All Product KPIs:
/api/ontology/product.json - Full catalog:
/api/ontology/index.json
R&D Monthly Spend
Total monthly cash outflow on research and development — fully-loaded engineering, product, and design payroll plus tooling, infrastructure dedicated to product development, contractors, and direct R&D vendor spend. The "input" side of R&D efficiency. Common pitfall: companies report base-payroll R&D and exclude the loaded cost (benefits, stock comp at cash-cost basis, allocated rent, dev tooling), under-reporting true R&D burn by 25–40%. Boards should always ask whether the number is base-payroll, fully-loaded, or GAAP R&D expense — they tell different stories. The KBCM/Sapphire SaaS Survey reports R&D as a percentage of revenue for its company panel — use that as the benchmarking lens. — Product KPI anchored to KBCM/Sapphire SaaS Survey 2024 (15th Annual).
Top Product ARR Concentration
Percentage of total ARR contributed by the single largest product line. Diversification-risk indicator at the product level (parallel to customer-concentration risk at the GTM level). Common pitfall: concentration risk is dismissed when the dominant product is performing well — but a one-product company is a one-feature-decision-away from existential risk. Boards should track this number alongside the portfolio narrative; sustained 70%+ concentration in a maturing company should pair with a documented diversification thesis or an explicit decision to remain a single-product company. Frames analogous to customer-concentration discussions in venture diligence (NfX / Bessemer founder essays cover the customer-side; the product-side analogue follows the same logic). — Product KPI, I'mBoard-authored (editorial tier).