Stakeholder mapping

Skill stanislavnianko/product-discovery-claude-skills/plugins/discovery-phase/skills/stakeholder-mapping

[discovery-phase pack · discovery] Maps client-side AND agency-side stakeholders with their stakes, success metrics, concerns, decision rights, and conflicts. Two-tier map. Surfaces deal-breakers in week 1, not week 4. Produces stakeholder-map.md. Reads discovery-context.md.From its SKILL.md

Install

npx -y skills add stanislavnianko/product-discovery-claude-skills --skill stakeholder-mapping

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

4.7 KB, ~1.0k tokens by cl100k_base, as published. Nobody here has run it

Stakeholder Mapping

Part of the discovery-phase skill pack · discovery group · reads discovery-context.md (run profile-builder first if missing).

Two-tier map for outsourcing reality: client stakeholders + agency stakeholders. The agency tier is the one most often forgotten, and it's where engagement-killers (sales conflict, delivery capacity, partner dependencies) live.

Step 1 — Read discovery context

Read discovery-context.md (sections 1. Client → Decision-makers, 3. Engagement → Runner role) and problem-canvas.md if it exists (anchors stakeholders against the actual problem).

If discovery-context.md is missing, ask the BA inline: "(a) name 1–3 client decision-makers + role; (b) engagement mode (pre-sale / paid discovery / delivery / staff aug)?" — tag any unverified stakeholder field as [ASSUMED]. Never block; recommend profile-builder for high-stakes work.

Step 2 — List client-side stakeholders

Identify 3-6 people on the client side. Cover these roles (combine if one person fills multiple):

Decision-maker — whose approval ships this
Budget owner — who pays
Delivery owner (client side) — who'll integrate the result into their org
Impacted teams — whose work is touched (CS, sales, ops, security, legal)
Domain experts — compliance, security, accessibility — needed for sign-off
A sceptic — the person most likely to block. Always include. If everyone is supportive, the map is incomplete.

Step 3 — List agency-side stakeholders

Often skipped. Typical roles:

Engagement lead / account manager — owns the client relationship
Delivery owner (agency side) — would lead build if engagement converts
Discipline leads — engineering, design, QA — capacity gates
Sales / partnerships — if pre-sale, has commercial pressure
Domain SME — if the domain (healthcare, finance) requires specific expertise
Finance / ops — for fixed-fee viability

Step 4 — Per-stakeholder fields

For each stakeholder (both tiers):

Field	Purpose
Name + role + tier (client/agency)
Their stake	What they win/lose from the outcome
Their success metric	How they personally know this is worth it
Their concerns	In their own words, ideally a quote
Input needed (and when)	Which discovery phase needs them
Decision rights	Approve / veto / advise / inform

Step 5 — Surface conflicts

After both tiers are filled, scan the success-metric column. Conflicts often look like:

Client sales wants "fast time-to-value" vs client security wants "SSO integration first"
Agency sales wants "convert to delivery" vs agency engineering wants "scope this down or we'll miss deadlines"
Client decision-maker wants "build it" vs client end-user manager wants "fix the workflow first"

Name conflicts on the map. Do not try to resolve them here. Resolution happens during proposal/SoW or in stakeholder workshops.

Step 6 — 15-minute async check-ins

Recommend (or send, if BA has the access) a 3-bullet async message to each high-stakes stakeholder:

The problem-canvas one-liner.
"Here's what I think your success criterion is — right?"
"Anything you'd kill this engagement over? Say it now, not in 4 weeks."

Capture responses in the map.

Step 7 — Set review cadence

Pick one based on engagement timeline:

Pre-sale sprint (≤2 wks): no recurring review, ad-hoc sync per major artifact
Discovery sprint (3-4 wks): weekly async update, doc-based
Delivery phase: bi-weekly stakeholder readout
Staff aug: mirror client's existing rituals

Output

./discovery/stakeholder-map.md per ./template.md.

Append to _log.md: [stakeholder-mapping | YYYY-MM-DD] client_tier: <N>; agency_tier: <N>; conflicts: <N>; cadence: <cadence>.

Anti-patterns

Skipping the agency tier. It's where the most fixable conflicts hide.
No sceptic on the map. Find one. If you really can't, your discovery is happening inside an echo chamber.
"We'll loop them in later." Stakeholders who learn about a project on week 4 veto it on week 4. Cheaper to absorb the veto on week 1.
Static map. Update after major artifacts (insights, scope, prototype). Especially before any deliverable skill runs.

What ships with it: 1 file

469 B alongside SKILL.md

template.md469 B

Gives 0 of the 12 instructions most operations skills give in ~1.0k tokens

Counted across 483 of the 484 authors here whose files we hold, read 2026-08-07

Collect monitoring data throughout the simulationin 14 of 483, across 6 files
Set the random seed for reproducibilityin 14 of 483, across 6 files
Validate simulations against analytical solutionsin 12 of 483, across 4 files
Clarify goals, constraints, and inputsin 11 of 483, across 2 files
Implement contract tests for integration pointsin 11 of 483, across 2 files
Implement strangler fig infrastructure with API gatewayin 11 of 483, across 2 files
Audit modernized components for security vulnerabilitiesin 11 of 483, across 2 files
Avoid Python blocking calls in processesin 10 of 483, across 3 files
Use resource context managers for automatic cleanupin 9 of 483, across 2 files
Maintain consistent time unitsin 9 of 483, across 2 files
Validate outcomes against success criteriain 8 of 483, across 1 file
Analyze the legacy codebase for technical debtin 8 of 483, across 1 file

Said here and by no other author read

read discovery context
identify client-side stakeholders
fill per-stakeholder fields
name conflicts on the map
send async check-in messages
set review cadence

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.