Async weekly update template: progress, plans, problems, and who posts it
A copy-paste weekly update template (progress, plans, problems), who writes it, when it goes out, and how it replaces the Monday status meeting.
On this page
A weekly update is a short written post, sent on the same day each week, with three parts: what moved since last week, what is planned for next week, and what is in the way. One person owns each product or area and posts it in one place the whole team reads. Done well, it takes fifteen minutes to write, five to read, and replaces the Monday status meeting entirely.
The template is below, followed by the rules that make it stick: who posts, when, where, and what to do when nobody reads it.
The weekly update template
Copy this into whatever tool your team uses. The square brackets are the only parts you change.
**[Product or area] — week of [date]**
**Status:** On track / At risk / Behind
**Owner:** [name]
**Progress**
- [Shipped or finished item, with a link]
- [Shipped or finished item, with a link]
- [Decision made, with where it was recorded]
**Plans**
- [What will be finished by next update]
- [What will be finished by next update]
- [What will start]
**Problems**
- [Blocker, who can unblock it, by when]
- [Risk that may slip the date, and what would change it]
- None, if that is true
**Numbers**
- [Metric]: [value] (last week [value])
- [Metric]: [value] (last week [value])
**Needs a decision**
- [Question], from [name], by [date]
Six headings, roughly twelve lines, and no paragraph longer than one sentence. Anyone can read it on a phone in a lift.
Why progress, plans, problems works
The format has survived decades because each section answers one question a reader has.
Progress answers "did anything happen?". It should list things that are finished, not things that were worked on. "Worked on checkout" is activity; "Checkout live on 40% of traffic" is progress. Link each item so a reader who wants detail can go and get it without asking.
Plans answers "what should I expect next week?". It is a commitment, so keep it to three items. Next week's Progress section will be read against this week's Plans, and that comparison is where the honesty comes from. If the same plan appears three weeks in a row, the update has surfaced a problem without anyone having to say so.
Problems answers "where do you need me?". This is the section managers read first and writers skip most often. A good problem line names the blocker, the person who can clear it, and a date. "Waiting on legal" is a complaint. "Need contract sign-off from Dana by Thursday or the pilot slips a week" is a request.
The two extra sections, Numbers and Needs a decision, are optional, but they are what make the update worth more than a meeting. Numbers give the week a shape over time. Decisions give readers a reason to reply.
Who posts the weekly update
One owner per product or area, not one per person. A team of eight with three products posts three updates, not eight. Personal updates become a list of tasks, and nobody reads a list of someone else's tasks.
The owner is whoever would be asked "how is it going?" in a meeting. Usually that is the product lead, the engineer carrying the most work, or the founder for anything without a named lead. Rotating the job does not work well; the value of the update comes from one voice tracking one thing across weeks.
Post it whether or not anything happened. A week with "Progress: none, the team was on the conference" is a useful update. A missing week is a hole that the reader fills with worry.
When it goes out
Pick one day and one time and do not move it. Most teams we know post on Friday afternoon, which closes the week while it is fresh, or Monday before 10:00, which sets the week up. Friday updates get read on Monday anyway, so the choice is mostly about when the writer prefers to write.
Set a deadline of about two hours after the posting time for comments. After that, anything that is not resolved in the thread becomes an item in next week's Problems section or a scheduled call between the two people who disagree. Without a cut-off, the thread stays open all week and the update becomes a meeting that never ends.
What replaces the status meeting
A status meeting does four things: it reports progress, surfaces blockers, forces decisions, and lets people hear each other. The written update covers the first two better than a meeting does, because the record stays and nobody has to attend. The other two need their own homes.
| Job of the status meeting | Async replacement | What is lost |
|---|---|---|
| Report progress | Progress section, with links | Nothing; the record is better |
| Surface blockers | Problems section, named person and date | Nothing, if the owner is honest |
| Force decisions | Needs a decision section, plus a 15-minute call only for the ones still open after comments close | Speed, by a day or two |
| Hear from each other | A short, optional weekly call with no status on the agenda | Some of it, for people who like meetings |
The pattern that works is this: cancel the status meeting, keep a 20-minute weekly call that assumes everyone has read the updates, and spend it only on open decisions and on talking. If the call has nothing on it, end it in five minutes. People will notice that the call is now worth attending.
Where to post it
The right place is wherever the people who need it already look, with three tests: it must be searchable later, people must be able to comment under it, and it must not vanish under the day's chat.
Team chat channels fail the third test. A weekly update in a busy channel is scrolled past by lunchtime. If chat is the only tool you have, pin the update or post it in a channel that carries nothing else.
Slack canvases are documents inside Slack that can be pinned to a channel as a tab and commented on. According to Slack's help centre, canvases are available on paid plans; the Pro plan is $8.75 per user per month billed monthly, or $7.25 billed yearly, as of October 2026. A canvas per product, updated each week, keeps the history in one place and sits next to the conversation.
Basecamp automatic check-ins solve the problem from the other direction. You set a question, such as "What did you work on this week?", on a daily, weekly or monthly schedule, and Basecamp asks each person and collects the answers together. Basecamp's Freelancer plan is $29 a month for up to 5 users, Pro is $79 for up to 10, and Pro Plus $99 for up to 15, as of October 2026; the Free plan is capped at 3 users. The check-in model works best for personal updates; for a product-level update with numbers you still want a document. The Basecamp comparison covers the rest of the product.
A project tool with a feed is what we use. In Atrix, each product has a page with its own update stream, and posting an update there also puts it in the workspace feed. Writing somebody's name in an update sends them a notification, including a push to their phone, so we only name a person when the update genuinely needs them, which in practice means the Problems and Needs a decision sections and nothing else. An update that names six people is a meeting invite in disguise. Our team chat stays for the conversation that follows.
For the Numbers section, the figures should come from the tracker rather than from memory. The Atrix MCP server has a project_status tool that returns one product's status figures: percent complete, work by status, what is overdue, what has been stuck in progress or review for more than a week, what is due in the next seven days, and what finished this week. Asking an assistant to "draft this week's update for Checkout from project_status" produces the Progress and Numbers sections in about a minute, and the owner edits rather than writes. It will not write the Problems section for you; the tracker does not know that Dana is on holiday.
How to introduce it in five steps
- Pick the owners and the day. Write them down somewhere public. If a product has no obvious owner, that is the first problem the update will surface.
- Post the first one yourself. The founder or lead writes the first update using the template above, including a real Problems section. The team copies the tone of the first one, so make it honest and short.
- Cancel the status meeting from week two. Not "shorten it". A meeting that still exists is where the updates will quietly move back to.
- Read and reply within the window. The second week, the owner checks whether anyone commented. If nobody did, the lead replies to each update with one question. Updates die from silence, not from effort.
- Review after six weeks. Compare the Plans sections to the Progress sections that followed. If plans were rarely met, the template is doing its job and the planning is the thing to fix.
Common mistakes
- Too long. If the update needs scrolling on a phone, it is a report, not an update. Move detail into linked pages.
- No problems for a month. No team has zero problems for four weeks. An empty Problems section usually means the owner is nervous about writing them down. Ask for one problem a week until it feels normal.
- Activity instead of outcomes. "Had three calls with the supplier" is activity. "Supplier confirmed delivery for 12 November" is progress.
- Naming everyone. If a tool notifies the people you mention, every name is an interruption. Name the person who must act, not the people who might be interested.
- Numbers without last week's. A metric on its own is a fact; the same metric next to last week's is a trend.
FAQ
What should a weekly update include?
Three sections at minimum: progress since last week (finished things, with links), plans for next week (at most three commitments), and problems (each with a named person and a date). Add a numbers section with last week's values alongside, and a short list of decisions you need from readers.
How long should a weekly team update be?
Short enough to read on a phone without scrolling much: 150 to 300 words, or roughly twelve bullet lines. Anything that needs more space should be a linked page, not a longer update.
Who should write the weekly status update?
One owner per product or area, usually the lead or the person carrying the most work. Personal updates from every team member turn into task lists that nobody reads. A team of eight with three products should post three updates.
Can a written update really replace the status meeting?
It replaces the reporting half of it. Keep a short optional call for open decisions and for talking to each other, with no status on the agenda. Teams that cancel the meeting outright and keep the call find the call gets shorter every week.
Which tools are good for async weekly updates?
Any tool where the update is searchable later, can be commented on, and does not disappear under chat. Slack canvases pinned to a channel, Basecamp's automatic check-ins, or a project tool with a per-product update feed such as Atrix all pass. A plain chat channel does not.
What is the difference between a weekly update and a daily standup?
A daily standup is about coordination for the next 24 hours and is usually per person. A weekly update is about the state of a product over the week and is per product or area. Small teams can usually drop the daily one once the weekly one is reliable.
Next step
If your updates live next to the work, the Progress section mostly writes itself. See how products, cycles and update feeds fit together in Atrix project management, or start from the template above in whatever you already use.