Key Initiatives
Definition
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.
Why it matters
Connects the strategic narrative to delivery reality at the level the board can act on — surfaces where engineering needs unblocking and where commitments are slipping, per named initiative with a named owner. The board's most efficient leverage point on the product organization.
How it's calculated
Container — field-array of initiative items (name, status, owner, targetDate, explanation / mitigation). No aggregate calculation; the surface makes each strategic initiative individually trackable at the board level. How to interpret it
Watch for chronic "at-risk" items without escalation (the team has accepted slippage and is notifying, not asking for help) and for all-green status alongside a declining `product.delivery_predictability` (status is being optimistically managed). Pair with the `product.key_initiatives_status` narrative — the gallery tracks the items, the narrative explains the pattern.
Source
imboard Editorial
Stage relevance
Typically owned by
Related KPIs
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.
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.
Container handle for the field-array of products in the portfolio — each entry tracks the product name, its portfolio classification (e.g. growth engine / cash cow / innovation bet / sunset candidate, or Horizon 1/2/3), ARR contribution, investment thesis, and lifecycle stage. The structured, per-product companion to the `product.portfolio_strategy` narrative: the narrative tells the story, this gallery makes each product line individually visible and trackable. Renders via the CollapsibleFormItemCardGallery widget (the reused gallery pattern shared with sales pipeline deals and HR key hires / openings). Common pitfall: a portfolio gallery that lists products without an explicit classification or investment thesis per item — that is an inventory, not a portfolio.
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.
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.