Key Initiatives Status
Definition
Stoplight-plus-narrative status of the strategic product initiatives committed for the current quarter / half — each initiative ideally tagged on-track / at-risk / blocked / shipped, with a one-line explanation. The execution-pulse view that connects strategy intent to delivery reality. Common pitfall: every initiative defaults to "on track" until two weeks before the deadline, then turns red — a board that only sees binary green-or-red status without intermediate "at-risk" signaling is being managed reactively. Pair with `delivery_predictability` to detect this pattern; require at-risk initiatives to surface a mitigation plan, not just a label.
Why it matters
Connects the strategic narrative to delivery reality at the level the board can act on. Surfaces where engineering needs unblocking, where commitments are slipping, and where the strategy needs revision. The board's most efficient leverage point on the product organization.
How it's calculated
Narrative — list of named strategic initiatives, each with (1) status (on-track / at-risk / blocked / shipped / cut), (2) one-line explanation, (3) for at-risk and blocked: a mitigation plan or escalation request. How to interpret it
Watch for two patterns: (1) chronic "at-risk" without escalation — usually a sign that the team has accepted the slippage and the board is being notified, not asked for help. (2) all-green status alongside declining `delivery_predictability` — usually a sign that the status field is being optimistically managed. The right cadence: at-risk should appear early and resolve via mitigation, not by re-labeling at the deadline.
Source
imboard Editorial
Stage relevance
Typically owned by
Related KPIs
Percentage of committed deliverables shipped on or before the originally-promised date within a measurement window (typically a quarter). Surfaces whether the engineering organization can be trusted to hit commitments the company makes externally — to customers in contracts, to the board in quarterly plans, to GTM teams sequencing launches. Common pitfall: gaming. Teams over-deliver by under-promising (predictability climbs while velocity drops) or move the goalposts (re-baseline mid-quarter so "on-time" stays high). Boards should ask for "predictability against original commitment", not "against current plan", and pair with throughput trends.
Narrative overview of the product portfolio — which products are growth engines, which are cash cows, which are innovation bets, and which are candidates for sunset. The CEO/CPO articulation of "what game each product line is playing." Frequently structured along the McKinsey Three Horizons framing or the classic BCG growth-share matrix (stars / cash cows / question marks / dogs — per Bruce Henderson's "The Product Portfolio", 1970). Common pitfall: the portfolio narrative does not name horizons, life-cycle stages, or sunset candidates — a portfolio described entirely as "growth engines" is not a portfolio strategy, it is a wishlist. Boards should push for explicit classification of every material product.
Percentage of the planned roadmap (typically next 1–2 quarters) allocated to offensive bets — net-new capabilities, market expansion, differentiation moats, new monetization. The "what proportion of the plan is about winning" view. Common pitfall: counting "improvements to existing features" as offensive when the change is really table-stakes parity work. Boards should expect a McKinsey-style horizon framing (Horizon 1 = core, Horizon 2 = adjacent, Horizon 3 = transformational) or an equivalent classification, and apply it consistently. Per the original McKinsey "Three Horizons" framing (Baghai/Coley/White, "The Alchemy of Growth", 1999), a healthy portfolio funds all three — over-indexing on any one is a strategic risk.
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.
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.
Track these KPIs with your board
I'mBoard helps startup CEOs report the metrics that matter, track resolutions, and run better board meetings.