Skill: Stakeholder Communication Matrix

Purpose

Adapt analytical findings to the audience — same insight, different framing, detail level, and format depending on who will read it. Ensures that executives get the bottom line, PMs get the implications, engineers get the specifics, and data teams get the methodology.

When to Use

Apply this skill when producing a narrative (Storytelling agent), creating a deck (Deck Creator agent), or whenever the user specifies an audience. If no audience is specified, default to Product Team format.

Instructions

The Stakeholder Matrix

Different audiences care about different things. For the same finding, adapt:

How to Adapt

Step 1: Identify the Audience

If the user specifies an audience, use that. If not, ask or default to Product Team.

Common signals:

• •"Prepare this for the leadership team" → Executive
• •"What should we do about this?" → Product Team
• •"Can you dig into the root cause?" → Engineering
• •"How confident are we in this finding?" → Data Team

Step 2: Select the Lead

Every communication starts with the most important thing for that audience:

EXECUTIVE:    "This is costing us $X per month."
PRODUCT:      "Mobile checkout conversion dropped 15% — here's what to prioritize."
ENGINEERING:  "iOS app v2.3.0 has a payment processing regression in the checkout flow."
DATA:         "We isolated the root cause through 5 rounds of segment decomposition, controlling for seasonality."

Same finding. Different first sentence.

Step 3: Calibrate Detail

Use the pyramid principle — start with the conclusion, add detail as the audience requires:

Level 1 (Executive):     Conclusion + impact + recommendation
Level 2 (Product):       + key findings + implications + next steps
Level 3 (Engineering):   + root cause details + affected systems + fix scope
Level 4 (Data):          + methodology + validation + caveats + alternative explanations

Each level includes everything above it plus more depth.

Step 4: Adapt the Recommendation

Multi-Audience Documents

When a document serves multiple audiences (common for analysis reports):

1. •Start with Executive Summary — 3-5 sentences, bottom line first
2. •Key Findings for Product — what happened, why, what to do
3. •Technical Details for Engineering — root cause, affected systems, fix scope
4. •Methodology for Data — how the analysis was done, validation, caveats

Label sections clearly so readers can jump to their level.

Output Format

When applying this skill, note the audience adaptation at the top of the deliverable:

**Audience:** [Executive / Product / Engineering / Data / Multi-audience]
**Adapted for:** [Name or role, if known]
**Detail level:** [Level 1-4]

Examples

Example: Same Finding, Four Audiences

Finding: Support ticket volume spiked 55% in June due to an iOS payment bug in app v2.3.0, causing 356 excess tickets and ~$5,340 in support costs.

Executive version:

Support costs increased $5,340/month due to an iOS app bug. Engineering has identified the fix. Recommend deploying the hotfix this sprint — expected to eliminate the excess ticket volume entirely.

Product version:

iOS payment failures spiked in June after the v2.3.0 release, driving a 55% increase in support tickets. The bug affects checkout on iOS devices, causing payment processing errors that generate support contacts. Recommend prioritizing the hotfix (v2.3.1) over planned feature work this sprint. After the fix, monitor ticket volume for 2 weeks to confirm recovery.

Engineering version:

The payment tokenization change in v2.3.0 (commit abc123, deployed Jun 1) introduced a regression in PaymentProcessor.swift that causes intermittent failures on iOS 16+ when using Apple Pay. The failure manifests as a timeout in the token exchange, which the client interprets as a generic error. 356 excess support tickets were generated between Jun 1-14. The fix is to revert the tokenization change and use the v2.2.x payment path until the token exchange timeout is resolved. Estimated effort: 2 story points.

Data version:

We isolated the root cause through 5 rounds of iterative decomposition: total tickets → monthly anomaly (June) → category isolation (payment issues, 72% of excess) → device isolation (iOS, 89% of payment excess) → version isolation (v2.3.0, 95% of iOS excess). The finding is robust: segment-first checks showed no Simpson's Paradox, the anomaly period aligns precisely with the v2.3.0 release window (Jun 1-14), and the v2.4.0 hotfix on Jun 15 shows immediate recovery. Confidence: HIGH. Caveat: ticket categorization relies on agent tagging, which has ~8% misclassification rate for payment issues.

Anti-Patterns

1. •Never give an executive a methodology-first report — they need the bottom line, not how you got there
2. •Never give an engineer a business-impact-only summary — they need the specifics to act on it
3. •Never skip the recommendation — every audience needs to know what to do next, even if the framing differs
4. •Never assume one format fits all — if you're presenting to a mixed group, use the multi-audience structure with labeled sections
5. •Never hide caveats from the data team — they will find them and lose trust in the analysis
6. •Never overload executives with caveats — mention only caveats that would change the recommendation