Weekly status update template
A good status update answers one question in the first line: are we on track? Everything after that is evidence. This template keeps your update short, honest and the same shape every week, so stakeholders know exactly where to look.
Updated
The short answer
A weekly status update tells stakeholders whether a product is on track, what shipped, what's at risk and what you need from them. Lead with the overall status and one sentence of why, then show milestone progress, risks, decisions and asks. Keep it under 300 words.
Pastes with formatting into Google Docs, Word, Notion and Confluence.
[Product] status update: week of [date]
Overall: On track / At risk / Off track. [One sentence on why.]
Headline
[The one thing a stakeholder should remember from this week.]
Milestones
| Milestone | Target date | Status | Progress | Note |
|---|
Shipped this week
-
Next week
-
Risks and blockers
| Risk or blocker | Impact | Owner | What we're doing |
|---|
Decisions made
| Decision | Why | Decided by |
|---|
What I need from you
- [A specific ask, from a named person, by a date.]
Example: fictional Meridian Labs data
Pulse Analytics status update: week of 21 Sep 2026
Overall: At risk. Self-serve dashboards (15 Nov) is at risk because the event schema contract is 4 days overdue.
Headline
Event ingestion is 85% done, but we need the schema contract this week to keep 15 November.
Milestones
| Milestone | Target date | Status | Progress | Note |
|---|---|---|---|---|
| Live event pipeline | 20 Sep | On track | 70% | Event ingestion at 85% |
| Self-serve dashboards | 15 Nov | At risk | 15% | Blocked by the schema contract |
| Governed metric catalogue | 20 Dec | On track | - | Starts after dashboards |
Shipped this week
- Event ingestion: deduplication on consumer restart
- Dashboard builder: first template (Daily active teams)
Next week
- Streaming aggregation: close the gap from 55%
- Agree owners for the top 20 metrics
Risks and blockers
| Risk or blocker | Impact | Owner | What we're doing |
|---|---|---|---|
| Dashboard builder -> Event schema contract, 4 days overdue | High | Tom Reyes | Escalating at Thursday's PI sync |
| Metric ownership unclear | High | Avery Nolan | Owner workshop on 3 Oct |
Decisions made
| Decision | Why | Decided by |
|---|---|---|
| Ship templates before exports | Templates drive self-serve adoption; exports can follow | Avery Nolan |
What I need from you
- Tom Reyes: confirm the event schema contract by 30 Sep, so Dashboard builder can start before PI 3 ends on 4 Oct.
New to status updates? Start here
What it is
A weekly status update is a short note that tells people outside the team whether the product is on track, what shipped, what's at risk and what you need from them.
Use it when
- Stakeholders aren't in your daily standups
- Leadership wants a weekly view
- You're in the run-up to a launch
Who writes it
The product manager or delivery lead
Who reads it
Leadership, stakeholders and neighbouring teams
How to fill it in
- 1Overall status
- Pick one. If you hesitate between two, choose the worse one. Stakeholders forgive early warnings, not late surprises.
- 2Headline
- One sentence. If a busy executive reads nothing else, this is what they take away.
- 3Milestones
- Only milestones that matter this quarter. Progress as a percentage, and a note only when something changed.
- 4Shipped this week
- Things users can see or use, not tasks completed.
- 5Next week
- Two or three things the team will focus on, so stakeholders know what to expect in the next update.
- 6Risks and blockers
- Each with an owner and an action. A risk with no action is just a worry.
- 7Decisions made
- Anything that changed scope, dates or approach, with the reason.
- 8What I need from you
- The most important section. Name the person, the ask and the date.
Tips for updates people actually read
- Put bad news first. Burying it in paragraph four erodes trust faster than the bad news itself.
- Use the same structure every week, so readers learn where to look.
- Link to detail instead of pasting it. The update is a summary, not a report.
- Send it at the same time every week.
Why weekly updates take so long
Writing this update often eats an hour or more every week. The information exists, but it's spread across the backlog, the roadmap, the risk log and a decisions doc, so someone copies it all into one place. By Tuesday it's out of date, and next Monday it starts again.
Status update in a doc
- Rebuilt by hand every week
- Copied from three or four tools
- Out of date soon after it's sent
- Readers can't click through to the detail
Product overview in Ondule
- Always current, because it reads from the work
- Milestones, sprint progress and open risks in one view
- Overdue dependencies surface in Needs attention on their own
- Click any line to see the work behind it
How to do this in Ondule
Questions
- What should a weekly status update include?
- Overall status with a reason, a one-line headline, milestone progress, what shipped, what's next, risks with owners, decisions made and specific asks.
- How long should a status update be?
- Short enough to read in two minutes, usually under 300 words. Link to detail rather than including it.
- How do I report that a project is behind?
- Say it in the first line, give the reason in one sentence, then show what you're doing about it and what you need.