A stakeholder map presentation should show who can influence a decision, who is affected by it, and where you need a better conversation before the project moves forward. A list of names is not enough. Give the map defined axes, explain why important roles are placed where they are, and finish with a small number of actions.
Prepare those judgments before turning your notes into a deck with Presenti's text-to-presentation workflow. AI can help organize the explanation, but it should not invent a person's authority, attitude or level of interest. The example below builds a map for a fictional service-rollout decision and shows how to discuss uncertainty without hiding it.
Define the decision before choosing the axes
Suppose a service team wants to pilot a new customer-request form. The immediate decision is whether to run a two-week pilot in one team. The map is for that decision, not a permanent ranking of everyone in the organization.
Use a power/interest map only if those two dimensions help the meeting. In this example, power means the ability to authorize, stop or materially change this pilot. Interest means the need or motivation to engage with this specific change. A senior job title alone does not determine either position.
Mindtools' stakeholder-analysis guide describes identifying stakeholders, prioritizing them on a power/interest grid and understanding their concerns. That is a useful starting structure. The presentation still needs evidence for its placements and a plan to hear from affected people who have little formal authority.
Do not silently substitute impact for interest. A customer can be heavily affected without knowing the project exists. An executive can be interested without being the person who approves the pilot. If impact is central to the decision, keep a separate impact note or use an impact-based map with appropriately named axes.
Build the map from role evidence
Before drawing quadrants, make a short working table. It forces the team to distinguish a known responsibility from a guess about someone's attitude. The following roles and observations are fictional.
| Role | Relevant evidence | Initial placement | What the team should learn or do |
|---|---|---|---|
| Service director | Approves pilot time and is accountable for request handling | Higher power, higher interest | Agree the decision criteria and the point at which the pilot would stop |
| Security reviewer | Can require changes to data fields before the pilot proceeds | Higher power; interest needs confirmation | Review the proposed fields and understand the approval process |
| Frontline team | Will use the form and handle exceptions, but cannot approve the pilot | Lower formal power, higher interest | Walk through difficult requests and record what would make the form unusable |
| Customer representative | Can bring examples of confusing or incomplete customer requests | Lower formal power, higher interest | Check whether the pilot covers the situations customers actually encounter |
| Finance approver | Approval is needed if the pilot requires additional spending | Higher conditional power, lower current interest | Clarify the spending trigger before assuming no approval is required |
| Adjacent department | May receive requests routed from the pilot; the routing effect is not yet known | Position unresolved | Confirm the handoff before placing the department on the grid |
Write role names rather than personal names when a wider audience does not need individual identities. Keep the detailed contact list separately. A public or broadly shared presentation rarely needs informal judgments about named colleagues.
Make four areas readable without turning them into labels for people
Place the service director toward the higher-power, higher-interest area. Put the frontline team and customer representative on the lower-power, higher-interest side. Put the finance approver toward higher power with a note that authority is conditional on spending. Show the security reviewer with an uncertainty marker along the interest dimension instead of pretending the team knows their level of involvement.
The lower-power, lower-interest area may be empty. That is acceptable. Do not invent a stakeholder to fill every quadrant or move a real role to make the graphic look balanced. An empty area communicates more honestly than a symmetrical but unsupported diagram.
Give the adjacent department an “unresolved” position beside the map. The reason is specific: the handoff effect has not been established. The next conversation may reveal that the department belongs in a very different place. A map is useful when it exposes that missing knowledge.
Separate the map from the evidence notes
Use short labels on the chart and put longer explanations alongside it. If six roles need six paragraphs inside the quadrants, the slide is trying to be both a map and a register. A numbered marker with a nearby note can keep a disputed placement readable.
Do not rely on color alone to distinguish “confirmed” from “uncertain.” Use an outline marker, a question mark with a legend, or the word “unconfirmed.” Avoid red/green labels such as “blocker” and “supporter” unless the underlying assessment is both appropriate and evidenced. Disagreement about a requirement is not the same thing as opposition to the project.
Present the map in three slides
The audience usually needs a short sequence, not a single overloaded matrix. For this pilot, three slides make the logic visible.
- Decision and scope. “Decide whether one service team can run the new-form pilot.” State the proposed duration, affected workflow and approvals still needed. Define power and interest in one line each.
- Map and two disputed positions. Show the roles on the same grid. Call attention to the security reviewer's unknown interest and the adjacent department's unresolved handoff, rather than narrating every marker.
- Conversations before the decision. Name the few missing facts, the role that will obtain them and what could change as a result.
A useful spoken explanation is: “The frontline team has less formal approval authority, but their exception cases determine whether this pilot is practical. We need that walkthrough before asking the director to approve it. The security review is a separate approval dependency, and we have not yet agreed how closely that reviewer needs to be involved.”
This is more useful than reading four generic quadrant instructions. It tells the audience why a placement matters for the next decision. It also makes clear that lower formal power is not a reason to ignore people who must use the new process.
Handle a placement disagreement by asking for evidence
If someone says the finance approver should be in a different quadrant, ask what decision the role can actually make and under what condition. The team may discover a spending threshold that changes the pilot's approval path. Update the note and position together; moving a dot without changing the explanation loses the reasoning.
Interest can also change. A department that initially needs only a short update may become closely involved when a pilot changes its incoming workload. Show the decision date and the event that would trigger a review of the map. Avoid displaying it as a permanent organizational truth.
Turn the map into the next conversations
A map should lead to a small set of actions. In the fictional pilot, the service lead can arrange the frontline walkthrough; the form owner can clarify the security review; and the pilot coordinator can confirm the adjacent department's handoff. Each action resolves a defined uncertainty.
Once those relationships and needs are understood, use a stakeholder communication plan to specify messages, channels and required responses. Keep that detailed schedule separate from the map: the map explains whom the decision depends on, while the communication plan organizes the conversations.
For a first presentation draft, use a source brief like this:
Create a three-slide stakeholder-map presentation for a fictional two-week request-form pilot. Slide one defines the decision and scope. Power means the ability to authorize, stop or materially change this pilot; interest means the need or motivation to engage with the change. Slide two maps the service director, frontline team, customer representative and conditional finance approval. The security reviewer's interest is unconfirmed. Keep the adjacent department outside the grid as unresolved until its handoff is understood. Slide three lists the conversations needed before approval. Do not invent attitudes, names, approval status or interview findings. Treat the map as an initial hypothesis.
Compare the resulting draft with the role table. Check that an unknown position has not become a confident label and that conditional approval has not become unconditional authority. If the map looks crowded, split its evidence notes onto a supporting slide instead of shrinking the role names.
End the meeting with what changed: a confirmed approval route, a newly identified affected group, or a question that still needs an answer. Those changes are the useful output of the stakeholder map.
