Project Updates Stakeholders Read, and Stop DMing You About

The short version

Stakeholders send direct messages after reading your update because the update answered your questions, not theirs.
Lead with the change and the ask. Most updates lead with activity, which is the part nobody needed.
Five lines beats a page: status, change since last time, risk, decision needed, and what happens next.
The follow-up questions are inevitable and specific. The update has to be askable, not just well written.

A good project update takes ten minutes to write and prevents an hour of questions. A bad one takes forty minutes and prevents none, because the questions it triggers were never the ones it was written to answer.

"I write the update and they ask me the same thing in DM."

Why the direct message always comes

Two reasons, and they compound.

First, most updates are written from the inside out. They describe what the team did, in the order it happened, because that is how the writer experienced the week. The stakeholder does not care what was done; they care what changed, what it means for their commitments, and what they now have to do. An update that leads with activity forces them to extract those three things themselves, and rather than do that, they ask.

Second, the stakeholder's question is nearly always more specific than any update would be. Not "how is the project", but "will the export be in the March release, because I have told a customer it will". No general update answers that. So the direct message is not a failure of the update, it is the predictable consequence of a broadcast meeting an individual need.

The five-line update

Line	What goes in it
Status	On plan, at risk, or slipping. One word, then the date you are aiming at
Change	What is different since the last update. If nothing, say nothing changed
Risk	The one thing most likely to move the date, and who owns it
Decision needed	What you need from the reader, from whom, by when. Or: nothing
Next	What the team is doing between now and the next update

The status word goes first, always, and it has to be honest. An update that says on plan for five weeks and then says slipping has burned the credibility of the whole format. Stakeholders who trust the status word stop reading the rest, which is the goal.

A worked example

Status. At risk for the 12 March release.

Change. The payment provider moved their sandbox cutover to 2 March, which compresses our integration testing from two weeks to four days.

Risk. If testing finds a mapping issue we have no slack. Owned by Priya.

Decision needed. Either we ship without the CSV export and add it in April, or we move the release to 19 March. Marc decides, by Friday.

Next. Integration tests written this week so they run the day the sandbox opens.

Five lines, under a hundred words, and a stakeholder can act on it. Compare that with the common alternative: three paragraphs about what the team worked on, with the sandbox date mentioned in the second paragraph and the decision implied but never asked for.

What happens after the template

Even a perfect five-line update generates follow-up questions, because a broadcast cannot anticipate each reader's specific commitment. That is not a flaw to be designed out, and the question is only where those questions land.

Right now they land on you, one at a time, often outside your hours, and often asking something you already wrote down. The fix is to make the update askable. With StandIn, the update is a brief: the same content, confirmed in ninety seconds, mostly pre-drafted from work that already happened. While you are off, your StandIn answers questions from it, in your words, with a source under every answer. The stakeholder who wants to know about the CSV export asks and gets what you wrote about the CSV export, at whatever hour they thought of it. If the answer is not in the brief, it says so and names who to ask.

The update stays short and the follow-ups stop arriving as interruptions. For a project rather than a person, the same shape applies at the project level, which is covered in project status reports executives read. See also how StandIn works.

Cadence and audience

Weekly is right for most projects. Fortnightly invites a lot of "any news?" messages in between, and twice a week means you will be reporting activity rather than change, which is how updates become filler.

On audience, write one update for everyone rather than a tailored version per stakeholder. Tailoring is how updates grow to a page and how inconsistencies appear between what two people were told. If a stakeholder genuinely needs something the shared update does not carry, that is a five-minute conversation, not a second document.

One exception worth making: always send the update at the same time on the same day. Predictability does more for stakeholder confidence than length or polish, because it removes the need to wonder whether something is being withheld.

Common Questions

How long should a project update be?

Under a hundred words in five lines: status, change, risk, decision needed, next. Longer updates get skimmed, and skimming defeats the purpose, since the reader then asks you the thing you wrote in paragraph three.

Should I report activity or outcomes?

Change, which is neither. Activity is what your team did and outcomes are what shipped. What a stakeholder needs is what is different since they last looked, especially anything affecting a date or a commitment they have made.

What if the status is bad and I do not want to say it?

Say it early and say it plainly. The cost of a late "at risk" is far higher than the cost of an early one, because by the time it is undeniable the stakeholder has lost their options. An honest status word is the entire value of the format.

How do I stop stakeholders asking things the update already answered?

Make the update retrievable rather than only sent. A one-off message is gone from a stakeholder's view within a day, so the answer needs to be somewhere they can ask again without asking you.