I'mBoard API Docs

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).

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.defensive_roadmap_pct Type: Percentage (%) Domain: Product

Definition

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.

Formula

defensive_roadmap_pct = (roadmap_capacity_allocated_to_defensive_initiatives / total_roadmap_capacity) × 100, where "defensive" includes reliability, security, compliance, scalability, parity, retention features, and tech-debt paydown. Complement of `offensive_roadmap_pct` (they sum to ~100% in a fully-classified roadmap).

Why it matters

Names the investment in not-losing alongside the investment in winning. A defensive % that responds to quality_churn_pct and scalability_headroom trends (rising when those degrade) is a sign of a healthy operating cadence; a defensive % stuck near zero while quality churn rises is a sign the board needs to push for re-prioritization.

How to interpret

Industry folk-wisdom, not citation-grade: 20–40% defensive at growth-stage SaaS with stable platform health; 40–60% during platform-investment cycles; below 15% rarely sustainable in a maturing product. Read alongside quality_churn_pct — a defensive ratio that has not increased while quality churn has been rising for 2+ quarters usually warrants a board-level conversation about reprioritization.

Calculation policy

How an AI agent should compute this KPI from messy company data. Free-text rules consumed at reasoning time — not a deterministic DSL. The most common ways to get this wrong are listed under Common miscomputations.

Inclusion rules

Share of planned roadmap capacity allocated to defensive work — platform reliability, security / compliance, scalability rearchitecture, table-stakes parity, customer-retention features, and tech-debt paydown.
Same denominator (total planned roadmap capacity for the horizon) and same unit as the offensive and commitments slices.
Classify each roadmap item to exactly ONE of the three intent slices.

Exclusion rules

Net-new capabilities / market expansion / differentiation — that is product.offensive_roadmap_pct.
Contractually committed deliverables — that is product.commitments_roadmap_pct.
The maintenance / tech-debt share measured against all engineering hours — that is the product.capacity_allocation_pct partition, a different denominator.

Required inputs

Classified roadmap item list with per-item capacity.
The horizon definition.
The reliability / security / scalability backlog, so defensive work is not under-counted.

Data-source priority

Roadmap planning tool with strategic-intent tags.
PM + engineering classification.
product.quality_churn_pct and product.scalability_headroom trends as a sanity check on whether defensive funding matches platform health.

Edge cases

Defensive work is chronically under-funded (less visible, harder to demo) until a quality or scalability event forces a reactive surge — watch for a near-zero defensive share in a maturing product.
An item that both hardens the platform and ships a feature: split its capacity across slices.
Re-baselining: recompute all three slices together so they still sum to 100%.

Validation checks

The three roadmap slices (offensive + defensive + commitments) must sum to ~100% — a defensive share that makes the sum drift off 100% means items are unclassified or counted in two slices.
A defensive share stuck near zero while product.quality_churn_pct or product.scalability_headroom degrades for 2+ quarters is a re-prioritization flag.
Do not reconcile against product.capacity_allocation_pct — different denominator (work-type vs roadmap-intent).

Common miscomputations

Under-counting defensive work because it is less visible / demo-able — until a reliability event forces a reactive surge.
Conflating the roadmap-intent defensive share with the maintenance / tech-debt share of the capacity-allocation partition.
Leaving backlog unclassified so the slices do not sum to 100%.

product.offensive_roadmap_pct
product.innovation_capacity_pct
product.quality_churn_pct
product.scalability_headroom
product.key_initiatives_status

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.