| name | stakeholder-mapper |
| description | Maps product decision-makers, stakeholders, and communication channels. Identifies approval paths, creates RACI matrix, and flags potential conflicts. Returns stakeholder map with roles, priorities, and influence flow. |
| allowed-tools | Read, Write |
| effort | medium |
Stakeholder Mapper
When to activate
Before launching a feature, making a major product decision, or planning a release rollout. You have org chart or team roster data and need to understand approval dependencies, communication channels, and competing priorities. Activation requires clarity on the decision type (design, pricing, feature launch, policy change).
When NOT to use
Not for general org charts—this focuses on product decision-making stakeholders only. Not for managing internal politics or personal conflicts. Not without sufficient organizational context. Not for documenting individual performance or team issues. Not for decisions where there is no formal approval process.
Stakeholder Framework
Core Roles:
- Decision-maker: Has final approval authority; often Product Lead, CPO, VP Product
- Influencer: Strong input; customer success, engineering leadership, design lead
- Executor: Implements; engineering, design, marketing teams
- Approver (Legal/Security): Gating authority for compliance, data, regulatory concerns
- Customer Voice: Customer Advisory Board, support, sales feedback
RACI Matrix:
- Responsible: Does the work
- Accountable: Final authority/ownership
- Consulted: Provides input (two-way conversation)
- Informed: Kept in the loop (one-way notification)
Analysis Steps
- Map decision type: Feature launch? Design change? Pricing? Timing?
- Identify accountable: Who has final sign-off?
- Identify responsible: Which team executes?
- Identify consulted: Who must have input before approval?
- Identify informed: Who needs notification?
- Identify blockers: Who has veto authority? (Legal, Security, Customer Success)
- Identify conflicts: Competing priorities between stakeholders?
- Map communication: How/when do approvals flow?
Output Format
# Stakeholder Map: [Feature/Decision Name]
## Decision Overview
**Type:** [Feature Launch / Pricing Change / Design / Policy / Timeline]
**Scope:** [What's being decided]
**Timeline:** [Decision deadline]
---
## RACI Matrix
| Role | Name | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|---|
| VP Product | [Name] | | X | | |
| Product Manager | [Name] | X | | | |
| Engineering Lead | [Name] | X | X | | |
| Design Lead | [Name] | X | | X | |
| Customer Success | [Name] | | | X | |
| Sales Lead | [Name] | | | X | X |
| Finance | [Name] | | | X | |
| Legal | [Name] | | | X | |
---
## Approval Path
**1. Product Manager** → Drafts brief, gathers customer signals
**2. Design Lead** → Provides design feasibility, UX sign-off
**3. Engineering Lead** → Provides technical feasibility, resource estimate
**4. Customer Success** → Signals customer demand and support impact
**5. VP Product (Accountable)** → Makes final decision
**Timeline:** Brief ready [Date] → Design review [Date] → Engineering estimate [Date] → Executive decision [Date]
---
## Stakeholder Priorities
| Stakeholder | Primary Goal | Concern | Influence |
|---|---|---|---|
| [Name/Role] | [What do they care about?] | [What could block them?] | [How much can they block progress?] |
**Example:**
| VP Product | Align with Q3 OKRs, customer retention | Scope creep, timeline risk | HIGH — can reject or delay |
| Engineering Lead | Maintain velocity, avoid technical debt | Unrealistic timeline, unclear spec | HIGH — can flag unfeasible |
| Customer Success | Customer satisfaction, support burden | Unclear documentation, UX friction | MEDIUM — can flag adoption risk |
---
## Conflict Resolution
**Potential Conflicts:**
- [Stakeholder A priority] vs. [Stakeholder B priority] — *How to resolve:* [Recommendation]
**Decision-making principle:** [How to weight tradeoffs when conflicts arise]
---
## Communication & Approvals
**Approval Gate 1:** Product definition (PM + Design)
**Approval Gate 2:** Technical feasibility (Engineering)
**Approval Gate 3:** Customer impact (Customer Success)
Executive approval (VP Product)
[Date]: Stakeholder alignment meeting
[Date]: Draft approval gates
[Date]: Final approval
[Date]: Launch communication to team
---
[If someone critical isn't represented, flag it]
[If approval paths have conflicting dates]
[If accountable role isn't clear]
[If approval depends on outside team/legal/security]
---
Example
Stakeholder Map: Tiered Pricing Launch
Decision Overview
Type: Pricing Change + Product Launch
Scope: Introduce 3-tier pricing model (Pro, Business, Enterprise) replacing flat-rate
Timeline: Decision by June 15; launch July 1
RACI Matrix
| Role | Name | Responsible | Accountable | Consulted | Informed |
|---|
| VP Product | Alice Chen | | X | | |
| Product Manager | Bob Smith | X | | X | |
| Finance | Carol White | X | | X | |
| Engineering Lead | David Lee | X | | X | |
| Customer Success | Elena Garcia | | | X | |
| Sales Lead | Frank Brown | | | X | |
Approval Path
1. Finance → Models revenue impact, churn risk by tier
2. Product Manager → Maps features to tiers, justifies positioning
3. Engineering Lead → Confirms feature gating and rollout feasibility
4. Customer Success → Flags at-risk accounts and migration needs
5. VP Product (Accountable) → Makes final tier/pricing decision
Timeline: Model ready [June 5] → Feature map [June 8] → Engineering feasibility [June 10] → CS impact assessment [June 12] → Executive decision [June 15]
Stakeholder Priorities
| Stakeholder | Primary Goal | Concern | Influence |
|---|
| Alice (VP Product) | Increase ARPU 15%, retain enterprise | Churn risk in SMB segment | HIGH — final decision |
| Bob (PM) | Clear tier positioning, customer value | Complexity, support burden | MEDIUM — can flag UX risk |
| Carol (Finance) | Maximize revenue, <5% churn impact | Model conservatism, adoption risk | HIGH — can veto pricing |
| David (Engineering) | Clean feature gating, no tech debt | Timeline pressure, scope creep | MEDIUM — can delay launch |
| Elena (CS) | Smooth migration, zero support chaos | Customer confusion, migration burden | MEDIUM — can flag risk |
| Frank (Sales) | Clear messaging, competitive positioning | Pricing credibility, deal friction | LOW-MEDIUM — advisory |
Conflict Resolution
Conflict 1: Finance wants aggressive pricing (14% churn projected) vs. CS concerned about SMB flight
- Resolution: Finance models retention incentive (3-month discount for Enterprise upgrades); CS owns outbound migration support
Conflict 2: Engineering flagged 4-week timeline vs. Product wants July 1 launch
- Resolution: Defer feature gating for "Starter" tier to August; launch with 2-tier (Pro, Enterprise) on July 1
Decision-making principle: Customer retention (zero unforced churn) takes priority over revenue optimization
Risk Flags:
- Legal compliance not mapped (check GDPR/SOC2 implications of pricing tiers)
- No customer advisory board input documented
- Migration communication plan undefined
