Stakeholder Updates and Hard Conversations

The same news, five audiences

A single change of plan might need to reach an engineering team, a sales director, a head of support, a customer success lead and an executive sponsor. Each cares about something different. Engineers want to know what changes in their work. Sales wants to know what to tell prospects. The executive wants the decision, the reason and the risk, in about four sentences.

Rewriting one message for five audiences is exactly the kind of structured, repetitive writing a language model does well. So is turning a messy set of sprint notes into a clear weekly update, or condensing a long decision document into a summary someone will actually read.

The harder half of stakeholder work is the conversations nobody wants to have: the delay, the no, the feature that is being cut. Here the tool is still useful, but for preparation rather than delivery. This lesson covers both halves, and ends with the part of the course that matters most: where using AI at all is the wrong choice.

Routine updates: draft from facts, not from vibes

The failure mode for updates is familiar by now. Give the model a vague prompt and it will produce a confident, upbeat status report with progress that sounds plausible and may not match reality. It pads, it reassures, and it rounds "we are not sure" up to "on track".

Give it the facts instead: what shipped, what slipped and why, what is blocked and who can unblock it, what decision you need. Ask for a version per audience with a hard length limit and a rule that nothing appears in the update unless it appears in your notes. Then read it once for tone. Models soften bad news by default, and an update that buries the one thing a stakeholder needed to know has failed however well it reads.

Hard conversations: prepare and rehearse

When you have to tell a senior stakeholder their priority is not happening this quarter, the preparation is where AI earns its place. Three uses stand out.

Find the holes in your reasoning before they do. Paste your explanation and ask for the five questions a sceptical listener would ask, ordered by how hard they are to answer. If one of them stumps you, better now than in the room.

Rehearse the specific person. Describe the stakeholder concretely: their goals, what they have been promised, what they are measured on, how they reacted last time. Then ask the model to respond as them. The more specific the description, the less it defaults to a generic sceptic. The design course has a short version of this for design reviews in AI for UX and Product Design. For product managers it is worth going further and practising several rounds.

Draft the written follow-up. After the conversation, a clear written record of what was decided and why protects everyone. That is ideal drafting work.

I need to tell a stakeholder something they will not like. Help me
prepare. Do not help me soften the message until it is unclear.
The message: [the decision, in one or two plain sentences]
Why: [the real reasons, including the uncomfortable ones]
The stakeholder: [role, what they are measured on, what they were
promised, how they reacted to similar news before]
What I can offer: [alternatives, timelines, partial options]
What I cannot offer: [things that are not negotiable]

List the ten objections or questions they are most likely to raise,
hardest first.
For each, tell me whether my reasons above actually answer it, or
whether I have a gap.
Now play the stakeholder. Respond to my opening in their voice. Stay
in role and push back realistically until I say stop. Do not concede
easily.

Remember that the rehearsal partner is a simulation built from your description. It can make you sharper. It cannot tell you how the real person will react, and it will not know the history you left out.

Deliver bad news yourself

Having prepared with the model, do not let it do the delivering. A message saying a customer's requested feature is cancelled, a partner's integration is delayed, or a colleague's project is being stopped should be written by you and, wherever possible, said by you first in a conversation.

This is not sentimentality. People can tell when a hard message has been generated: it is too even, too complete, too careful to be sorry in exactly the right places. Receiving bad news through something that reads like a template tells the recipient you did not think they were worth your own words. Trust spent that way is slow to earn back.

When AI is the wrong choice

Some things should not go near the tool at all.

The decision itself. It can prepare you to make a call and to explain it. It should not make it, and "the analysis suggested" is not a defence when the call goes wrong.

Confidential company material. Unannounced plans, financials, acquisition discussions, people matters, anything under a confidentiality agreement. Check your organisation's policy on which tools are approved, and if there is no policy, ask before you paste.

Customer data without approval. Feedback, tickets and call notes often contain names, contact details and account information. Remove what you do not need, and do not paste customer data into any tool your organisation has not approved for that purpose. What customers agreed to when they shared it is the boundary, not what would be convenient.