Stakeholder Map Template

The stakeholder who kills your launch is almost never the one you were managing closely. It's the compliance reviewer nobody looped in, who arrives at the pre-launch gate with a terms-of-service objection that costs three weeks. Or the analytics team whose dashboard quietly breaks the morning your schema change ships, because you never knew they'd built a report on your event names.

Neither was hostile. Both were off the map.

A stakeholder map is the thirty-minute exercise that drags those people out of your blind spot. But most maps fail in a specific, predictable way — they get filled in as a seniority chart, and the compliance reviewer scores low on every column right up until the day he stops you.

This is the template and how to fill it. For why the people who block you are systematically the ones you didn't think to consult, see stakeholder mapping for technical changes.

The template

| Stakeholder | Role | Interest | Influence | Engagement | Owner | Cadence | Notes |
|-------------|------|----------|-----------|------------|-------|---------|-------|
|             |      | H/M/L    | H/M/L     |            |       |         |       |

Two of those columns are routinely left to guesswork, so define them before you fill anything in.

Interest is how much this person's own work changes because of yours. High means the outcome lands in their day — a workflow they run, a number they're measured on, a system they maintain. Low means they may still be able to stop you while genuinely not caring about the result, which is exactly the combination that produces the surprise veto.

Engagement is the action the row commits you to, and the five values come from the power–interest grid usually credited to Mendelow: Manage closely (high influence, high interest — bring them into decisions), Keep satisfied (high influence, low interest — brief them early, never surprise them), Involve (low influence, high interest — consult, and tell them what you did with it), Inform (low influence, low interest — one-way updates), Keep informed (the standing version of Inform for a long project). If you cannot pick one of the five, the row's Interest and Influence are not yet honest.

Eight columns. Six are bookkeeping. Two do the work: Influence, which is the one everyone gets wrong, and Owner, which is the one that turns the map from a list into a plan.

Influence is a gate, not a job title

Here is the mistake, and it's near-universal: teams read influence as seniority — how important is this person in the organisation? Filled in that way, the VP scores High and the compliance reviewer scores Low, and the map faithfully reproduces the org chart you already had in your head. It adds nothing, which is why so many stakeholder maps feel like paperwork.

Influence in this context means something narrower and far more useful:

What specifically can this person stop, and at which gate?

Run the compliance reviewer through that. He is junior. He has no interest in your project — he has forty others. He will never attend your standup. And he holds an absolute veto at the pre-launch review, which is a gate your launch date depends on. That is maximal influence, and the seniority reading misses it completely.

Now run the VP of Sales through the same question. Genuinely senior, genuinely interested, and — on this project — able to complain loudly but not to stop anything. That's real, and it's not the same thing. It changes what you owe them: information, not sign-off.

The test: for every stakeholder you've marked High influence, name the specific gate, approval, or system they control. If you can't name one, you've recorded their seniority. If you can name a gate for someone you marked Low, that row is wrong and it's the one most likely to hurt you.

The eight most-missed rows

The stakeholders that surface late share a property: they're connected to your project through a system rather than through the org chart, so no amount of thinking about people finds them.

Who	Why they're invisible	The gate they hold
Compliance / legal reviewer	No interest, no seniority, not in your team's network	Absolute veto at a pre-launch gate
The dashboard owner	Built a report on your data months ago and never told you	Nothing — but they break silently, and loudly afterwards
An old integration partner	Built against your API years ago; the relationship predates you	Can escalate a breaking change straight to leadership
Security reviewer	Usually a quick approval, so it's assumed away	A blocking review that queues behind other work
The newly-arrived VP	Wasn't there when the project was scoped	Can re-open decisions everyone thought were settled
Support lead	Downstream of you; never consulted upstream	Absorbs the cost of a bad rollout, and will say so
Data / privacy owner	Only appears when personal data is involved	Can force a design change late
The internal power user	Not senior, not formally consulted	Informal authority — the strongest advocate or the loudest critic

The prompt that surfaces most of these isn't about people at all. It's: what systems, data, or contracts does this change touch, and who owns each one? Ask who would be unhappy and you get a political list. Ask what breaks and you get the real one.

The test: name every system your change touches — schemas, APIs, dashboards, exports, scheduled jobs — and find the owner of each. Any owner not already on your map is exactly the kind of person who surprises you.

The filled version

Eight rows for a mid-sized launch. Note that engagement follows from the combination of interest and influence, not from rank:

Stakeholder	Interest	Influence	Engagement	Owner	Cadence
VP Product (sponsor)	H	H	Manage closely	Sam	Weekly
Compliance reviewer	L	H	Keep satisfied — book the gate early	Sam	At design + T-3 weeks
Success team	H	M	Involve	Pat	Bi-weekly
Security reviewer	L	H	Keep satisfied — queue the review	Pat	At design + pre-launch
Sales VP	M	H	Keep satisfied	Sam	Monthly
Analytics owner	L	M	Inform — flag the schema change	Pat	Before migration
Power users (beta)	H	L	Keep informed	PM	At milestones
Finance	L	M	Inform	Sam	Start and end

Two rows carry most of the value, and both are low-interest. The compliance reviewer and the security reviewer don't care about your project and can each stop it — so the action isn't relationship-building, it's booking their gate early enough that the queue isn't the problem. That's a calendar action, and it's the single highest-return thing a stakeholder map produces.

The test: look at your High-influence, Low-interest rows. If the engagement plan for them is anything other than a specific date already in a calendar, you have identified the risk without mitigating it.

Owner and cadence are what make it a plan

A map with interest and influence filled in and Owner blank is an analysis. It tells you who matters and commits nobody to anything, which is why so many maps are built once and never opened again.

The Owner column means: one named person is responsible for that relationship not going wrong. Not the team. A person. The cadence is what they've committed to — and "at milestones" is a real cadence, while "as needed" is not, because nobody has ever been reminded by "as needed."

The test: every row has a person's name and a frequency or a date. Rows with neither aren't tracked; they're just recorded.

When to skip it

The map costs about thirty minutes, and it's genuinely not worth it for work that stays inside one team with an obvious stakeholder list. Building one there produces a document whose only reader is its author, and it teaches the team that the exercise is ceremony — which costs you later, on the project that needed it.

Build one when the work crosses a boundary: another team's system, an external partner, a regulated area, a customer-visible change, or a first-of-its-kind initiative where the approval path itself is unknown. The tell is simple — if you can't confidently list who has to say yes before this ships, that uncertainty is the reason to map it.

One more caution on size. A thirty-row map is as useless as no map, because attention doesn't scale and everything ends up nominally Monitor. If you're past about a dozen rows, most of them are context rather than stakeholders. Keep the ones who hold a gate or absorb the impact.

The test: can you name who has to say yes before this ships, without looking anything up? If yes, skip the map. If no, that's the map's whole job.

What to do with yours

Don't fill in eight columns for twenty people. Do this instead, in about twenty minutes.

List every system, dataset, contract, and approval gate your change touches. Find the owner of each. Then take that list — plus the obvious people you'd have named anyway — and for each one answer only the influence question: what can this person stop, and at which gate?

Sort by that answer. The rows where you can name a real gate get a named owner and a date in a calendar this week. Everything else gets one line and no further effort.

The map isn't a picture of your organisation's politics, and it stops being useful the moment it becomes one. It's a list of the specific places your project can be stopped, with a person's name against each — and the reason it's worth thirty minutes is that the compliance reviewer costs three weeks, and he is always, in hindsight, the one nobody thought to write down.