Metrics & Growth

Weekly PM Report

A structured weekly report template for product managers. Covers key metrics, what shipped, what's blocked, decisions made, upcoming priorities, and asks from leadership — in a format that takes 20 minutes to write and 5 minutes to read. Free to copy, download, and use. No signup required.

Template
# Weekly PM Report
**Product / Area:** [Name]
**PM:** [Name]
**Week of:** [Date range, e.g. Apr 21–25, 2025]
**Sent to:** [Stakeholders / team]

---

> **Writing guidance:** This report should take you 20 minutes to write and 5 minutes to read. Be specific — numbers, not adjectives. "Signups grew" is useless. "Signups grew 18% WoW, driven by the SEO post on PRD templates" is useful. Lead with what changed, not what happened.

---

## 🔢 Metrics snapshot

| Metric | This week | Last week | WoW change | Target | Status |
|---|---|---|---|---|---|
| [Primary metric, e.g. MRR] | ₹ | ₹ | % | ₹ | 🟢 / 🟡 / 🔴 |
| [Activation rate] | % | % | % | % | |
| [DAU / WAU] | | | % | | |
| [Churn rate] | % | % | | % | |
| [NPS / CSAT] | | | | | |
| [Your metric] | | | | | |

**One sentence on the most important metric movement:**
[What moved, why, and whether it's signal or noise]

---

## ✅ Shipped this week

*Only include things that are live in production and usable by real users.*

- [ ] [Feature / fix 1] — [1-line description of what it does and why it matters]
- [ ] [Feature / fix 2]
- [ ] [Feature / fix 3]

**Impact of the most significant shipped item:**
[What behaviour or metric are you expecting to move, and by how much, and when will you know?]

---

## 🔄 In progress

| Item | Owner | Expected ship | Blocker |
|---|---|---|---|
| [Item 1] | [Name] | [Date] | None / [Blocker] |
| [Item 2] | [Name] | [Date] | |
| [Item 3] | [Name] | [Date] | |

---

## 🚧 Blockers

*Only list things that are actively blocking progress — not things you're monitoring.*

1. **[Blocker 1]:** [What is blocked, what is blocking it, what you need to unblock it, and by when]
2. **[Blocker 2]:** [Same format]

**Ask from leadership (if any):** [Specific decision or unblock you need, and the deadline for it to matter]

---

## 🧠 Decisions made

*Decisions made this week that stakeholders should be aware of.*

| Decision | Rationale | Alternatives considered |
|---|---|---|
| [Decision 1] | [Why] | [What else was on the table] |
| [Decision 2] | | |

---

## 🔭 Next week priorities

| Priority | Why it's first | Owner | Success criteria |
|---|---|---|---|
| [P1] | [Reason] | [Name] | [What done looks like] |
| [P2] | | | |
| [P3] | | | |

**What is explicitly NOT happening next week (and why):**
[The thing that looks urgent but isn't — say it so stakeholders don't ask about it]

---

## 💬 Context / commentary

*Optional. Use for anything that doesn't fit above — market signal, customer feedback, a concern, a hypothesis.*

[Free text — keep it under 150 words]

How to use this Weekly PM Report template

1

Write it on Friday afternoon, not Monday morning

A Monday report describes last week from memory. A Friday report describes last week while you're in it. The difference is specificity — Friday you remember why signups spiked on Tuesday; Monday you just see the number. Set a recurring 30-minute block on Friday afternoons. The 20-minute write time is realistic only if you're doing it while the week is fresh.

2

Lead every metric with the change, not the absolute

'MRR: ₹1,84,000' tells leadership nothing if they don't remember last week's number. '₹1,84,000 MRR, up 12% WoW' is useful. 'MRR up 12% WoW driven by the annual plan promotion — 8 new annual customers converted' is excellent. The change and the driver are more important than the absolute number.

3

The 'not happening' section prevents more questions than anything else

Leadership asks about the thing you deprioritised because they don't know you deprioritised it. Explicitly naming 'we are not shipping X next week because Y is higher priority' saves you a meeting, a Slack thread, and the implied pressure to do both. It also forces you to articulate your own prioritisation logic, which is useful even if no one reads it.

4

Use the blockers section as a forcing function, not a complaint log

A blocker entry that says 'design hasn't delivered the mocks' is a complaint. A blocker entry that says 'mocks due Friday from design; if not received by EOD Friday, engineering kickoff slips to the following Monday — flagging now so design lead is aware' is a forcing function. The difference is specificity about consequence and timeline. Only the second version prompts action.

Want a Weekly PM Report grounded in your actual customer data?

PMRead ingests your customer interviews, feedback, and Slack threads — and generates PRDs backed by real evidence, not guesses.

Try PMRead free →

Frequently asked questions

How long should a weekly PM report be?

One to two pages maximum. If it's longer, you're including things that belong in a Jira ticket or a strategy doc, not a weekly report. The test: can your CEO read it in 5 minutes and understand what matters? If they have to read it twice, it's too long. Cut the items where the update is 'on track' with no new information — those don't belong in the report.

Should I include negative news in the report?

Yes — immediately and specifically. Hiding bad news in weekly reports is the fastest way to destroy trust with leadership. The format to use: 'Metric X missed target by Y%. Root cause is Z. Plan to address it is A, B, C. Expected to recover by [date].' Leaders who find out about problems from sources other than the PM lose confidence in the PM, not the product.

Who should receive the weekly report?

Your direct manager, the engineering lead for your product area, and any stakeholders who have standing asks or dependencies on your roadmap. Don't send it to everyone — you'll water down the signal with noise. If someone hasn't engaged with a report in 4 weeks, take them off the list and offer a monthly summary instead.