How to use AI for stakeholder updates people actually read

What is a weekly update for?

Changing what somebody does. That is the test, and most updates fail it. A reader finishes a good update knowing one thing they did not know, or holding one decision they now have to make. A reader finishes a status log knowing that several workstreams remain in progress, which is what they assumed when they opened it.

So the shape follows from the purpose: what changed, what it means for the date or the scope, what you need from the reader and by when, what happens next. Four beats. A model will produce all four from raw notes in about a minute, and it will produce them in a format that is complete, balanced and slightly too long.

Give it the last three updates, not just this week's notes

The single change that most improves a generated update is history. Hand over the previous three alongside this week's tickets, metrics and notes, and instruct it to report only what changed since the most recent one.

Without that, a model re-reports. The payments integration is still in progress, the migration is still on track, the hiring is still ongoing, week after week, because each of those is true and the model has no way to know that saying it again costs you the reader's attention. Three or four repeated weeks is all it takes for somebody to learn that your update contains nothing new, and they stop reading it properly long before they stop receiving it.

The second instruction worth giving up front: mark anything it inferred rather than found in the input. A model asked to summarise a messy week will smooth the gaps, and the smoothing reads exactly like the parts that are true.

The first edit: cut the workstream that did not move

A generated update covers everything you gave it, because coverage is what completeness means to a model. Your reader does not want coverage. If a workstream did not move this week, it does not get a paragraph; it gets a line in a list at the bottom, or nothing.

This is uncomfortable to do by hand because a shorter update feels like a smaller week. It reads as the opposite. An update that reports three things with consequences attached reads as a team that knows what matters, and an update that reports nine things in identical hedged sentences reads as a team that does not.

A useful rule: every paragraph in the body has to end with a consequence. If you cannot write "which means the date moves to the 14th" or "which means we need a decision on scope by Friday" after a paragraph, the paragraph belongs in the list at the bottom.

The second edit: name the decision and the date

Models write requests as descriptions of a situation. "We are currently evaluating two approaches to the integration and would welcome input from the team." Nobody has been asked to do anything, so nobody does anything, and next week the same sentence appears with a week added to the delay.

Replace it with the specific ask: who decides, what the options are, what happens by default if nobody decides, and when. "We need a call on whether the integration ships with the beta or waits for general availability. Default if I hear nothing by Thursday is waiting, which moves the launch by two weeks." That version is uncomfortable to write and impossible to ignore, which is the whole point of writing it.

• Who is being asked, by name rather than by team.
• The default that happens if nobody answers, stated plainly.
• The date the default takes effect.

The third edit: put the bad news first

Given a week with two wins and a slip, a model produces a balanced paragraph with the slip in the middle, hedged with a clause about mitigation. That ordering is wrong for the same reason it feels right: the slip is the only item in the update that changes what the reader does today.

Lead with it. "The migration slipped two weeks; here is why and here is what it costs." A reader who learns about a two-week slip in paragraph four learns two things, and the second one is that your updates need to be read carefully rather than trusted. That lesson is expensive and hard to reverse.

Hedging deserves its own pass. A model hedges by default because hedged prose is safer prose, and "we anticipate some potential impact to the timeline" is a sentence that tells nobody anything. Rewrite each hedge as either a number or an admission that you do not have one: the date moves to the 14th, or we will know the new date on Thursday. Both are answers. The hedge is not.

Does the audience change the draft?

Yes, and it is the one instruction people leave out. An update written for your engineering leads and an update written for a commercial director are different documents with the same facts in them, because the two readers act on different things. The lead needs the sequencing and the dependency. The director needs the date and the revenue consequence of the date.

Name the reader in the prompt and name what they control. "This goes to the commercial director, who owns the launch date commitment to three enterprise customers" produces a draft organised around the date. "This goes to the two engineering leads sharing the platform team" produces one organised around sequencing and contention. Left unspecified, a model writes for a generic senior stakeholder, which is a reader who does not exist and therefore acts on nothing.

The practical version for most teams is two drafts from the same input rather than one draft sent twice. It costs a second prompt and it stops the familiar failure where a leadership update is skimmed because half of it is about a dependency the reader cannot influence.

What this is not

It is not a decision-making tool. A model has no view on whether the trade-off you are describing is the right one, and asking it to recommend produces a confident paragraph assembled from the shape of the arguments rather than from knowledge of your business.

It is also not a substitute for the conversation. An update lands a decision that has already been socialised; it does not create consensus on its own, and a surprise arriving by email in week nine is a management failure the writing cannot fix. Builders Camp's Product Storytelling bootcamp covers the craft side over 1 week with 2 live sessions and 7 microlessons, building narratives that align teams and influence stakeholders. Head of Product covers the level above, direction, stakeholders, teams and the hard calls, across 2 weeks with 4 live sessions and 8 microlessons, and both sit inside the Product Leadership Track, which sequences vision, strategy, stakeholder management and operating cadence.

For the adjacent documents, writing a one-pager with AI covers the format for a decision that needs more than a paragraph, and AI release notes covers the outward-facing sibling of this update. The wider practice is defined in stakeholder management, and the numbers half of an update is covered in data storytelling.

Where the time actually goes

Drafting takes a minute and the three edits take four, which inverts how most people spend the half hour they give this. If the format is worth more investment than that, Amazon's 2017 shareholder letter is honest about the cost: it describes replacing slide presentations with narratively structured six-page memos, and states that a high-standards memo takes a week or more rather than the day or two people assume. A weekly update is not that document, and treating it as one is how it stops going out.

See the Product Storytelling bootcamp

One check worth running in a month: open the last four updates and count how many contained a request with a name and a date on it. If the answer is fewer than two, the updates are a log, and the fix is not a better draft.