discover-stakeholder-summary

$npx mdskill add product-on-purpose/pm-skills/discover-stakeholder-summary

Maps stakeholder landscape and their influence for project kickoff

  • Identifies key stakeholders and groups with interest in a project.
  • Deploys tools like project management software to gather stakeholder information.
  • Analyzes stakeholder data using frameworks such as triple diamond, lean startup, and design thinking.
  • Generates a summary document for communication and engagement strategies.

SKILL.md

.github/skills/discover-stakeholder-summaryView on GitHub ↗
---
name: discover-stakeholder-summary
description: Maps the people and groups with a stake in a project, documenting their needs, concerns, influence, and engagement approach. Use at project kickoff, when taking over from another PM, or when resistance signals misalignment. For the update you send to those stakeholders, use foundation-stakeholder-update instead; this skill maps them, that one talks to them.
license: Apache-2.0
metadata:
  phase: discover
  version: "2.2.0"
  updated: 2026-07-04
  category: research
  frameworks: [triple-diamond, lean-startup, design-thinking]
  author: product-on-purpose
---
<!-- 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.

More from product-on-purpose/pm-skills

SkillDescription
define-hypothesisDefines a testable hypothesis with clear success metrics and a validation approach. Use when forming assumptions to test or aligning a team on what success looks like, before any experiment is designed. To design the A/B test or experiment that will validate the hypothesis, use measure-experiment-design.
define-jtbd-canvasCreates a Jobs to be Done canvas capturing the functional, emotional, and social dimensions of a customer job. Use when deeply understanding customer motivations, designing for jobs, or reframing product positioning.
define-opportunity-treeCreates an opportunity solution tree connecting a desired outcome to customer opportunities and candidate solutions, preventing solution-first jumps in continuous discovery. Use when structuring scattered feature ideas or communicating how the roadmap traces to outcomes. For ranking an existing flat list of candidates, use define-prioritization-framework instead; this skill discovers the list, it does not score one.
define-prioritization-frameworkRun applicable prioritization frameworks (RICE, ICE, MoSCoW, Weighted Scoring, Kano) against a list of features or initiatives. Produces a comparison table showing where rankings agree and diverge across frameworks, and an executive summary with recommendation. Framework applicability is filtered by data availability; Kano requires customer research. Refuses to fabricate scores; produces an estimation scaffold when input data is missing.
define-problem-statementCreates a clear problem framing document with user impact, business context, and success criteria. Use when starting a new initiative, realigning a drifted project, or communicating up to leadership.
define-xFixture skill for phase-map and phase-router tests.
deliver-acceptance-criteriaGenerates structured Given/When/Then acceptance criteria for a user story or feature slice, covering the happy path, key failure scenarios, and non-functional expectations in testable form. Use when turning requirements into verifiable scenarios for engineering handoff and QA sign-off. For a dedicated catalog of boundary conditions, error states, and recovery paths across a feature, use deliver-edge-cases; to write the stories themselves, use deliver-user-stories.
deliver-edge-casesDocuments edge cases, error states, boundary conditions, race conditions, and recovery paths for a feature - the systematic catalog of what can go wrong and the failure modes to design for. Use during specification to map the failure surface and ensure comprehensive coverage, or during QA planning to identify boundary and limit scenarios to test. Distinct from deliver-acceptance-criteria, which writes story-level Given/When/Then checks; this skill produces the whole-feature edge-case catalog.
deliver-launch-checklistCreates a cross-functional pre-launch checklist covering engineering, design, marketing, support, legal, and operations readiness, with owners, dates, and go/no-go criteria so nothing is missed before release. Use for significant or cross-team launches, not a small single-team change. For the customer-facing announcement of what shipped, use deliver-release-notes instead.
deliver-prdCreates a comprehensive Product Requirements Document that aligns stakeholders on what to build, why, and how success will be measured. Use when specifying features, epics, or product initiatives for engineering handoff.