Stakeholder Summary

Quick facts

Phase: Discover | Version: 2.0.0 | Category: research | License: Apache-2.0

Try it: /stakeholder-summary "Your context here"

A stakeholder summary documents the people and groups who have interest in or influence over a project, capturing their needs, concerns, and relationships. Effective stakeholder management often determines project success more than technical execution, making this document essential for navigating organizational complexity.

When to Use

At the start of a new project or initiative to map the landscape
When taking over an existing project from another PM
Before major decision points that require cross-functional buy-in
When experiencing resistance or misalignment mid-project
During organizational changes that shift stakeholder dynamics
When preparing communication strategies for launches or changes

How to Use

Use the /stakeholder-summary slash command:

/stakeholder-summary "Your context here"

Or reference the skill file directly: skills/discover-stakeholder-summary/SKILL.md

Instructions

When asked to create a stakeholder summary, follow these steps:

Identify All Stakeholders List everyone with a stake in the project: sponsors, approvers, contributors, consumers of the output, and those affected by changes. Cast a wide net initially.you can prioritize later. Include both individuals and groups.
Assess Influence and Interest For each stakeholder, evaluate their influence (power to affect the project) and interest (how much they care about outcomes). This determines how much attention each requires.
Understand Their Perspective Document what each stakeholder needs from the project, what concerns or risks they perceive, and what a successful outcome looks like to them. When possible, validate these directly through conversation.
Map Relationships Identify key dependencies, alliances, and potential conflicts between stakeholders. Understanding who influences whom helps you navigate organizational dynamics.
Categorize by Engagement Level Based on influence and interest, determine the appropriate engagement approach: actively manage, keep satisfied, keep informed, or monitor. Different stakeholders need different levels of attention.
Plan Communication For high-priority stakeholders, define communication cadence, preferred channels, and key messages. Good stakeholder management is proactive, not reactive.
Identify Risks and Mitigations Note where stakeholder concerns could derail the project and plan how to address them. Early attention to resistant stakeholders prevents surprises.

Output Template

Stakeholder Summary: [Project/Initiative Name]

Overview

Project: [Project or initiative name] Purpose: [One-line description of what this stakeholder analysis supports] Date: [When analysis was conducted] Owner: [Who maintains this document]

Stakeholder Map

                    [High Interest]
                          |
        KEEP SATISFIED    |    MANAGE CLOSELY
                          |
                          |
[Low Influence] ----------+---------- [High Influence]
                          |
                          |
        MONITOR           |    KEEP INFORMED
                          |
                    [Low Interest]

Quadrant Placement

Manage Closely (High Influence, High Interest):

[Stakeholder name]
[Stakeholder name]

Keep Satisfied (High Influence, Low Interest):

[Stakeholder name]
[Stakeholder name]

Keep Informed (Low Influence, High Interest):

[Stakeholder name]
[Stakeholder name]

Monitor (Low Influence, Low Interest):

[Stakeholder name]
[Stakeholder name]

Stakeholder Profiles

Stakeholder	Role	Influence	Interest	Alignment	Key Need
[Name]	[Title/Function]	High/Med/Low	High/Med/Low	Supportive/Neutral/Resistant	[Primary need]
[Name]	[Title/Function]	High/Med/Low	High/Med/Low	Supportive/Neutral/Resistant	[Primary need]
[Name]	[Title/Function]	High/Med/Low	High/Med/Low	Supportive/Neutral/Resistant	[Primary need]
[Name]	[Title/Function]	High/Med/Low	High/Med/Low	Supportive/Neutral/Resistant	[Primary need]
[Name]	[Title/Function]	High/Med/Low	High/Med/Low	Supportive/Neutral/Resistant	[Primary need]

Detailed Stakeholder Analysis

[Stakeholder Name 1]

Role: [Title and function] Influence Level: [High/Medium/Low] . [Why] Interest Level: [High/Medium/Low] . [Why] Current Alignment: [Supportive/Neutral/Resistant]

Needs:

[What they need from this project]
[What success looks like to them]

Concerns:

[What worries them about this project]
[What risks they perceive]

What Motivates Them:

[Underlying drivers and priorities]

Preferred Communication:

Channel: [Email/Slack/meetings/etc.]
Frequency: [Daily/weekly/milestone-based]
Style: [Data-driven/narrative/executive summary]

[Stakeholder Name 2]

Role: [Title and function] Influence Level: [High/Medium/Low] . [Why] Interest Level: [High/Medium/Low] . [Why] Current Alignment: [Supportive/Neutral/Resistant]

Needs:

[What they need from this project]
[What success looks like to them]

Concerns:

[What worries them about this project]
[What risks they perceive]

What Motivates Them:

[Underlying drivers and priorities]

Preferred Communication:

Channel: [Email/Slack/meetings/etc.]
Frequency: [Daily/weekly/milestone-based]
Style: [Data-driven/narrative/executive summary]

[Stakeholder Name 3]

Role: [Title and function] Influence Level: [High/Medium/Low] . [Why] Interest Level: [High/Medium/Low] . [Why] Current Alignment: [Supportive/Neutral/Resistant]

Needs:

[What they need from this project]
[What success looks like to them]

Concerns:

[What worries them about this project]
[What risks they perceive]

What Motivates Them:

[Underlying drivers and priorities]

Preferred Communication:

Channel: [Email/Slack/meetings/etc.]
Frequency: [Daily/weekly/milestone-based]
Style: [Data-driven/narrative/executive summary]

Key Relationships

Dependencies

From	To	Dependency Type
[Stakeholder]	[Stakeholder]	[Approval/Resources/Information]
[Stakeholder]	[Stakeholder]	[Approval/Resources/Information]

Alliances

Potential Conflicts

Parties	Conflict Area	Risk Level
[Names]	[Issue]	High/Med/Low
[Names]	[Issue]	High/Med/Low

Communication Plan

Stakeholder	Frequency	Channel	Content	Owner
[Name]	[Weekly/bi-weekly/monthly]	[Meeting/email/Slack]	[What to communicate]	[Who sends]
[Name]	[Weekly/bi-weekly/monthly]	[Meeting/email/Slack]	[What to communicate]	[Who sends]
[Name]	[Weekly/bi-weekly/monthly]	[Meeting/email/Slack]	[What to communicate]	[Who sends]

Risk Mitigation

Resistant Stakeholders

Stakeholder	Concern	Mitigation Strategy	Owner
[Name]	[Core concern]	[How to address]	[Who owns]
[Name]	[Core concern]	[How to address]	[Who owns]

Political Risks

Risk	Impact	Mitigation
[Risk description]	[What could happen]	[Prevention strategy]
[Risk description]	[What could happen]	[Prevention strategy]

Action Items

[Action to improve stakeholder relationship]
[Meeting to schedule]
[Communication to send]
[Concern to address]

Document History

Date	Change	Author
[Date]	Initial creation	[Name]
[Date]	[Update description]	[Name]

Review and update this document when stakeholder dynamics change or at major project milestones.

Example Output

Stakeholder Summary: Cloud Infrastructure Migration

Overview

Project: Migrate core business applications from on-premise data center to AWS Purpose: Identify and manage stakeholders to ensure smooth migration with organizational buy-in Date: January 2026 Owner: Sarah Chen, Technical Program Manager

Stakeholder Map

                    [High Interest]
                          |
        KEEP SATISFIED    |    MANAGE CLOSELY
         - CFO            |     - CTO (Marcus)
         - Legal          |     - VP Engineering (Diana)
                          |     - IT Director (James)
                          |     - Security Lead (Priya)
[Low Influence] ----------+---------- [High Influence]
                          |
        MONITOR           |    KEEP INFORMED
         - HR             |     - Engineering Leads
         - Marketing      |     - Customer Success
                          |     - Sales
                    [Low Interest]

Quadrant Placement

Manage Closely (High Influence, High Interest):

Marcus Wong, CTO . Executive sponsor, budget authority
Diana Reyes, VP Engineering . Technical decision maker, team impact
James Liu, IT Director . Infrastructure owner, operations impact
Priya Sharma, Security Lead . Compliance gatekeeper

Keep Satisfied (High Influence, Low Interest):

Michael Torres, CFO . Budget approval, cost concerns
Jennifer Adams, Legal Counsel . Contract and compliance review

Keep Informed (Low Influence, High Interest):

Engineering Team Leads . Affected by changes, need to plan
Customer Success Team . Potential customer-facing impact
Sales Team . Need confidence to reassure customers

Monitor (Low Influence, Low Interest):

HR Department . Minor process updates needed
Marketing Team . Minimal direct impact

Stakeholder Profiles

Stakeholder	Role	Influence	Interest	Alignment	Key Need
Marcus Wong	CTO	High	High	Supportive	Successful migration, modernization
Diana Reyes	VP Engineering	High	High	Supportive	Minimal team disruption, improved DX
James Liu	IT Director	High	High	Neutral	Clear transition plan, job security
Priya Sharma	Security Lead	High	High	Resistant	Zero security incidents, compliance
Michael Torres	CFO	High	Medium	Neutral	Cost predictability, ROI clarity
Jennifer Adams	Legal Counsel	Medium	Low	Neutral	Contract compliance, vendor terms

Detailed Stakeholder Analysis

Marcus Wong, CTO

Role: Chief Technology Officer, Executive Sponsor Influence Level: High . Budget authority, final technical decisions Interest Level: High . Strategic initiative tied to his objectives Current Alignment: Supportive

Needs:

Successful migration that positions company for scale
Clear progress visibility without micromanaging
Minimal production incidents during transition

Concerns:

Timeline slippage affecting other initiatives
Hidden costs emerging mid-project
Team burnout from concurrent projects

What Motivates Them:

Technology leadership reputation in industry
Enabling business growth through infrastructure
Building a modern, attractive engineering organization

Preferred Communication:

Channel: Weekly 1:1, Slack for urgent items
Frequency: Weekly status, immediate escalation for blockers
Style: Executive summary with key decisions needed

Diana Reyes, VP Engineering

Role: VP Engineering, 60 engineers across 8 teams Influence Level: High . Controls engineering resources and priorities Interest Level: High . Her teams are directly affected Current Alignment: Supportive

Needs:

Minimal disruption to sprint commitments
Clear ownership boundaries during transition
Improved developer experience post-migration

Concerns:

Engineers pulled from product work for migration tasks
On-call burden increasing during transition
Knowledge gaps on new cloud infrastructure

What Motivates Them:

Team morale and retention
Engineering velocity and productivity
Technical excellence and best practices

Preferred Communication:

Channel: Engineering leads meeting, Slack channel
Frequency: Bi-weekly detailed review, weekly async update
Style: Technical depth with impact on team metrics

James Liu, IT Director

Role: IT Director, manages infrastructure and operations team of 12 Influence Level: High . Owns current infrastructure, critical for transition Interest Level: High . Directly affects his team’s role and processes Current Alignment: Neutral (previously resistant)

Needs:

Clear role for his team post-migration
Training on AWS operations
Recognition of his team’s institutional knowledge

Concerns:

Job security for himself and team members
Being blamed if migration causes outages
Loss of control and expertise relevance

What Motivates Them:

Team stability and career growth paths
Operational excellence and uptime metrics
Being seen as enabler, not blocker

Preferred Communication:

Channel: Direct 1:1 meetings, private Slack
Frequency: Weekly check-in, daily during critical phases
Style: Collaborative, acknowledging his expertise

Priya Sharma, Security Lead

Role: Head of Information Security, compliance owner Influence Level: High . Can block migration with security concerns Interest Level: High . Major changes to security perimeter Current Alignment: Resistant

Needs:

Zero security incidents during and after migration
Compliance documentation for auditors
Security controls equal or better than current state

Concerns:

Expanded attack surface with cloud exposure
Team lacks cloud security expertise
Rushed timeline compromising security reviews

What Motivates Them:

Zero breach track record
Regulatory compliance (SOC 2, GDPR)
Security team recognition and resources

Preferred Communication:

Channel: Security review meetings, documented decisions
Frequency: Bi-weekly security review, ad-hoc for findings
Style: Risk-focused, evidence-based, documented

Michael Torres, CFO

Role: Chief Financial Officer, budget authority Influence Level: High . Controls funding approval Interest Level: Medium . Cares about cost, not technical details Current Alignment: Neutral

Needs:

Predictable costs with clear ROI
No budget surprises or overruns
Business continuity during transition

Concerns:

Cloud costs spiraling out of control
Hidden costs not in original estimate
Productivity loss during migration

What Motivates Them:

Financial predictability and control
Operational efficiency
Risk management

Preferred Communication:

Channel: Monthly finance review, email for budget items
Frequency: Monthly, plus any budget change requests
Style: Numbers-focused, ROI-driven, concise

Key Relationships

Dependencies

From	To	Dependency Type
Project Team	Marcus Wong	Budget approval, executive air cover
Project Team	Priya Sharma	Security sign-off for each phase
James Liu	Diana Reyes	Knowledge transfer on current systems
Diana Reyes	Engineering Leads	Resource allocation for migration work

Alliances

Executive alignment: Marcus and Michael are aligned on cloud strategy; Marcus can influence Michael on budget concerns
Technical block: Diana and James share operational concerns; addressing James’s concerns helps with Diana
Security partnership: Priya has CFO’s ear on risk; getting her support removes a major blocker

Potential Conflicts

Parties	Conflict Area	Risk Level
James Liu vs. Diana Reyes	Ownership of cloud operations post-migration	Medium
Priya Sharma vs. Project Team	Security review timeline vs. project schedule	High
Engineering Leads vs. Project Team	Resource allocation between product and migration	Medium

Communication Plan

Stakeholder	Frequency	Channel	Content	Owner
Marcus Wong	Weekly	1:1 meeting	Status, risks, decisions needed	Sarah (PM)
Diana Reyes	Bi-weekly	Eng leads sync	Team impact, timeline, asks	Sarah (PM)
James Liu	Weekly	Private 1:1	Transition planning, concerns	Sarah (PM)
Priya Sharma	Bi-weekly	Security review	Security status, findings, mitigations	Sarah + Tech Lead
Michael Torres	Monthly	Finance review	Budget status, forecast, variances	Sarah + Marcus
Engineering Leads	Bi-weekly	Slack + meeting	Technical updates, timeline	Tech Lead
Broader org	Monthly	All-hands update	High-level progress, what’s changing	Marcus

Risk Mitigation

Resistant Stakeholders

Stakeholder	Concern	Mitigation Strategy	Owner
Priya Sharma	Security controls inadequate	Engage her team early in architecture; hire cloud security consultant; extra review time	Sarah + CTO
James Liu	Team relevance post-migration	Create explicit “Cloud Operations” role; AWS training budget; acknowledge expertise	Sarah + Diana

Political Risks

Risk	Impact	Mitigation
James blocks knowledge transfer	Migration delayed, critical gaps	Private relationship building; involve in architecture decisions; protect his team
Priya escalates to board	Project paused for extended security review	Proactive security partnership; over-communicate; no surprises
CFO cuts budget mid-project	Scope reduced, value compromised	Regular cost updates; contingency in budget; ROI documentation

Action Items

Schedule private lunch with James Liu to discuss team transition plan (Sarah, this week)
Invite Priya to architecture review as co-owner, not reviewer (Tech Lead, next sprint)
Prepare “IT Team Cloud Evolution” proposal for Diana’s approval (Sarah, next week)
Create CFO dashboard showing migration costs vs. budget (Sarah, before next finance review)
Draft security partnership proposal for Priya with dedicated review slots (Sarah + Tech Lead)

Document History

Date	Change	Author
2026-01-14	Initial creation	Sarah Chen
2026-01-14	Added communication plan	Sarah Chen

Review and update this document when stakeholder dynamics change or at major project milestones.

Real-World Examples

See this skill applied to three different product contexts:

Storevine (B2B): Storevine B2B ecommerce platform . Campaigns launch stakeholder map

Prompt:

/stakeholder-summary

Project: Campaigns . native email marketing for Storevine merchants
Stage: PRD complete, moving to engineering kickoff

Stakeholders I've identified:

Internal:
- Growth PM (me) . owner
- Eng Lead (Platform) . aligned, participated in PRD review
- Design . in progress on Figma specs
- Legal . needs to review CAN-SPAM + GDPR section; not started yet
- Merchant Success . launch comms owners; engaged in discovery
- Storevine Marketing . dog-food use case; interested in using
  Campaigns for our own merchant communications

External:
- Power-user merchants (fashion/home segment) . 5-6 who joined
  discovery interviews; have expectations about the feature
- Klaviyo integration partner team . active Storevine integration;
  not sure how they'll react to a native competing feature

Need: influence/interest map, stakeholder profiles, communication
plan, and risk mitigation for Klaviyo and resistant stakeholders.

Output:

Stakeholder Summary: Campaigns . Native Email Marketing

Brainshelf (Consumer): Brainshelf consumer PKM app . internal stakeholder map for the Resurface feature

Prompt:

/stakeholder-summary

need to map the internal stakeholders for the resurface feature before
we kick off the build. brainshelf is a ~20 person startup so this is
small-team politics, not enterprise governance.

key people:
- marco (ceo/cofounder) . big advocate, sees this as the retention bet
- alex (eng lead) . supportive but worried about A/B test infrastructure
- jordan (growth) . wants resurface as the retention lever
- dan (designer) . concerned about the digest feeling spammy
- chloe (data) . needs instrumentation for the experiment

want a proper stakeholder map with communication plan.

Output:

Stakeholder Summary: Resurface Feature

Workbench (Enterprise): "Workbench enterprise collaboration platform: Blueprints launch stakeholder map"

Prompt:

/stakeholder-summary

Project: Workbench Blueprints -- reusable document templates with required sections and role-based approval gates
Product: Workbench (enterprise collaboration platform, Series B, ~200 employees, ~500 enterprise customers [fictional])
Stage: Pre-development. Discovery interviews complete. About to enter Define phase.
PM: Rachel V. (Technical PM, Blueprints)

Stakeholders to map:

Internal:
1. Sandra C. -- Head of Product. Blueprints sponsor. Approves scope and timeline. Wants Blueprints to drive enterprise expansion and reduce churn in the compliance segment.
2. James W. -- VP Engineering. Owns engineering allocation. Concerned about CRDT complexity and timeline risk. Supportive but cautious.
3. Karen L. -- Engineering Lead, Blueprints squad. Day-to-day engineering owner. Excited about the technical challenge. Needs clear requirements early.
4. Derek H. -- Head of Marketing. Owns GA positioning and messaging. Needs competitive differentiation story for enterprise sales enablement.
5. Mei-Lin T. -- Enterprise Sales Lead. Manages the top 50 enterprise accounts. Wants Blueprints to close pipeline deals stalled on governance gaps. Resistant to phased rollout -- wants everything at once.

External:
6. IT Security leads at enterprise customer accounts. Gate SSO and data residency requirements. Will block deployment if security posture is insufficient.
7. Confluence-migrant accounts (estimated 15 of 80 closed-beta customers [fictional]). High-value, high-risk -- switching cost makes them sticky if onboarding goes well, churnable if it doesn't.

Format: Full stakeholder summary with influence/interest map, detailed profiles, communication plan, and risk mitigation.

Output:

Stakeholder Summary: Workbench Blueprints

Quality Checklist

Before finalizing, verify:

All significant stakeholders are identified (not just obvious ones)
Influence and interest assessments are realistic, not wishful
Concerns are documented from stakeholder’s perspective, not dismissed
Relationships and dependencies are mapped
Communication plan is specific and actionable
Resistant stakeholders have mitigation strategies

Output Format

Use the template in references/TEMPLATE.md to structure the output.