Stakeholder Identification

Skill Overview

Stakeholder Identification is an AI skill that helps you fully map your stakeholders before engaging with anyone. Through structured brainstorming, three-category classification, R/P/D power markers, and fairness and bias checks, it identifies all stakeholders—including marginalized groups—and pinpoints the 2–3 key individuals or groups that require the deepest understanding first.

Use Cases

1. Launching a new initiative: When the stakeholder landscape has not yet been mapped and influence networks are unclear, quickly identify allies, gatekeepers, and decision-makers, while surfacing hidden blockers who control permission (P) or decision-making authority (D).
2. Planning discovery research: Determine who the research is about, whom to interview, and whom to recruit. Ensure that user research covers high-impact, low-voice groups rather than focusing only on the most active and well-resourced users.
3. Writing the stakeholder section of a PRD: Before writing requirements, produce a complete stakeholder list that has undergone bias checks and includes R/P/D markers. This ensures that the requirements scope, launch plan, and definition of success are built without overlooking key people.

Core Features

1. Three-category classification and R/P/D markers: Classify each stakeholder as an Ally, Audience, or Influencer, and mark whether they control Resources (R), Permission (P), or Decision-making authority (D). This makes it immediately clear who can fund, approve, or veto your project.
2. Fairness perspective and bias checks: Trace ripple effects through primary, secondary, and tertiary impact chains. Proactively include groups that bear the consequences of a product but have little organizational voice, such as frontline customer service staff and small customers without dedicated technical teams. Explicitly record assumptions such as “Who did we nominate by default, who did we overlook, and who did we allow to represent whom?”
3. Disciplined narrowing to priority targets: Follow the principle of “complete the list first, prioritize later.” This avoids quietly cutting off high-impact, low-power voices that have not yet been understood during brainstorming. From the complete list, identify the 2–3 stakeholders who most need to be understood in depth, and specify for each one “what we need to learn from them.” The output can be directly connected to stakeholder mapping and engagement planning.

Frequently Asked Questions

What is the difference between stakeholder identification and stakeholder mapping?

Identification answers “Who is involved?” Mapping answers “Who matters most?” This skill produces a complete stakeholder list that has undergone fairness checks; stakeholder mapping then ranks that list using frameworks such as a power–interest grid. Combining the two steps makes teams likely to eliminate high-impact, low-power groups before they are fully understood during brainstorming. The correct order is to identify first, then rank.

Why is a list based on memory insufficient, and how can it be completed?

Initial brainstorming typically covers only about 60% of stakeholders and systematically misses the less visible 40%. To complete the list, apply a fairness perspective: trace the primary, secondary, and tertiary impact chains layer by layer—for example, changes to customer service workflows → changes in customer service experiences → changes in reputation and churn. Continue asking, “Who bears the consequences but has no power to participate in the design?” and “Whom did we assume could represent whom?” Explicitly add marginalized user groups, frontline employees, and compliance and security gatekeepers back to the list.

Is this skill reliable when used by one person?

Yes. The skill supports an individual practice mode that takes approximately 20–30 minutes. However, an individual stakeholder list reflects that person’s network and assumptions. After completing the bias and assumption checks, it is recommended that you ask a cross-functional colleague to validate the list before proceeding. Also keep two points in mind: the list should identify specific roles that can actually be engaged in conversation, rather than organizational units such as “the Engineering Department”; and when defining priority targets, include action items specifying “whom to contact and when to talk,” otherwise the list remains a document rather than becoming a plan.