Stakeholder Mapping Asks the Wrong Question

Here's a stakeholder map I've seen a dozen times, in a dozen different tools. A customer, marked High Power, High Interest, top-right quadrant, exactly where every guide tells you to put them. Someone spent an afternoon on this. It's correct.

We booked ninety minutes with that same customer last month. I walked in expecting a decision: sign-off on the new onboarding flow. I walked out with three pages of notes on how their finance team reconciles invoices, and no sign-off. Nobody was rude. Nobody was unprepared. The map said this person mattered. It didn't say why, in this room, on this day.

The map wasn't stale, either. Nobody had reorganized. Nobody had lost budget or gained a new title. Nothing had changed since we filled it in. The map was accurate and useless at the same time.

That's the part most stakeholder-mapping advice skips. A chart can be perfectly up to date and still answer the wrong question.

Why "Update the Map More Often" Doesn't Fix This

The standard advice for a stakeholder map that stops working is to refresh it. Power shifts, priorities shift, so the thinking goes: schedule a review, tie it to your sprint cadence, keep the quadrants current, or the map turns into a historical artifact instead of a working product tool. That advice solves a real problem. It's not the one I ran into.

My map was current. The customer's power and interest hadn't moved an inch. What moved was the question I was bringing into the room. The map has no field for that, no matter how recently you touched it.

This is close to a point Teresa Torres makes about stakeholder work in product teams: the framework was never the hard part. Identifying who matters is the easy half. What determines whether a meeting goes well is something the quadrant chart doesn't touch at all. Updating the chart more often doesn't touch it either. You can re-run the workshop every sprint and still walk into the same ninety-minute mismatch, because the chart was never measuring the thing that broke.

Two Questions, One Axis

Here's the compression that's happening. A power-interest grid asks one question about a person: how much do they matter. It answers with one score, one quadrant, one label that sticks to that person until the next review.

But in practice, every stakeholder conversation is really answering two separate questions, and they don't move together:

• Do I need information from this person right now? They know something about the domain, the workflow, the edge cases, that I don't.
• Does this person need to approve what happens next? Nothing moves forward without their yes.

A person can score high on both, high on one, or low on both. That combination can flip between two meetings with the same person, in the same week. The power-interest axis has no way to express that, because it was built to describe the person, not the conversation.

It's worth noticing that even the more rigorous academic version of stakeholder theory doesn't collapse this into one number. Mitchell, Agle, and Wood's 1997 salience model (the closest thing stakeholder theory has to a formal framework) scores a stakeholder on three separate attributes: power, legitimacy, and urgency, each judged independently for the issue at hand. It already treated power as only one of three separate signals, not a single score standing in for all of them. Somewhere between the academic paper and the whiteboard template, three independent questions became one static label.

The left side is a snapshot of a person. The right side is a question you ask before every meeting, and the answer to both parts can change independently, even for someone you've worked with for years.

The Customer Who Is Both

The customer from the opening isn't an edge case. She's the normal case for anyone doing product work with real users instead of internal stakeholders. She explains how her team's invoicing works: that's the information role. Two weeks later, she signs off on whether the new onboarding flow ships: that's the approval role. Same person, same relationship, same spot on any power-interest grid you'd draw. Two entirely different jobs to do in the room.

Here's what goes wrong when this gets muddled from the approval side: an approval session that turns into an open-ended discussion never gets a real yes. People nod along, ask a few questions, and the meeting ends without the sign-off it was supposed to produce, not because anyone disagreed, but because nobody was being asked to decide anything. Run the meeting the other way (treat an information-gathering conversation like a formal approval) and you get the opposite failure: people give you their gut reaction wrapped in a signature, and you leave with a decision built on a five-minute impression instead of the domain knowledge you needed.

Both failures look identical from the outside. A meeting that "didn't quite work." The map didn't predict either one, because the map was never asked which one it was protecting against.

The Question to Ask Before Every Meeting

The fix isn't a better chart. It's a smaller, more specific habit: before a stakeholder conversation, decide out loud (even just to yourself) what this specific meeting needs from this specific person. Not who they are in general. What you need from them today.

There's a related point in the research on requirements elicitation: stakeholders get treated as the default source of information, but they aren't the only one, and they aren't automatically the most reliable one either. That's a narrower claim than the one I'm making here: it's about stakeholders as a category, not about a single stakeholder's role changing from one conversation to the next. But it points at the same underlying mistake: treating "stakeholder" as one fixed relationship instead of asking, case by case, what this person is for right now. What they can usefully tell you, and what they're there to decide, depends on the situation you're in with them at that moment, not on a label assigned to them once and left alone.

That reframes the whole exercise. A stakeholder map, if you keep one at all, becomes a starting point for who's in the room, not an instruction for how to run the meeting once they're there. The second question, the one that determines whether the next ninety minutes work, gets asked fresh, every time.

I've started asking it out loud in planning now: "are we here to learn something, or to get a yes." It feels almost too small to matter. It isn't. The map was never a wrong picture of the customer. It was accurate the whole time. It couldn't tell me, walking into that room, which conversation I was about to have. That turned out to be the only thing that mattered. Nobody redraws a quadrant chart in the thirty seconds before a meeting starts. But anyone can ask one sentence out loud before walking in.

The people you know best are exactly where this breaks down first. You stop asking the question because you feel like you already know the answer. That's precisely where it gets expensive: nobody double-checks a mismatch with someone they trust, so it ships as a decision nobody made.

Further Reading

Requirements Engineering for modern Software-Teams

This article looks at one blind spot in how teams read stakeholders. This course covers requirements engineering from the ground up.

View the course