What do stakeholders want in a project update?

They want answers to a small set of decision-relevant questions: is the project on track, will it hit the date, is anything at risk, is anything needed from them, and how worried should they be. They generally do not want a task-by-task account of what the team did — that's activity, not answers.

Why don't stakeholders read the status reports I send?

Usually because the report answers 'what did we do this week?' when the stakeholder is asking 'is this okay and do I need to act?' A list of completed tasks makes the reader do the interpretation themselves, so they skim it, stay unsure, and follow up with a direct question anyway.

How much detail should a stakeholder update include?

Enough to answer the five questions and no more. Lead with the verdict, give a sentence of why, flag anything at risk or needed from them, and stop. Detail is available on request; the update's job is to convey status and prompt any decisions, not to prove how much work happened.

What non-technical stakeholders actually want to know about a project

You send a thorough weekly update. It lists everything the team accomplished, neatly organized, genuinely accurate. And the stakeholder reads it, nods, and then asks you — out loud, in the next meeting — "So how are we doing overall?"

It's tempting to be annoyed. You just told them. But you didn't, and the gap between what you sent and what they asked is the whole subject of this article. It's also, not coincidentally, the same gap Atlassian's own Atlas product was built to close — see how Atlassian's Atlas migration left a gap for that history.

The five questions in their head

A non-technical stakeholder — a client, an executive, a sponsor — is not reading your update to learn what the team did. They're reading it to answer the questions quietly running in their head, and there are only about five:

Is it on track?
Will it be done when you said it would?
Is anything going wrong?
Do you need anything from me?
Should I be worried?

That's the entire agenda. Notice that a list of completed tasks answers none of them directly. "We finished the auth refactor and closed 14 tickets" is an input to those answers, but it's not an answer. You've handed the reader raw material and silently asked them to do the analysis — and they can't, because they don't know whether 14 tickets is good, or whether the auth refactor was the scary part or the easy part.

Activity is not status

This is the core mistake, and almost everyone makes it: reporting activity ("here's what happened") when the reader wants status ("here's what it means").

Activity is easy to report because it's just a record of what occurred. Status is harder because it requires you to make a judgment — to look at the activity and say "and therefore, we're on track" or "and therefore, the launch date is now at risk." That judgment is exactly the value the stakeholder can't produce themselves and is relying on you for. When you report only activity, you've done the easy 90% and skipped the 10% that was the actual point.

The tell is the follow-up question. Every "so how's it going?" after a detailed report is the reader telling you the report didn't contain the answer, only the ingredients.

Report to the questions

The fix is to write the update as answers to the five questions, in that order, with the interpretation you're uniquely positioned to give:

Lead with the verdict. On track / at risk / off track. One word does more work than a page of tasks.
Give one sentence of why. "On track — the integration work landed on schedule and nothing is blocked."
Name what's at risk, honestly. If the date is slipping, say so here, plainly. Stakeholders forgive bad news delivered early far more than good news that turns out to be wrong.
State what you need from them. A decision, an approval, an intro. Most stakeholders genuinely want to help and don't know how; tell them.
Calibrate the worry. Implicitly or explicitly, answer "should I be worried?" A reader who can't tell will default to yes, and now you have an anxious stakeholder for no reason.

The completed-task detail can still exist — as an appendix, a link, a "details on request." But it's not the update. The update is the five answers. (For exactly how to phrase that update, line by line, see writing a status update people actually read.)

Why this feels wrong to do

The reason people over-report activity isn't laziness — it's the opposite. A long list of accomplishments feels like proof of work. Leading with a one-word verdict feels almost insultingly thin, like you're not showing your labor. There's an instinct that says if I just say "on track," they'll think I'm not doing anything.

But that's your anxiety, not their need. The stakeholder isn't auditing your effort; they're trying to make decisions and manage their own worry. A confident, clear verdict signals competence more than a wall of tasks, because it says you understand the project well enough to summarize it. The detailed list says "here's everything, you figure out what it means" — which is the opposite of reassuring.

Answer the five questions. Lead with the verdict. Let the detail wait to be asked for. Do that, and the "so how's it going?" question stops coming — because you finally answered it.

I'm Andrey. I write about the unglamorous parts of running projects and keeping the people around them informed.