How PM Teams Can Improve Write Outcomes

Your VP opens Slack at 8:40 on Monday. Between two fires and a budget review, she gives your team update eleven seconds. If she has to hunt for the headline, you've already lost her.

That's the skip test, and most weekly status reports fail it. Not because the work is bad — because the report is a diary, not a briefing. Here's how to write one that gets read, forwarded, and acted on.

The core problem: you're writing for the record, not the reader

Most PMs write weekly updates as a chronological log: what happened Monday, what happened Tuesday, blockers, next steps. It's accurate. It's also unreadable.

Your reader doesn't care what you did. She cares about three things: Is the project on track? What does she need to decide or unblock? What's the risk she doesn't know about yet?

Flip the structure. Lead with the answer, then support it.

The five-block structure that works

I've used this format across three companies and roughly 200 weeks of reporting. It holds up whether you're updating an exec, a client, or a cross-functional partner.

1. Headline (one line). The single sentence that answers "how's it going?" Write it as a status, not a mood. "On track for June 14 launch; one open risk on vendor contract" beats "Making good progress!"

2. Status: green / yellow / red. Pick one. Define what each color means for your team and stick to it. Ambiguity here is the fastest way to lose trust — a yellow that means "fine" to you and "about to blow up" to your VP is worse than no signal at all.

3. Decisions needed. This is the section most reports omit and the one your reader actually wants. List each decision, who owns it, and the date you need it by. If there are none, write "None this week" — don't leave the section out. The absence is information.

4. Risks and blockers. One line each: what's at risk, what's the impact, what you're doing about it. No essays. If a risk needs a paragraph, it needs a meeting.

5. What shipped / what's next. Brief. Bullets. This is the part everyone expects, so give it to them last and keep it short.

Write the headline last, then move it to the top

Draft the body first, then force yourself to write the one-sentence summary. It's easier to compress once you've laid out the facts.

Then read that sentence as if you were your busiest stakeholder. If it doesn't tell her whether to worry, rewrite it. "Team is aligned and executing" tells her nothing. "Launch slips one week — QA capacity, not scope" tells her everything.

Kill the passive voice and the hedge words

Two edits clean up 80% of weak status reports:

• Passive to active. "The contract was reviewed by legal" becomes "Legal reviewed the contract." Same fact, half the words, clear owner.
• Cut hedges. "We're hoping to maybe finalize by end of week" becomes "We'll finalize by Friday or flag a slip Thursday." Commit or don't. Hedging trains readers to discount everything you write.

Use a template — but not the same one forever

A fixed template saves you time and trains your readers to find things. The five-block structure above is a good starting point. But audit it quarterly: if a section is always "N/A," cut it. If a section is always long, split it.

The template serves the reader. When it stops doing that, change it.

A worked example

Here's what a real weekly update looks like in this format:

Headline: On track for June 14 launch. One risk: vendor contract still unsigned.

Status: Yellow

Decisions needed:

• Approve vendor contract exception (owner: Dana, needed by Wed 6/5)

Risks:

• Contract unsigned — if not resolved by Friday, integration testing slips one week.

Shipped: Auth refactor, new onboarding flow (behind flag)

Next: Integration testing, load test, beta cohort invites

Forty-five seconds to read. Every line earns its place.

The test before you hit send

Read your draft and ask: if my reader only reads the first two lines, does she know whether to act? If not, rewrite the headline and the status line until she does.

That's the whole job. Your report isn't a record of your week — it's a decision-support tool with a deadline. Write it like one.