Stop Treating Every Objection the Same. Start Asking Who It's For.

Strategic Stakeholder Engagement means sorting an objection before you decide to act on it. The first sort is whether the person raising it is who the deliverable was built for.

Stop Treating Every Objection the Same. Start Asking Who It's For.
Photo by sydney Rae / Unsplash

 Not every "this doesn't work" carries the same weight. Here's the filter.


You spend two hours building a stakeholder dashboard the week before a steering committee meeting. You show it to your sponsor. She skims it, frowns, and says, "This doesn't work."

Twenty minutes later, a director who's cc'd on every project update but has never once opened the dashboard glances at your laptop and says the exact same thing: "This doesn't work."

Same four words. Wildly different information.

Here's the problem: most PMs don't have a way to tell which one is a warning and which one is an opinion from someone standing outside the thing they're looking at. So both land with the same weight. Both trigger the same afternoon of revisions.

The Principle: Strategic Stakeholder Engagement

Strategic Stakeholder Engagement means sorting an objection before you decide to act on it. The first sort is whether the person raising it is who the deliverable was built for.

"We revised the dashboard because someone said it didn't work" → "We revised the dashboard because the sponsor who reads it every week said it didn't work."

"We rewrote the plan to satisfy every comment in the thread" → "We rewrote the plan to satisfy the two stakeholders whose sign-off the project depends on."

Most PMs default to the first version of each pair. The words "this doesn't work" sound identical no matter who says them, and disagreeing with a stakeholder feels risky. So every critic, core or peripheral, gets the same veto power over your plan.

Task-trackers treat every objection as equally binding, because sorting takes a judgment call nobody trained them for. Strategic PMs treat it as one more assumption to test, the same discipline behind the Four Pillars of Project Clarity: name who the deliverable serves before someone in the room decides for you.

Two Kinds of "Doesn't Work"

Seth Godin draws a distinction worth stealing for this exact problem. A watch that doesn't tell time fails in the engineering sense: there's a spec, and it's either met or it isn't. A joke that "didn't work" is a different kind of failure. The room might have been roaring. The person telling you it flopped is telling you it didn't land for them.

Creative and cultural work doesn't have one universal spec the way a watch does. Godin's fix is this filter: "it's not for you." It sorts objections into two piles. From the audience you're building for, "this doesn't work" is a signal — something needs fixing. From everyone else, it's accurate targeting.

Your dashboard, your plan, your status deck: none of them have a watch's spec either. They work for the sponsor who has to make a call based on what's in front of her, or they don't. Whether a peripheral director likes the layout was never the test.

The AI Advantage

Thinking: Use AI to reason across your stakeholder notes and classify who's the intended audience for a given deliverable, versus who's an interested bystander. Do this before the meeting, not while you're absorbing live feedback and trying to sort it in your head under pressure.

Communicating: Use AI to draft two different responses to the same complaint. One digs deeper, because it came from inside the circle. One acknowledges and closes the loop, because it didn't. Same input feedback, two entirely different outputs — because the source, not the wording, decides which response fits.

This Week's Prompt

Use this to sort your next piece of "this doesn't work" feedback:

Copy/paste this into ChatGPT or Claude:

WHO: Act as a stakeholder feedback strategist with expertise in audience prioritization and stakeholder salience 

WHY: because I need to know whether a piece of feedback is a signal I should act on or a peripheral opinion I should log and move past 

WHAT: review the feedback and my stakeholder context below and:

Identify who is the intended audience for this deliverable, based on my stakeholder notes

Determine whether the person who raised the objection is inside or outside that audience

If inside: name the most likely specific problem behind their general complaint
If outside: draft a short acknowledgment that closes the loop without triggering a revision 

HOW: provide a one-line verdict (signal or noise), followed by the specific next step for each case 
[Paste the feedback, who said it, and your stakeholder notes or map here]

What this reveals: whether you're about to spend your afternoon on a real gap or on someone else's taste.

This Week's Challenge

Before: you revise your plan, dashboard, or deck the moment anyone in the room says "this doesn't work." After: before you touch anything, you ask one question — "Is this person who this was built for?"

If yes, dig in. Ask a follow-up question. Find the specific gap behind the general complaint. If no, thank them, log it, and leave the deliverable alone. That one question is the entire difference between being led by the loudest objection in the room and being led by the people whose judgment the deliverable answers to. Try it on the next piece of feedback you get, before you decide whether to change anything.

Get Intentional,

Paul

Subscribe to The Intentional Project Manager

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.
jamie@example.com
Subscribe