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

Pre-flight: Load Learnings

Before executing, check .knowledge/learnings/index.md for relevant communication preferences:

1. Try to read the file: Use the Read tool on .knowledge/learnings/index.md
2. If it exists, scan for entries under these headings:
   • "Communication" - stakeholder preferences, formatting conventions
   • "General" - cross-cutting preferences that apply to all work
   • "Stakeholder Preferences" - audience-specific guidance
3. If it doesn't exist or is empty, skip silently and proceed with standard stakeholder matrix
4. If entries exist, incorporate them as constraints (e.g., "VP prefers 1-page summaries", "always include confidence grades for data team")
5. Never block execution if learnings are unavailable - this is an enhancement, not a blocker

Example learnings that would apply:

• "Executive team prefers dashboards over text reports"
• "Product team wants effort estimates in days, not story points"
• "Data team requires p-values for all statistical claims"

The Stakeholder Matrix

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

Dimension	Executive	Product Team	Engineering	Data Team
Lead with	Business impact ($, users, risk)	What to do about it (action)	What's broken and where (specifics)	How we found it (methodology)
Detail level	Bottom line + 1 supporting fact	Findings + implications + next steps	Root cause + technical details + fix scope	Methodology + data quality + caveats
Format	3 slides max / 1-paragraph summary	Analysis report with charts	Investigation log with queries/code	Full report with validation section
Metrics language	Revenue, users, growth rate	Conversion, retention, engagement	Error rate, latency, success rate	Statistical significance, confidence intervals
Time horizon	This quarter / this year	This sprint / this month	This release / this deploy	This analysis / this dataset
Charts	1-2 high-level (big number, trend)	3-5 focused (funnel, segmentation)	Technical plots (timelines, error logs)	Distribution, correlation, validation
Caveats	Only if they change the recommendation	Noted alongside findings	Noted with technical implications	Full methodology section
Recommendation style	"We should X" (decisive)	"I recommend X because Y" (reasoned)	"The fix is X, effort is Y" (scoped)	"The data supports X with caveats Y" (qualified)

How to Adapt

Step 1: Identify the Audience

Detect the audience from both explicit mentions and context clues.

Explicit signals (direct audience mentions):

• "Prepare this for the leadership team" / "my VP wants to see this" / "present to the CEO" → Executive
• "present to the product team" / "sprint planning" / "PM review" → Product Team
• "Can you dig into the root cause?" / "engineering needs this" → Engineering
• "data science team wants to understand" / "review before we present" / "peer review" → Data Team

Context clues (implicit signals):

• Urgency + Business outcome → likely Executive
  • "tomorrow morning" / "board meeting Friday" / "urgent update needed"
  • Combined with business language ($, revenue, users, risk)
• Planning context → likely Product Team
  • "sprint planning" / "roadmap discussion" / "prioritization meeting"
  • Questions like "what should we do?" / "how do we prioritize?"
• Technical investigation → likely Engineering
  • "root cause" / "debug" / "fix" / "error logs" / "latency issue"
  • Focus on specific systems, code, or infrastructure
• Methodology questions → likely Data Team
  • "how confident are we?" / "validate this" / "peer review"
  • Requests for methodology, statistical rigor, caveats

If the audience is unclear: for a live presentation or time-boxed request, ask "Who will read this?"; for a document that will be shared widely, use the multi-audience structure; otherwise default to Product Team (most versatile).

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

Audience	Recommendation Style	Example
Executive	Decisive, resource-oriented	"Recommend allocating 2 engineers for 1 sprint to fix the iOS payment bug. Expected recovery: $64K/year."
Product	Reasoned, prioritized	"Recommend prioritizing the iOS payment fix over the checkout redesign. The bug affects 12% of transactions and has a clear fix, while the redesign has uncertain ROI."
Engineering	Specific, scoped	"The regression is in PaymentProcessor.swift introduced in v2.3.0 commit abc123. Hotfix path: revert the payment tokenization change and deploy v2.3.1."
Data	Qualified, methodical	"The data strongly supports a causal link between v2.3.0 and the ticket spike (r²=0.94, controlled for seasonality and mix shift). Recommend confirming with server logs before concluding."

Multi-Audience Documents

Use multi-audience format when:

• The document will be shared widely (emailed to a distribution list with mixed roles, posted to wiki)
• It's a formal analysis report that serves as a reference document
• The user explicitly says "this needs to work for everyone" or mentions multiple audience types
• You're creating an artifact that will be archived/referenced later by different stakeholders

Use single-audience format when:

• The user specifies a single audience ("prepare this for my VP", "write this for engineering")
• It's a live presentation (deck, meeting brief) — pick the primary audience in the room
• Time is constrained ("tomorrow morning") — optimize for one audience, don't try to serve everyone
• The context is meeting-specific ("sprint planning", "board meeting") — tailor to that meeting's attendees

Multi-audience structure (when needed):

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

Label sections clearly so readers can jump to their level. This creates a "pyramid" structure where each level contains everything above it plus more depth.

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]

Template Mode vs Analysis Presentation

Distinguish between drafting a structure and presenting actual findings:

If you're drafting a template or structure (user hasn't done analysis yet):

• Use clearly marked placeholders: [Insert actual value from analysis] or [$X in lost revenue - from analysis]
• Never fabricate numbers or statistics to illustrate the template
• Focus on structure, format, and what goes where
• Example: "Revenue at risk: [$X/month from mobile checkout funnel analysis]"

If you're presenting actual analysis results:

• Use concrete numbers from your analysis or the user's findings
• Cite the data source (table, query, date range) inline
• Show your work (include supporting queries/charts as appendices for technical audiences)
• Example: "Revenue at risk: $47K/month (from orders.checkout_completed, Oct 2024)"

This prevents hallucination while preserving the skill's value for both planning and presenting.

Source Attribution by Audience

For every quantitative claim, cite the source appropriate to the audience:

Audience	Attribution Style	Example
Executive	Brief inline citation	"based on mobile checkout data, Oct 2024"
Product	Table/column reference	"from orders.checkout_completed events"
Engineering	Full query in appendix with explanation	"See Appendix A: checkout_drop_query.sql lines 15-23"
Data	Complete query + validation + data quality notes	"Query validates with row count match (n=15,234), no nulls in key fields, 2% outlier rate within expected bounds"

This builds trust and allows stakeholders to verify claims independently.

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