The Stakeholder Heat Map
There is a particular kind of meeting that goes smoothly and then dies quietly afterward. Everyone nodded. Nobody objected. The sponsor said “great work.” And then two weeks pass, and nothing happens.
The meeting didn’t fail. The pitch did — before it started. The presenter designed it for the person in the room with the highest title, or for the person they knew best, or for the audience that was easiest to impress. They forgot that rooms are not single entities. They’re coalitions, and coalitions require different things.
The Stakeholder Heat Map is a 20-minute exercise you do before writing a single slide. It tells you exactly who’s in the room, what each person needs in order to support you, what fear would make them block you even if they like you personally, and what specific evidence reduces that fear. When you fill it in honestly, it will often change what you put in your pitch entirely.
Who it’s for
Anyone pitching a change that touches more than one team or requires more than one person’s support. The word “stakeholder” sounds corporate, but this applies equally to a founder pitching investors, a consultant recommending a vendor change, a manager pushing for headcount, or a freelancer proposing a new engagement scope.
When to use it
- The decision affects people who aren’t in the room.
- You have one loud, visible skeptic but aren’t sure who else might be quietly resistant.
- You’ve pitched this before and gotten “let’s revisit” more than once without a real reason.
- You’re optimizing for a clean presentation when you should be optimizing for a clean decision.
Core framework
Draw a table with names or roles down the left side. Run three columns across the top:
Win — What does this person need to be able to say about the outcome, publicly, to look good at their job? Not what they personally care about intellectually. What does their professional environment reward? A VP of Finance wins when spend is predictable and controllable. A Head of Security wins when there’s an audit trail and no surprises. An Engineering Manager wins when there’s a path forward that doesn’t create more toil for their team.
Veto — What single fear would cause this person to block progress, even without ever saying the word no? Vetoes are almost never stated directly. They come as “let’s slow down,” “I want to loop in legal,” or “can we revisit this next quarter.” If you can name the fear, you can address it before it becomes a blocker. Common veto fears: being blamed if it fails, losing budget they already have, having to clean up someone else’s mess, creating work they don’t have capacity for.
Proof — What specific evidence would reduce their veto fear enough that they’d support the move? This is not your favorite proof artifact. This is what they find credible. Finance needs numbers with methodology. Legal needs precedent. Engineering needs architecture review. Executives often need a reference from a company they respect. Fill this cell honestly — if you can’t name the proof, you’re not ready to pitch this person yet.
No more than seven names
If you have more than seven rows, group people into decision roles: champion, economic buyer, technical reviewer, end user, executive sponsor. You can’t tailor a pitch to twelve individuals. You can tailor one to five decision roles.
Worked example
Imagine you’re proposing a new vendor for identity management — a change that affects engineering, security, finance, and the CTO.
| Name / Role | Win | Veto | Proof |
|---|---|---|---|
| Riya (Finance) | Predictable, capped OPEX spend | Surprise cost overruns mid-contract | Fixed-price contract + monthly cap clause + cancellation terms |
| Jordan (Security) | Clean audit trail, no new attack surface | Introducing a vendor without SOC2 compliance | SOC2 Type II report + existing IdP integration so no new credentials |
| Marcus (Eng Lead) | Fewer on-call pages, better dev experience | Another tool the team has to learn and maintain | Migration estimate under 2 engineer-weeks + reference from a team their size |
| CTO | Solid technical decision, no surprises | Being blindsided by something that should have been vetted | That her team ran the analysis, with security and finance already aligned |
Notice how the CTO’s veto isn’t “bad technology.” It’s the political risk of being caught off guard. Her proof isn’t a technical deep-dive. It’s that the people she trusts already reviewed it. That changes what you put on the first slide entirely.
Common mistakes
Treating title as proxy for influence. The person who can block a decision isn’t always the most senior person in the room. Often it’s the engineer who will have to implement it, or the manager who will have to absorb the work into their team. Map influence, not org chart position.
Filling in the Proof column with what impressed you. It’s natural to lead with the evidence you find most compelling. But you built the thing — of course you find it compelling. Ask yourself: what would a skeptical version of this person say about my proof? Use that question to sharpen it.
Skipping the Veto column. It feels confrontational to think about who might block you. But vetoes don’t go away because you ignore them. They go away because you surface and address them before the meeting. The purpose of the veto column is not to be paranoid — it’s to give yourself a specific problem to solve.
Doing the heat map after you’ve finished the deck. It changes what you put in the deck. Do it first.
Practice prompt
Pick one upcoming meeting that requires a decision. Fill in the heat map — even partial rows are useful. Then ask: is there anyone whose Proof cell I cannot fill in? If yes, go get that proof before you schedule the meeting. Or schedule the meeting for a smaller room until you have it.
Related reading
- Five-line idea brief — compress your pitch once you know your audience
- Demo vs pitch vs update — choose the right container for the room
- Internal selling: when your biggest obstacle is alignment — a deeper look at organizational dynamics