How to Write a Project Update That a Client Can Understand in Two Minutes
Most project updates answer "what did we do this week" when the client only wants to know one thing: do I need to do anything right now. Here is the structure that answers that, and the one that doesn't.
I have sent hundreds of client updates. For the first few years I wrote them the way most agency people do: a list of what we did this week, in the order we did it. Built the nav. Fixed the form bug. Had a call with the vendor. Started on the pricing page. It felt like progress because it was progress. It was also, from the client's chair, almost useless.
The client opening that email is not trying to understand your week. They are trying to answer one question in the time it takes to read it: do I need to do anything right now? If the update doesn't answer that in the first two lines, you've made them read the whole thing to find out — or worse, they skim it, miss the one line that needed a reply, and you find out three days later in a tone that suggests they think you buried it on purpose.
The question under every update
Clients don't actually want visibility into your process. They want to know whether this is one of the weeks where they can close the email, or one of the weeks where they need to make a call before Friday. A good update sorts itself into one of those two piles before the client has finished the first sentence.
That sorting is the whole job. Everything else — the activity list, the Slack-style play-by-play, the screenshots of a Figma board mid-edit — is you narrating your own competence to someone who already hired you and doesn't need convincing. Worse, it trains the client to skim, and a skimmed update is how a decision you needed gets missed.
A structure that answers it
Five lines, in this order. If a line has nothing to say, cut it rather than pad it.
- Outcome — what is true now that wasn't true last update, in the client's terms, not yours.
- Evidence — the one proof point that makes the outcome credible: a number, a link, a screenshot, a test result.
- Current risk — the thing that could slow this down, named plainly, even if it's not resolved yet.
- Decision needed — the specific choice only the client can make, or "none" if there isn't one.
- Next milestone — the next date they should expect to hear from you, and what they'll see then.
Notice what isn't in there: a list of tasks completed, internal tool names, who was on which call, or how hard the week was. None of that helps the client decide anything. It helps you feel like you documented your effort, which is a different goal and usually the wrong one for this document.
What it looks like when it's wrong
Here's a version I would have sent five years ago, lightly disguised:
“Hi team — busy week. We completed the sprint planning for the checkout flow, synced with the design team on the modal states, pushed three PRs to staging, and had a good call with your ops lead about the return policy edge cases. QA found a couple of issues we're tracking in the board. Let us know if you have questions!”
Read that again as the client. What changed? Is it on track? Do they owe you anything? You genuinely cannot tell. "A couple of issues we're tracking" could mean a typo or a launch blocker, and the client has no way to know which, so either they ignore it and it was serious, or they ask you to clarify and you've both spent a round trip getting to information the first email should have carried.
The same week, rewritten
Same work, same week, different document:
“Checkout flow is functionally complete and in staging — you can test it here: [link]. QA flagged one issue: returns on partial refunds don't yet match your current policy, which we need your ops lead to confirm before we can close it. No other open risks. Next update Thursday, when we expect sign-off on returns and a go/no-go for next week's launch.”
That version is shorter and says more. The client knows the outcome (checkout is functionally done), has evidence they can click on, knows the one risk by name, knows exactly what decision is theirs to make, and knows when to expect the next thing. If they're busy, they can act on one sentence — confirm the returns policy — and ignore the rest without guilt, because the rest genuinely doesn't need them.
Why agencies default to the long version anyway
The activity-list update is easier to write under deadline pressure, because you can generate it by copying your own task tracker. It also does something subtler: it reassures the writer. If the client can see how much you did, the thinking goes, they'll trust that the engagement is worth the invoice. But a client who has to infer value from volume of activity is a client who hasn't been told what matters, and eventually asks "is this on track?" anyway — which means the long update didn't even do the one job it was trying to do.
The five-line version requires you to actually decide what the outcome, the risk, and the decision are before you write anything. That's a few extra minutes of thinking per update. It is also, not coincidentally, a forcing function for noticing when a project doesn't have a clear outcome yet — which is useful information for you, not just the client.
Where this breaks down without a place to put it
The hard part isn't writing one good update. It's writing the tenth one, three months in, when the project has three workstreams and the client has stopped reading email carefully because nothing in the last four updates required them to act. At that point the structure only works if there's somewhere the client can go between updates to check the current state themselves, instead of waiting for Thursday to find out whether the returns decision got made.
That's a visibility problem, not a writing problem, and it's one reason we built guest access the way we did in Team and Tricks: a client can see the specific projects or tasks you grant them, without you turning every status check into an email thread, and without giving them a paid seat or a login they have to learn. If they want to know what's true right now, they can look. The Thursday update is then free to do what it's actually for — flagging the one thing that needs them, not restating what they could already see.
The template works whether or not you're using anything beyond email. It works because it answers the one question the client is actually asking. Everything past that is either evidence they asked for or activity they didn't.
