
Discover Stakeholder Summary
- 494 installs
- 518 repo stars
- Updated August 4, 2026
- product-on-purpose/pm-skills
discover-stakeholder-summary is a Claude Code PM skill that documents stakeholder needs, concerns, and influence maps for developers and product managers starting cross-functional initiatives.
About
discover-stakeholder-summary is an Apache-2.0 PM skill (version 2.1.0) from product-on-purpose/pm-skills that produces a stakeholder summary listing sponsors, approvers, contributors, consumers, and affected groups with needs, concerns, and relationships. The workflow walks identification, prioritization, influence mapping, and alignment risks using triple-diamond, lean-startup, and design-thinking framing. Reach for discover-stakeholder-summary when kicking off a project, taking over an existing initiative, or preparing decisions that need cross-functional buy-in. The output is a structured influence map—not a status email; pair it with foundation-stakeholder-update when you need to communicate to stakeholders directly.
- discover-stakeholder-summary
- AI & Agent Building
- AI-coding skill
Discover Stakeholder Summary by the numbers
- 494 all-time installs (skills.sh)
- +30 installs in the week ending Aug 4, 2026 (Skillselion tracking)
- Ranked #1,785 of 16,546 AI & Agent Building skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/product-on-purpose/pm-skills --skill discover-stakeholder-summaryAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 494 |
|---|---|
| repo stars | ★ 518 |
| Last updated | August 4, 2026 |
| Repository | product-on-purpose/pm-skills ↗ |
How do you document stakeholder needs and influence?
Helps with ai & agent building tasks.
Who is it for?
Product managers and tech leads starting or inheriting cross-functional projects who must align sponsors, approvers, and contributors before committing scope.
Skip if: Teams that need to draft or send stakeholder status updates rather than map influence—use foundation-stakeholder-update instead.
When should I use this skill?
User starts a new initiative, takes over a project, or asks to map stakeholders, influence, or organizational alignment
What you get
Stakeholder summary with prioritized actors, needs, concerns, influence relationships, and alignment risks
- Stakeholder summary document
- Influence and alignment risk map
By the numbers
- Ships as PM-Skills version 2.1.0 under Apache-2.0
- References 3 frameworks: triple-diamond, lean-startup, and design-thinking
Files
<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
Stakeholder Summary
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
When NOT to Use
- You need the async update you will SEND to stakeholders -> use
foundation-stakeholder-update; this skill maps them, that one talks to them - You are preparing for one specific high-stakes meeting -> use
foundation-meeting-brief - You need customer research synthesis rather than an influence map -> use
discover-interview-synthesis - You want a persona to design or market against -> use
foundation-persona
Instructions
When asked to create a stakeholder summary, follow these steps:
1. 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.
2. 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.
3. 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.
4. Map Relationships Identify key dependencies, alliances, and potential conflicts between stakeholders. Understanding who influences whom helps you navigate organizational dynamics.
5. 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.
6. Plan Communication For high-priority stakeholders, define communication cadence, preferred channels, and key messages. Good stakeholder management is proactive, not reactive.
7. 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 Format
Use the template in references/TEMPLATE.md to structure the output. A complete summary fills every template section: Overview; Stakeholder Map; Stakeholder Profiles; Detailed Stakeholder Analysis; Key Relationships; Communication Plan; Risk Mitigation; Action Items; and Document History.
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
Examples
See references/EXAMPLE.md for a completed example.
{
"schema": 1,
"skill": "discover-stakeholder-summary",
"runs_per_query": 3,
"trigger_threshold": 0.5,
"queries": [
{
"q": "Create a stakeholder summary for the data-platform migration project",
"expect": "trigger",
"split": "train"
},
{
"q": "I'm taking over this initiative from another PM and don't know who actually has influence; map the people and the politics for me",
"expect": "trigger",
"split": "train",
"notes": "Intent-only ask; taking over a project is a listed use case"
},
{
"q": "Document who cares about the billing rewrite, what each group needs, and where their interests conflict",
"expect": "trigger",
"split": "train"
},
{
"q": "We're hitting resistance from ops mid-project; map stakeholder concerns and influence so I can navigate it",
"expect": "trigger",
"split": "train"
},
{
"q": "Before the big architecture decision I need cross-functional buy-in; lay out every stakeholder, their stake, and their stance",
"expect": "trigger",
"split": "train"
},
{
"q": "The reorg shuffled who owns what; redo the stakeholder map for the personalization program",
"expect": "trigger",
"split": "train"
},
{
"q": "Map the stakeholders for our compliance initiative, including needs, concerns, and influence levels",
"expect": "trigger",
"split": "validation"
},
{
"q": "Three departments touch this launch and they're not aligned; document who they are and what each one needs from us",
"expect": "trigger",
"split": "validation",
"notes": "Intent-only ask, no artifact keyword"
},
{
"q": "New project kickoff next week: who has a stake, who can block us, and what does each of them care about?",
"expect": "trigger",
"split": "validation"
},
{
"q": "Build the influence-and-interest summary for the API deprecation so our comms can be targeted properly",
"expect": "trigger",
"split": "validation"
},
{
"q": "Write this week's status update email to stakeholders on the migration progress",
"expect": "no-trigger",
"split": "train",
"near_miss_of": "foundation-stakeholder-update",
"notes": "The update you SEND to stakeholders, not the map of them, per When NOT to Use"
},
{
"q": "I have a high-stakes steering-committee meeting Thursday; prep my private brief with positions, asks, and likely objections",
"expect": "no-trigger",
"split": "validation",
"near_miss_of": "foundation-meeting-brief",
"notes": "Prep for one specific meeting, per When NOT to Use"
},
{
"q": "Synthesize the ten customer discovery interviews into themes and insights",
"expect": "no-trigger",
"split": "train",
"notes": "Customer research synthesis, not an influence map"
},
{
"q": "Create a persona for our target buyer in healthcare accounts",
"expect": "no-trigger",
"split": "train",
"notes": "Customer persona, not internal stakeholders"
},
{
"q": "Draft the agenda for the cross-team kickoff meeting next Tuesday",
"expect": "no-trigger",
"split": "validation"
},
{
"q": "Write the problem statement for the onboarding drop-off initiative",
"expect": "no-trigger",
"split": "train"
},
{
"q": "Help me fix a flaky Playwright test that fails only in CI",
"expect": "no-trigger",
"split": "train",
"notes": "Unrelated debugging ask"
},
{
"q": "Write a SQL query listing the top 20 accounts by support ticket volume",
"expect": "no-trigger",
"split": "validation",
"notes": "Unrelated technical ask"
},
{
"q": "Find flights to Singapore for the regional stakeholder roadshow",
"expect": "no-trigger",
"split": "train",
"notes": "Contains 'stakeholder' but is a travel-booking ask"
},
{
"q": "Run a retrospective on how stakeholder communication went last quarter",
"expect": "no-trigger",
"split": "validation"
}
]
}
discover-stakeholder-summary - Version History
| Version | Date | Release | Effort | Type | Summary |
|---|---|---|---|---|---|
| 2.1.0 | 2026-06-10 | v2.26.0 | F-12-batch-3 | minor | Quality convergence: When NOT to Use + output-contract enumeration (F-12 Batch 3) |
| 2.0.0 | 2026-01-26 | - | - | baseline | Prior published version |
2.1.0 (2026-06-10)
Quality-convergence minor (F-12 Batch 3): added a "When NOT to Use" section with boundary pointers to neighboring skills, and the Output Format now enumerates the template sections a complete artifact fills. No template or example changes.
2.0.0 (2026-01-26)
Baseline row for the prior published version; see git history for its changes.
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.
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
<!-- Visual representation of influence vs. interest -->
[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
<!-- Map important dependencies and dynamics -->
Dependencies
| From | To | Dependency Type |
|---|---|---|
| [Stakeholder] | [Stakeholder] | [Approval/Resources/Information] |
| [Stakeholder] | [Stakeholder] | [Approval/Resources/Information] |
Alliances
<!-- Stakeholders who tend to align with each other -->
- [Group description]: [Names]
- [Group description]: [Names]
Potential Conflicts
<!-- Stakeholders with competing interests -->
| 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.
Related skills
How it compares
Choose discover-stakeholder-summary for influence mapping at kickoff; use foundation-stakeholder-update when the deliverable is an async update sent to stakeholders.
FAQ
When should discover-stakeholder-summary run?
discover-stakeholder-summary fits project kickoff, PM handoffs, pre-decision alignment, and org-change moments. The skill maps who has interest or influence, their needs, and relationship risks before execution—not when drafting emails to stakeholders.
What does discover-stakeholder-summary deliver?
discover-stakeholder-summary outputs a stakeholder summary listing individuals and groups with needs, concerns, influence levels, and relationships. The document supports communication planning and buy-in—not customer interview synthesis or persona design.