PM - Stakeholder Map + RACI

Agent mode (--agent)

Supports --agent: runs autonomously in a subagent, drafts the artifact from existing inputs, and returns a short summary + coverage note.

• No flag → interactive (default); if inputs are heavy, offer agent mode.
• --agent → obey. First check inputs are complete. Anything missing: do NOT invent it - mark [ASSUMED - what/why] in the output and summary. Never hallucinate to fill a gap.

Standalone run

Runs with or without a Pureinn workspace - it needs no other skill's artifact, so it works as a single tool from an install that never ran /pureinn.

• No workspace: create just the folder this skill writes into, or write to a path the user names, and say where the file went. Do not scaffold a project, do not invent a state.json, and do not send the user to /pureinn first.
• Read pureinn-variables.md / state.json where a value is actually used, not at the top of the run. Missing value: continue and name the capability it costs.

What this skill does

Generates three artifacts:

1. Stakeholder Map - Power/Interest matrix with engagement strategy
2. RACI Matrix - Responsible / Accountable / Consulted / Informed for key decisions
3. Escalation Tree - Who resolves conflicts and blockers

Dependencies

This skill has no hard prerequisites. It is typically the first skill run in Phase 1.

Produces artifacts used by:

• pm-project-charter - stakeholder context informs charter decisions
• pm-team-roster - RACI and decision authority context
• pm-comms-charter - stakeholder communication needs

Step 0: Current state check

Check for existing artifacts:

• Stakeholder Map
• RACI Matrix
• Escalation Tree

Look for: missing stakeholders, RACI gaps (decisions with no single Accountable), conflicts with Project Charter or Team Roster if those exist.

Re-run behavior (delta mode): If these artifacts already exist, do not redraft blank. Compare new answers against the existing map/matrix/tree, show what changed (new stakeholders, power/interest shifts, new decisions), and update only what the new input supports.

Interaction: Group related questions (2-4 per round) and confirm before moving on. For any A/B/C/D choice, use the AskUserQuestion tool with one option marked (Recommended) - never print options as plain text. Keep open-ended questions free-text (don't fake options). If the user is unsure, propose 3-4 concrete options plus "Other". Surface an assumption the moment you make one; never fabricate to fill a gap. (Full standard: CLAUDE.md.)

Step 1: Gather inputs

Ask questions in 2 groups. After each group show a summary and wait for confirmation before continuing.

Group 1 of 2 - Stakeholders

Ask all as plain text:

List the internal team - roles involved in this project. For each, briefly describe their interest and how much influence they have over project outcomes.

Who outside the team has a stake in or influence over this project? List external stakeholders: investors, customer segments, partners, regulators, vendors. For each, what do they care about and how much power do they have? (can kill it, can block it, can slow it, or can simply be ignored)

Late-veto check (ask explicitly - this is the most common stakeholder-mapping failure): "Who can veto this project at the END - close to or at launch?" Typical late vetoers: legal, compliance/DPO, security review, procurement, works council, app-store review, a key integration partner's approval process. They show zero interest for months, then block the release. Anyone identified here goes into Keep Satisfied with a scheduled early touchpoint (Phase 1-2, not Phase 7) noted in their engagement strategy.

After answers, confirm: "Is this a complete picture of who matters for this project?"

Group 2 of 2 - Decisions and governance

Ask all as plain text:

What are the 5-8 most important decisions in this project? (e.g., Go/No-Go at phase gates, MVP scope, tech stack, pricing, hiring, fundraising)

Who has the final word when there is disagreement? Are there anticipated conflicts between stakeholders that need a clear escalation path?

After answers, show complete stakeholder inputs summary. Ask for final confirmation before generating the artifact.

Step 2: Generate artifacts

Generate all documents in English.

Placement heuristics (apply when classifying, and explain your placement if it differs from the user's):

• Power = can they kill, block, or materially slow the project - not seniority. A junior compliance officer who signs off releases has high power; a VP with no touchpoint does not.
• When unsure between two quadrants, classify one power level higher - the cost of over-managing a stakeholder is a few updates; the cost of under-managing one is a blocked launch.
• Payer ≠ user (B2B): if the person who pays is not the person who uses the product, they are two stakeholders with different interests - map both, never merge them.

ARTIFACT 1: Stakeholder Map

# Stakeholder Map - [Product Name]

> **Version:** 1.0 · **Date:** [date]

---

## Power / Interest Matrix

| | Low interest | High interest |
|---|---|---|
| **High power** | 👁 Keep satisfied | ✅ Manage closely |
| **Low power** | 🔍 Monitor | 📢 Keep informed |

### Manage Closely (High power, High interest)
| Stakeholder | Role | Interest | Engagement strategy |
|---|---|---|---|
| [Name/Role] | [Type: Internal/External] | [What they care about] | [How we engage] |

### Keep Satisfied (High power, Low interest)
| Stakeholder | Role | Interest | Engagement strategy |
|---|---|---|---|
| [Name/Role] | [Type] | [What they care about] | [How we engage] |

### Keep Informed (Low power, High interest)
| Stakeholder | Role | Interest | Engagement strategy |
|---|---|---|---|
| [Name/Role] | [Type] | [What they care about] | [How we engage] |

### Monitor (Low power, Low interest)
| Stakeholder | Role | Interest | Engagement strategy |
|---|---|---|---|
| [Name/Role] | [Type] | [What they care about] | [How we engage] |

---

## Stakeholder Register

| Name / Role | Type | Interests | Concerns / Risks | Preferred communication | Frequency |
|---|---|---|---|---|---|
| [Stakeholder 1] | Internal | [Interests] | [Concerns] | [Email/Slack/Meeting] | [Weekly/Monthly] |

ARTIFACT 2: RACI Matrix

# RACI Matrix - [Product Name]

> **R** = Responsible (does the work) · **A** = Accountable (owns the outcome) · **C** = Consulted (input requested) · **I** = Informed (receives update)
> Each decision has exactly one **A**.

| Decision / Activity | [Stakeholder 1] | [Stakeholder 2] | [Stakeholder 3] | [Stakeholder 4] | [Stakeholder 5] |
|---|---|---|---|---|---|
| [Decision 1] | A | R | C | I | - |
| [Decision 2] | | | | | |
| Phase 1 Go/No-Go | | | | | |
| Phase 2 Go/No-Go | | | | | |
| MVP Scope lock | | | | | |
| Tech stack decision | | | | | |
| Hiring decisions | | | | | |
| Budget / Fundraising | | | | | |

---

**Warning flags:**
- More than one **A** per decision = conflict, needs resolution
- Stakeholder with no **R** anywhere = likely not needed in core team

ARTIFACT 3: Escalation Tree

# Escalation Tree - [Product Name]

> Who resolves what when the team cannot agree.

---

## Escalation levels

### Level 1 - Operational decisions (within 24h)
**Decision owner:** [PM / Tech Lead]
**Types:** Scope details, technical implementation choices, daily priorities

### Level 2 - Strategic decisions (within 72h)
**Decision owner:** [PM + Leadership]
**Types:** MVP scope changes, timeline shifts, resource allocation, tech stack changes

### Level 3 - Critical / Escalated (ASAP)
**Decision owner:** [CEO / Founder / Board]
**Types:** Phase Go/No-Go, budget overruns, legal / compliance blockers, pivot decisions

---

## Conflict resolution protocol

1. Team attempts async resolution (Slack thread, 24h window)
2. If unresolved → sync meeting (max 30 min, PM facilitates)
3. If still unresolved → escalate to Level 2
4. Document the decision (what, why, who decided) → log in project workspace

---

## Anticipated conflicts and resolution rules

| Conflict | Parties | Resolution rule / Decider |
|---|---|---|
| [Anticipated conflict 1, e.g. tech vs. business priority] | [Parties] | [Who decides, based on what] |

Internal completeness checklist

Stakeholder Map must cover:

• All internal stakeholders identified with role and interest (CEO, CTO, CFO, PM, Tech Lead, UX, Marketing, Sales, Support, Legal, Compliance, DPO if personal data handled)
• All external stakeholders identified (customers, investors, partners, regulators, vendors, integration partners)
• Power/Interest matrix populated across all 4 quadrants
• Payer vs. end user distinction made explicitly (critical for B2B SaaS)
• For AI products: who owns AI ethics, bias, and model decision accountability

RACI Matrix must cover:

• Decision authority over product scope - one owner
• Decision authority over tech stack - one owner
• Decision authority for design approval - one owner
• Final say on Go/No-Go at each phase gate - one owner
• Each key decision has exactly one Accountable
• For AI/data products: who owns data strategy and model decisions

Escalation Tree must cover:

• Who can block the project (and mitigation per blocker)
• Escalation path defined with time limits per level
• Conflict resolution protocol (async first, then sync, then escalate)
• Anticipated conflicts identified with resolution rules

Save to

pureinn-workspace/[project-slug]/artifacts/phase-1-foundation/stakeholder-map.md
pureinn-workspace/[project-slug]/artifacts/phase-1-foundation/raci-matrix.md
pureinn-workspace/[project-slug]/artifacts/phase-1-foundation/escalation-tree.md

Handoff

Čo si teraz má: Zmapovaných stakeholderov podľa vplyvu a záujmu (+ RACI, eskalačný strom) - vieš koho zapojiť do ktorých rozhodnutí a kadiaľ eskalovať.

Ďalší krok: /pm-project-charter — ciele, scope a success kritériá, na ktoré sa stakeholdri viažu. Alebo /pureinn pre Phase 1 gate check.

Môžeš preskočiť ak: Si solo builder bez externých investorov či boardu - tento aj nasledujúce Phase 1 koordinačné skilly preskoč, choď rovno do Phase 2 (/pm-tech-feasibility).