Why build the stakeholder map before the requirements doc, not after?

Because every requirement in the doc has to trace to a named stakeholder need — you can't trace to a name you haven't identified yet. Building the map first means the requirements doc inherits a ready-made list of whose needs to capture and who signs off, instead of the BA reconstructing that under pressure mid-interview.

What if two stakeholders want contradictory things?

That's exactly what the RACI is for — it names one Accountable person per decision, so a conflict between a Consulted stakeholder's preference and the Accountable owner's call has a clear resolution path. Surface the contradiction explicitly in the map rather than quietly picking a side; the Accountable name is who breaks the tie, not Claude and not the BA.

How do I handle a stakeholder who won't engage or won't answer clearly?

Note it in the map as an open gap rather than guessing at their need — an assumed need is worse than an acknowledged unknown, because it can pass silently into a requirement nobody actually asked for. Flag it, and chase the real answer before requirements gathering treats that stakeholder's need as settled.

Does the RACI need to be reviewed by anyone besides the BA?

Yes — always. The BA drafts it with Claude, but every Accountable name has to be confirmed by that person or their manager, not just declared in the doc. An unconfirmed RACI is a disagreement waiting to surface the first time a decision is actually made.

Map every stakeholder before you write a single requirement

when to reach for this

A new initiative lands with a tangle of names — some people affected, some who decide, some who just need to be kept in the loop — and nobody has mapped who is which. Without that map, requirements get gathered from whoever's loudest, sign-off gets skipped because no one was named accountable, and a 'stakeholder' who should have been consulted finds out at launch. The fix is a stakeholder map built before anything else: who cares, what they need, how much influence and interest they carry, and a RACI (Responsible/Accountable/Consulted/Informed) for each key decision. This is the first thing a BA does on any initiative — everything downstream, starting with the requirements doc, names its owners from this map.

gather this first

The rough list of people connected to this initiative — an org chart, a meeting invite list, an email thread, even names typed straight into the chat in Claude Desktop.
Any notes on who asked for this, who's paying for it, and who has to live with the outcome day to day.
The initiative's key decisions so far, or a first guess at them — scope, budget, launch date, design approach — so the RACI has something concrete to attach to.

the workflow

List everyone connected — before judging who matters

Open the folder with your invite list or notes in Claude Desktop and ask in the chat — no terminal needed. Get the full cast first. Sorting by importance too early is how a quiet-but-critical stakeholder gets dropped.

you ask

Here's the invite list and notes for this initiative. List every person or group connected to it in any way — sponsors, users, approvers, people whose team is affected, anyone who'll be consulted or just informed. Don't rank them yet, just give me the full roster with a one-line note on their apparent connection to the initiative.

what you get back A complete roster — "Sarah Chen, Finance Director, approves budget; the Ops team, will use the new process daily; Legal, must review data-handling change" — with nothing filtered out yet.

Resist trimming the list. The person you cut here is the one who blocks sign-off in week six.
Score influence and interest — and name what each stakeholder actually needs

For each person on the roster, work out how much say they have, how much they care, and what outcome they're actually after. This is what turns a name list into a map you can act on.

you ask

For each person on the roster, score their influence (how much power they have over this initiative's direction) and interest (how much it affects them) as high/medium/low, and write one sentence on what they specifically need from this initiative — not what we assume, what they'd say themselves if asked. Flag anyone high-influence but low-interest — they're the ones who get missed until it's too late.

what you get back A scored map — "Sarah Chen: high influence, medium interest, needs the budget impact clearly bounded before she'll approve" — with the high-influence/low-interest group flagged separately.

The flagged group is the highest-value output here. They won't chase you for updates, so you have to chase them.
Build the RACI for the initiative's key decisions

Turn the map into an accountability grid. Every key decision gets exactly one Accountable name — the person whose sign-off actually counts — plus who's Responsible for doing the work, who must be Consulted, and who just needs to be Informed.

you ask

Here are the key decisions for this initiative: [list them, e.g. final scope, budget approval, design approach, go-live date]. Build a RACI table across the stakeholder roster: for each decision, who is Responsible, Accountable, Consulted, and Informed. Every decision must have exactly one Accountable person. Flag any decision where you can't tell who's Accountable from what I've given you.

what you get back A RACI table with one clear Accountable owner per decision, and an honest flag on any row where the accountable owner isn't yet clear from the input — those are the gaps to close with a real person, not guess at.

Never let Claude assign the Accountable role by inference alone when it's ambiguous — that's a decision for a real person to confirm, not a default to accept.
Surface the traceability gaps

Before calling the map done, check it against the initiative's stated goals — does every goal have a stakeholder who owns it, and does every high-influence stakeholder have a documented need?

you ask

Review the finished map and RACI against these initiative goals: [paste them]. Flag any goal with no clear owning stakeholder, any high-influence person with no documented need, and any decision where the Accountable name is still unconfirmed. This is the gap list to close before requirements gathering starts.

what you get back A short, specific gap list — "no stakeholder owns the 'reduce processing time' goal; the go-live date's Accountable owner is unconfirmed" — each one a name to go get, not a problem to solve in the chat.
Assemble the stakeholder-map.md

Pull it into one canonical file — the roster, the influence/interest scoring, the needs, and the RACI. This is what the requirements doc and every downstream playbook points back to when it needs to name an owner.

you ask

Assemble everything into one stakeholder-map.md: the roster with influence/interest scores and needs, the RACI table by decision, and the gap list still to close. Keep each stakeholder entry to two or three lines so the whole map stays scannable in one sitting.

what you get back A single, paste-ready stakeholder-map.md — every stakeholder's need, influence, interest, and RACI role in one place, ready to hand to whoever runs the next interview or drafts the requirements doc.

Save this file at the top of your project folder. Every future 'who signs off on this?' question gets answered by pointing at stakeholder-map.md, not by asking around again.

make it your own

Feeds the requirements doc: hand stakeholder-map.md straight into Turn interview notes into a requirements doc — every requirement traces back to a named stakeholder need from this map, which is the whole traceability guardrail.
Re-run when the cast changes: a reorg, a new sponsor, or a stakeholder leaving the project means the RACI may no longer be accurate — refresh the map rather than letting an old Accountable name quietly go stale.
Make it a reusable skill (Power Track): load the stakeholder-mapping prompt sequence as a skill or a /stakeholders command so every new initiative starts from the same disciplined process (see the Features tab).
Cross-reference the workshop synthesis: if you're running a discovery workshop, bring this map in as the invite list and the RACI as the room's decision-rights reference (see Turn a messy workshop into a clean synthesis, stage 2).

watch out for

A map with no confirmed Accountable name is not done. Claude can draft a plausible RACI from what it's given, but 'plausible' isn't 'agreed' — every Accountable role must be confirmed by a real person before requirements gathering starts, not assumed from a title.
High-influence, low-interest stakeholders get missed by design. They won't ask for updates, so the map has to surface them explicitly — that flag in step two is the whole point of scoring interest separately from influence, not a nice-to-have.
Don't let the map go stale. A RACI built at kickoff and never revisited quietly drifts as people change roles or leave — an out-of-date Accountable name is worse than an acknowledged gap, because everyone still trusts it.
The roster is only as good as what you fed it. If the invite list only includes people already in the room, the map will miss whoever wasn't invited — cross-check against the org chart or a wider distribution list before calling the roster complete.

you'll end up with A single `stakeholder-map.md` — every stakeholder's need, influence, interest, and RACI role per key decision — that names exactly who owns what, so the requirements doc and everything downstream traces to a real, accountable person instead of an assumption.

Questions people ask

Why build the stakeholder map before the requirements doc, not after?: Because every requirement in the doc has to trace to a named stakeholder need — you can't trace to a name you haven't identified yet. Building the map first means the requirements doc inherits a ready-made list of whose needs to capture and who signs off, instead of the BA reconstructing that under pressure mid-interview.
What if two stakeholders want contradictory things?: That's exactly what the RACI is for — it names one Accountable person per decision, so a conflict between a Consulted stakeholder's preference and the Accountable owner's call has a clear resolution path. Surface the contradiction explicitly in the map rather than quietly picking a side; the Accountable name is who breaks the tie, not Claude and not the BA.
How do I handle a stakeholder who won't engage or won't answer clearly?: Note it in the map as an open gap rather than guessing at their need — an assumed need is worse than an acknowledged unknown, because it can pass silently into a requirement nobody actually asked for. Flag it, and chase the real answer before requirements gathering treats that stakeholder's need as settled.
Does the RACI need to be reviewed by anyone besides the BA?: Yes — always. The BA drafts it with Claude, but every Accountable name has to be confirmed by that person or their manager, not just declared in the doc. An unconfirmed RACI is a disagreement waiting to surface the first time a decision is actually made.