How to Write a Weekly Product Update (Template + Examples)

Q: How long should a weekly product update be?

Long enough to be scanned in under two minutes. In practice that is 200-500 words of prose over a structured list. Length should scale with what shipped, not with how much time the author had.

A repeatable process for writing a weekly product update: what to include, how to structure it by product and category, and how to stop rewriting it from scratch every Friday.

Soobrief Team — Product & Engineering, Sooapps · 2026-08-12

In short

A weekly product update should be assembled, not composed. Pull the work that actually completed in the window, group it by product and category using fixed rules, then write prose only on top of that structure. The structure answers 'what shipped'; the prose answers 'why it matters'. Teams that separate the two steps cut writing time from roughly an hour to under ten minutes and stop losing work between updates.

Most weekly product updates fail for the same reason: they are written as an essay when they should be assembled as a record. The author opens a blank document on Friday afternoon, tries to remember what the team did, pings three people for status, and produces something that is both late and incomplete.

The fix is structural. Separate the update into two operations that have nothing to do with each other:

Collection and grouping — deterministic, rule-based, and repeatable. What completed in this window? Which product and category does each item belong to?
Narration — the part that requires judgment. Why does this work matter to the reader?

When those two steps get mixed, the writing step inherits all the uncertainty of the collection step, which is what makes it take an hour.

What a weekly product update is for

A weekly update has exactly one job: let someone who was not in the room understand what changed, in under two minutes, without asking a follow-up question.

That reader is usually one of three people, and they want different things from the same document:

Reader	What they need	What they skip
Leadership	Direction and pace — is the team moving on the right things?	Ticket IDs, implementation detail
Adjacent teams	Anything that affects their surface or unblocks their work	Internal refactors with no external effect
The team itself	A durable record of what was finished and when	The summary prose they already lived through

A single well-structured document serves all three, because structure lets each reader skip to their layer. Prose alone does not — an unstructured paragraph forces every reader to read every word to find out whether any of it applies to them.

The template


# Weekly Update — [Team] — [Start] to [End]

[2-4 sentences: the through-line of the week. What is the story
of this week's work, not a restatement of the list below.]

## [Product Area]

### [Category]
— [Completed item, phrased as an outcome]
— [Completed item, phrased as an outcome]

### [Category]
— [Completed item]

## [Another Product Area]

### [Category]
— [Completed item]

## Carried over
— [In-progress item] — [one-line reason]

Three properties of this template matter more than its exact shape:

The summary sits at the top, not the bottom. Readers who bounce after two sentences should still leave with the correct impression of the week. Burying the synthesis under the list guarantees most readers never reach it.

Grouping is by product and category, not by person or by ticket type. Nobody outside the team cares which engineer closed which ticket. They care what changed in the product. Grouping by person also quietly turns the update into a performance review, which changes how people report their work.

Items are phrased as outcomes. "Fixed the invite flow so members can be added without an owner present" beats "PROJ-4412: invite bug." The ticket title was written for the person doing the work; the update is read by someone who has no context at all.

Writing the prose layer

Once the structure exists, the prose is a small job with a clear brief. Answer three questions in two to four sentences:

What is the through-line? Most weeks have one — a theme the work clusters around.
What should the reader do or know differently as a result?
What is deliberately not in this update, if a reader might expect it?

That third question is the one most updates skip, and it is the one that prevents the "wait, what happened to X?" reply. If a major initiative saw no movement this week, one sentence saying so is worth more than the rest of the document.

Resist the urge to restate the list in paragraph form. If the prose can be deleted without losing information, it was restating the list.

Common failure modes

Writing from memory. Memory is biased toward the most recent and the most painful work. The Tuesday fix that took ten minutes and unblocked another team disappears; the Thursday incident dominates. Working from a completed-work list corrects this automatically.

Chasing status. If gathering the update requires messaging people, it will always be late and it will always tax the people being asked. The completed work is already recorded in the tracker — the update should read from that record, not re-collect it from humans.

Inconsistent structure week to week. Readers learn where to look. If the sections move every week, every reader pays the scanning cost again. Fixed grouping rules produce fixed structure, which is why the grouping step should not involve judgment at all.

Letting a language model decide the structure. A model asked to both organize and narrate will produce a different organization each run, from identical input. That is fine for a first draft and disqualifying for a weekly record — two consecutive updates become impossible to compare. Structure should be deterministic; only the prose should be generated.

Making it repeatable

The process above still costs real time if every step is manual. What makes it sustainable is that most of it is mechanical:

Completed work already lives in Trello, Jira, or your tracker of choice, with completion timestamps.
Product and category can be derived from board, list, label, or component — a fixed mapping, not a decision.
The time window is just a date range.

Everything up to the prose layer can be assembled without a human. That is precisely what Soobrief does: it reads completed tasks from your source, groups them by product and category with deterministic rules that produce identical structure from identical input, and hands a language model an already-organized document to narrate. The model never chooses the grouping, so the same week always renders the same shape — and the human keeps the final edit.

The result is not that nobody writes the update. It is that the person writing it starts from an accurate, organized draft instead of a blank page and a vague memory of Tuesday.

Frequently asked questions

What should a weekly product update include? Four things: the time window it covers, the completed work grouped by product and category, a short prose summary of why the work matters, and anything blocked or carried over. Anything else is optional.

How long should a weekly product update be? Long enough to be scanned in under two minutes — in practice 200-500 words of prose over a structured list. Length should scale with what shipped, not with how much time the author had.

Who should write the weekly product update? One accountable owner, usually a product manager or team lead, working from a structured list rather than from memory or from individual status replies.

Should a weekly update include work that is still in progress? Only as a short, clearly separated carry-over section. Mixing in-progress work into the shipped list is the fastest way to lose the reader's trust in the document.