My embarrassing moment
It took me years to figure out what leadership really wants to see in updates.
Five years ago, my updates looked like project summaries: timelines, milestones, blockers.
Fine for a project manager. But as a product manager, I was missing the most important part: outcomes.
Three years ago, I sent my first real product update. My manager blocked it.
The vision was fuzzy. I was too focused on delivery, not direction.
Two years ago, things started changing.
I began writing outcome-driven updates... focused on user value, not activity.
And that’s when I got the best feedback of my career:
“Maria & Team... this is really work to be proud of.”
That’s when I realized something important.
The difference between ignored and appreciated updates isn’t format. It’s focus.
Why your updates get ignored
Leadership doesn’t read every word. They scan for signals:
→ What impact did we create?
→ Can I reuse this story to showcase success?
→ Are we on track?
→ Are there risks?
→ What do users say?
If they can’t find those quickly... or your update is too long, too vague, or too detailed... it’s gone.
The most common mistakes (and how to fix them)
Here are the top mistakes I see internal PMs make in their updates... and the fixes that make all the difference.
1️⃣ Writing features, not outcomes
Bad: “Shipped new approval workflow.”
Good: “Rebuilt approval workflow. Average approval time dropped from 5 days to 3 days.”
Fix: After every feature, ask: “So what?” What changed for users or the business?
2️⃣ Hiding risks instead of surfacing them
Bad: [No mention of risks]
Good: “Risk: User adoption at 38% (target 83%). Root cause: Missing custom fields Sales needs. Meeting with Sales VP next week to prioritize.”
Fix: Call out what’s off track, what you’re doing about it, and who’s involved. Transparency builds trust.
3️⃣ Ignoring your team’s contributions
Bad: “The team did great work this month.”
Good: “Sarah (Data Engineer) wrote a deduplication script that saved us weeks of manual cleanup.”
Fix: Be specific. Keep a running doc of team wins and mention real contributions.
4️⃣ Using jargon or technical detail
Bad: “Refactored backend microservices to improve API latency.”
Good: “Improved system performance. Page load times dropped from 3s to 0.5s.”
Fix: Translate technical work into outcomes. Leadership doesn’t care about refactors. They care about impact.
5️⃣ Making excuses instead of asking for help
Bad: “We couldn’t ship X because Y team didn’t deliver.”
Good: “Risk: Dependency on Y team blocking launch. Escalating to leadership to unblock.”
Fix: Frame blockers as risks that need resolution, not excuses. It shows ownership.
6️⃣ Overwhelming with too much detail
Bad: 10 highlights, 15 metrics, 3 pages of text.
Good: 3–4 key highlights and 3–5 metrics that fit on one page.
Fix: Be ruthless with brevity. Leadership skims. Save extra details for deep dives.
7️⃣ Forgetting “what’s next”
Bad: Ending the update after highlights.
Good: “Next month: Launch pilot with 10 users. Complete phase 2 migration. Test new dashboards.”
Fix: Always include 3–4 clear priorities. Leadership wants to know what’s next... not just what’s done.
The fix that changed everything
Before you hit send, ask yourself:
After every section, check:
→ What changed for users or the business?
→ How do I know (metric, quote, or observation)?
Do that, and your updates stop being ignored. Because they now show value, not activity.
Want the full structure?
I created a framework that helps you write confident, impactful updates in under 10 minutes.
It includes examples, a Notion template, and a GPT that drafts your first version.
👉 Get The Confident Product Update System
It’s the exact system I use to make leadership actually read my updates.
