How long should a weekly status update be?

Under 500 words for the body (excluding tables). The entire update should be readable in under 2 minutes. If you find yourself writing paragraphs, you are over-explaining. Move details to links or appendices. The status update is an index, not an essay.

Should I send the update via email, Slack, or a project management tool?

Email is the most reliable for stakeholders who do not live in your team's tools. Slack is good for the immediate team. The best practice: post the update in a dedicated Slack channel AND send a brief email to your distribution list with a link to the full update. This catches both the "inbox readers" and the "Slack readers."

What if nothing notable happened this week?

Send the update anyway. "Progress this week: On track across all initiatives. No blockers. Next week priorities: [list]." A short update that confirms things are on track is more valuable than silence, which stakeholders will interpret as a problem you are not sharing.

How do I handle a status update when things are going badly?

Lead with the facts, not the spin. State what happened, what the impact is, and what you are doing about it. "The checkout A/B test showed a -3% regression. We are reverting to control today and investigating the root cause. Updated timeline: [X]." Stakeholders respect transparency and a clear plan. They do not respect surprises three weeks later.

Should I ask my manager to review the update before I send it?

For your first 2-3 updates, yes. Ask your manager to review the format and confirm the right distribution list. After that, send independently. The point of a status update is to reduce the need for your manager to actively seek information. If they are reviewing every update before it goes out, the update is not saving anyone time. ---

Weekly Status Update Template

What This Template Is For

Status updates are the tax PMs pay for operating in complex organizations. Done poorly, they consume hours of writing time and minutes of reading time before landing in an inbox nobody checks. Done well, they are the single document that keeps your manager informed, your stakeholders aligned, and your team accountable without requiring another meeting.

This template provides a structured weekly format designed to be written in 15-20 minutes and read in under 2 minutes. It opens with a three-bullet TL;DR for executives who will not scroll past the first paragraph. It then breaks down progress by initiative, highlights key metrics, surfaces blockers and risks, lists decisions that need stakeholder input, and sets priorities for the coming week. The structure is intentional: every section answers a question your stakeholders are already asking in Slack or scheduling meetings to discuss.

If you are figuring out how to communicate effectively with different stakeholders, the Stakeholder Management Handbook covers communication strategies by stakeholder type. For recurring 1:1 meetings with your manager, pair this update with the 1:1 Meeting Template so your written update covers status and your live meeting covers the things that do not fit in a document.

When to Use This Template

Every week, on the same day. Consistency builds trust. Pick a day (Friday afternoon or Monday morning) and send the update at the same time every week. Your stakeholders should know when to expect it.
When you manage multiple initiatives. If you own more than one workstream, a single update with a progress table is far more efficient than scattering status across Slack channels, Jira tickets, and meeting notes.
When your stakeholders are senior. VPs and executives rarely read project management tools. A concise written update in their inbox is the most reliable way to keep them informed.
During high-stakes periods. Launches, migrations, and cross-functional projects generate anxiety. A weekly update with clear status indicators (On Track, At Risk, Blocked) prevents drive-by Slack messages asking "how's it going?"
When you are new to a team. Sending structured updates in your first few weeks signals competence, builds visibility, and creates a written record of your early contributions.
When you need to create a paper trail. If a decision is made, a risk is flagged, or a blocker is escalated, having it in a dated status update is significantly more defensible than a Slack thread.

How to Use This Template

Write the TL;DR first. Force yourself to distill the week into three bullets. If you cannot, you do not yet understand what matters most this week. The TL;DR should be readable in 10 seconds and give a busy executive everything they need.
Update the progress table. One row per active initiative. Use simple status indicators: On Track (green), At Risk (yellow), Blocked (red). The status column is the most-read part of any update. Make it scannable.
Add the metrics snapshot. Pick 3-5 metrics your stakeholders care about. Show the current value, the trend (up, down, flat), and the target. Do not bury metrics in a paragraph. Put them in a table.
Flag blockers and decisions. Be specific about what is blocked and what you need. "Need alignment on pricing" is vague. "Need VP Sales to approve the 20% discount threshold for enterprise deals by Friday" is actionable. Every blocker should have a proposed resolution.
Send it to a consistent distribution list. Your manager, your skip-level (optional), your engineering lead, your design lead, and any stakeholders with active involvement. Do not send it to everyone in the company. A status update sent to too many people is read by none.

The Template

TL;DR

Three bullets. One sentence each. Cover the most important win, the biggest risk or blocker, and the top priority for next week.

Win. [What went well this week. Be specific: shipped feature X, closed deal Y, resolved blocker Z.]
Risk. [The biggest thing your stakeholders should know about. If nothing is at risk, note that.]
Next week. [The single most important priority for the coming week.]

Progress This Week

Initiative	Status	Update
[Initiative 1]	[On Track / At Risk / Blocked / Complete]	[1-2 sentence update. What happened, what is next.]
[Initiative 2]	[On Track / At Risk / Blocked / Complete]	[1-2 sentence update.]
[Initiative 3]	[On Track / At Risk / Blocked / Complete]	[1-2 sentence update.]
[Initiative 4]	[On Track / At Risk / Blocked / Complete]	[1-2 sentence update.]

Metrics Snapshot

Metric	Current	Trend	Target	Notes
[Metric 1, e.g. Weekly Active Users]	[Value]	[Up / Down / Flat]	[Target]	[Brief context if trend is notable]
[Metric 2, e.g. Trial-to-Paid Conversion]	[Value]	[Up / Down / Flat]	[Target]
[Metric 3, e.g. NPS Score]	[Value]	[Up / Down / Flat]	[Target]
[Metric 4, e.g. Support Ticket Volume]	[Value]	[Up / Down / Flat]	[Target]

Blockers and Risks

#	Blocker / Risk	Impact	Proposed Resolution	Owner	Needed By
1	[Specific blocker or risk]	[What happens if this is not resolved]	[What you recommend]	[Who can unblock this]	[Date]
2	[Blocker or risk]	[Impact]	[Proposed resolution]	[Owner]	[Date]

If no blockers or risks this week, write: "No blockers this week."

Decisions Needed

Decisions that require stakeholder input. Be explicit about what you are asking for and when you need an answer.

#	Decision	Context	Options	Recommendation	Decision Maker	Needed By
1	[What needs to be decided]	[Brief background]	[Option A vs. Option B]	[Your recommendation and why]	[Name]	[Date]
2	[Decision]	[Context]	[Options]	[Recommendation]	[Name]	[Date]

If no decisions needed this week, write: "No open decisions this week."

Next Week Priorities

Ranked list of what you plan to focus on next week. Keep it to 3-5 items.

[Priority 1: specific deliverable or milestone]
[Priority 2]
[Priority 3]

Shoutouts

Optional. Recognize a team member who went above and beyond. Keep it specific: what they did and why it mattered.

[Name]: [What they did and why it mattered.]

Filled Example: Mobile Checkout Redesign

Context. A PM at a direct-to-consumer e-commerce company is leading a mobile checkout redesign aimed at reducing cart abandonment. The team includes 2 frontend engineers, 1 backend engineer, 1 designer, and 1 QA. The PM reports to the VP of Product and works closely with the Head of Growth and the Payments team.

TL;DR (Example)

Win. Shipped the new single-page checkout to 25% of mobile traffic (Variant B). Early data shows 8% higher completion rate vs. the multi-step control.
Risk. Payment integration for Apple Pay is blocked on the Payments team's sprint capacity. If unresolved by Feb 28, we will miss the full rollout target of March 10.
Next week. Finalize A/B test results for single-page checkout and prepare the ship/no-ship recommendation for Thursday's product review.

Progress This Week (Example)

Initiative	Status	Update
Single-page checkout (A/B test)	On Track	Variant B live to 25% of mobile traffic since Feb 12. Test is 8 of 14 planned days. Primary metric (checkout completion rate) trending +8% but not yet significant. Full results due Feb 26.
Apple Pay integration	Blocked	Payments team confirmed they cannot start the integration until March 3 due to their PCI compliance sprint. I have escalated to VP Engineering to discuss reprioritization.
Checkout error messaging redesign	On Track	New error states designed and approved by QA. Engineering work starts Monday. Expected to ship with or without the Apple Pay integration.
Post-purchase upsell experiment	At Risk	Design review pushed from this week to next week due to designer PTO. One week delay but does not affect the March 10 checkout rollout deadline.

Metrics Snapshot (Example)

Metric	Current	Trend	Target	Notes
Mobile checkout completion rate	52.3% (control) / 56.5% (Variant B)	Up	58%	Variant B at +8% relative. Not yet statistically significant (day 8 of 14).
Mobile cart abandonment rate	64.1%	Down (from 67.2% last month)	<60%	Trending in right direction. Checkout redesign is one factor; new "save cart" feature also contributing.
Average order value (mobile)	$47.20	Flat	$50	No change from checkout redesign, as expected. AOV is driven by merchandising, not checkout UX.
Checkout-related support tickets	38/week	Down (from 44/week)	<30/week	Down 14% since error messaging improvements in Jan.

Blockers and Risks (Example)

#	Blocker / Risk	Impact	Proposed Resolution	Owner	Needed By
1	Payments team cannot start Apple Pay integration until March 3	Delays full checkout rollout by 1 week (March 10 to March 17) if Apple Pay is a launch requirement	Option A: Launch without Apple Pay, add it in a fast-follow. Option B: VP Engineering moves Payments team priority. I recommend Option A.	VP Engineering (for capacity decision)	Feb 24
2	Designer PTO delayed upsell experiment design review	1-week slip on upsell experiment. No impact on core checkout rollout.	Reschedule design review to Feb 24.	Priya (Design)	Feb 24

Decisions Needed (Example)

#	Decision	Context	Options	Recommendation	Decision Maker	Needed By
1	Should we launch the new checkout without Apple Pay?	Apple Pay accounts for 12% of mobile payments. Delaying the full launch by 1 week to include it has opportunity cost (~$18K in lost conversion improvement based on current test results).	A. Launch March 10 without Apple Pay. Add Apple Pay by March 17. B. Delay full launch to March 17 to include Apple Pay.	Option A. The 8% checkout lift applies to 88% of transactions immediately. Apple Pay users keep the existing checkout until the integration ships.	VP Product	Feb 24

Next Week Priorities (Example)

Finalize single-page checkout A/B test results (test ends Feb 26). Prepare ship/no-ship recommendation for Thursday product review.
Resolve Apple Pay integration timeline with VP Engineering and Payments team lead.
Run design review for post-purchase upsell experiment.
Ship checkout error messaging redesign to 100% of mobile traffic.

Shoutouts (Example)

Sam (Frontend). Identified and fixed a race condition in the checkout form validation that was causing 3% of submissions to silently fail. Caught it through manual testing before QA even started.

Key Takeaways

Write the TL;DR first and make it readable in 10 seconds. Most stakeholders will only read this section. If it is clear and complete, the rest of the update is reference material.
Use a consistent status vocabulary: On Track, At Risk, Blocked, Complete. Traffic-light simplicity is the point. Do not invent creative status labels.
Every blocker should include a proposed resolution and a name. "Blocked" with no path forward is a complaint, not a status update. Pair your product review meetings with written updates to cover both async and synchronous communication.
Include metrics every week, even if they have not changed. Showing stable metrics builds confidence. Showing declining metrics early buys you time to respond before stakeholders notice on their own.
Send the update on the same day at the same time every week. Consistency is what turns a status update from an ignored email into a trusted information source.
Keep the shoutout section. Public recognition in a written document that reaches leadership is one of the most effective ways to build team morale and it costs you one sentence. For more on stakeholder management through regular communication, see the handbook.

About This Template

Created by: Tim Adair

Last Updated: 2/19/2026

Version: 1.0.0

License: Free for personal and commercial use