Topic 12 — Stakeholder management and communication

Goal: Learn to influence and align people when you have no authority over them.

Lesson 12.1 — The meeting where everyone wants something different

Maya is six months into her job at Lumi, the budgeting app. On Tuesday she's in a small room with three people, and all three want the next two weeks of engineering time.

Dan from sales wants the Excel export feature, because a big customer keeps asking and might walk without it. Sam, the senior engineer, wants those two weeks to fix the loading screen that's been crawling for months. Priya, the designer, points at user research showing people abandon sign-up before they ever see either thing. Everyone is right. Everyone disagrees.

Each of these people is a stakeholder — anyone with an interest in the product or a stake in a decision. Maya's full list is longer than the three in the room: executives, engineering, design, marketing, sales, customer support, finance, legal, and the users themselves. They care about different things, and they routinely want conflicting things. Sales wants the big-customer feature now. Engineering wants time to fix the foundations. The user wants it simple and free.

So whose job is it to untangle that? Maya's. The PM is the one who hears all the voices, weighs them, makes the call, and keeps everyone moving in the same direction afterward.

A useful first move is to map your stakeholders by two things: how much they care about a decision, and how much sway they have over it. The people high on both — Sam can block the work, Dan owns the customer relationship — you engage closely and early. The people who just need to know what happened, you keep informed and don't drown in detail.

Maya can't make all three of them happy. No PM can. What she can do is make every one of them feel heard and informed, and most of the time, that's most of the battle.

Lesson 12.2 — How do you lead people who don't report to you?

Sam has been an engineer for eight years. Dan has closed more deals than Maya has had jobs. Neither of them works for her, and she can't tell either of them what to do.

Back in Topic 1 we said a PM usually has no authority to give orders. This is where that bites. So how does she get a room of people, several more senior than her, to commit to one plan? Not by pulling rank she doesn't have. Through influence, which she builds on four habits.

She communicates the why. When Maya picks the loading-screen fix, she doesn't say "because I decided." She connects it to the goal: users are quitting, and a faster app keeps them. People follow a decision they understand.

She brings data and user evidence. "Here's what the numbers show" and "here's what twelve users told Priya" move Sam far more than "I have a feeling." (We built that muscle in Topics 5 and 9.)

She builds relationships before she needs them. The week she grabbed coffee with Sam and actually listened to his gripes about tech debt is the week that pays off now, when she needs his trust. The PM who only appears to make demands gets nothing. The one people like and respect gets the benefit of the doubt.

And she listens for real. The fastest way to win Dan over is rarely to out-argue him. It's to understand the customer pressure he's under so completely that he can tell she gets it.

Influence is slower than authority. It's also more durable, and it's a skill anyone can build, whatever they did before this. This is the through-line of the entire job.

Lesson 12.3 — Say the point first

Maya's first big update to the team was a wall of text. Three paragraphs of background, then the decision buried at the bottom. The CEO replied with one line: "What are you actually asking me to do?"

Most of Maya's influence travels through one channel: clear communication. A few habits make it land.

Lead with the point. Conclusion first, reasoning after. Busy people shouldn't have to dig for the thing you need them to know. This even has a name in some teams: BLUF, bottom line up front.

Write things down. A short note on a decision — what, why, who it affects — kills the "wait, I thought we agreed on something else" problem two weeks later. And a written summary scales in a way that hallway conversations never will.

Be concise. A tight message gets read. A rambling one gets skimmed and forgotten.

Close the loop. When someone gives you input, tell them what happened to it. Silence makes people anxious and quietly chips away at trust.

A PM is, in large part, a professional communicator. Clear writing is how the work gets done.

Lesson 12.4 — The same decision, said five ways

Maya makes her call: fix the loading screen first, Excel export next sprint. Now she has to tell people. And if she sends the exact same message to the CEO, to Sam, and to Dan, she'll lose most of them.

Different audiences care about different things, so the same decision gets framed differently for each.

Audience	What they want to hear
Executives	The outcome, the trade-off, and the risks — in about 30 seconds, not the implementation detail
Engineers	The precise requirement and the reasoning behind it
Sales and support	What changes for customers, and when
Users	Plain language about what's in it for them

The CEO doesn't want the ticket breakdown. Sam doesn't want a vague vision statement, he wants the exact scope. Dan needs a date he can repeat to a customer. A user just wants to know the app will stop being slow.

This is not being two-faced, and it's worth being clear on that, because it can feel that way at first. The facts don't change between versions. Only the emphasis and the level of detail change. Tailoring is what makes a message actually reach the person you're talking to.

Lesson 12.5 — Tell people bad news early

If Maya takes one habit from this whole topic, make it this one: manage expectations early and honestly.

Two weeks in, the loading-screen fix is running long. It'll slip. Maya feels the very natural pull to wait — maybe Sam catches up, maybe she never has to send the awkward message.

That instinct is the trap.

Picture Dan finding out about the slip on the day he'd promised the customer it would be done. He's blindsided, in front of his customer, by something Maya knew about for a week. Now picture Dan hearing it two weeks early, with a reason and a new date he can pass along. Same delay. In the first version Maya looks careless. In the second she's still a partner. The difference is entirely about timing.

Surprises destroy trust. Early heads-ups, with a reason and a plan, protect it.

The same logic runs through under-promising and over-delivering instead of the reverse. The PM who's consistently straight about what's realistic — even when it isn't what people hoped — becomes the one leadership actually trusts when the stakes are high.

A PM's real superpower is turning a messy tangle of opinions into a clear, shared direction that everyone understands and trusts.

Worked example — One decision, four audiences

Maya has decided to delay a flashy new feature by one sprint to fix a reliability problem that's been hurting existing customers. The decision is made. The job now is telling four very different groups without blindsiding any of them.

To the executives, she leads with the bottom line and the trade-off. "We're delaying Feature X by a sprint to fix reliability. The churn risk from outages outweighs the new feature's upside — here's the data." Thirty seconds, outcome and risk, done.

To the engineers, she gives the precise scope and the why, so Sam knows exactly what's in and what isn't, and why it jumped the queue.

To sales, who had already promised Feature X to a prospect, she breaks the news early. She explains the reasoning and hands Dan a revised date he can take back to the customer himself, so he's never caught flat-footed.

To users, support posts a short, plain-language note about improved reliability. No internal drama, just what's getting better for them.

One decision. Four tailored messages. All delivered early. Nobody is surprised, and everyone stays pointed in the same direction. That's stakeholder management.