The PM Brag Sheet: What to Track to Make Your Promotion Case Write Itself
CareerClimb
Tracking PM wins is hard
Log product decisions and influence moments before they disappear from memory.
Share this article
You open a brag doc template. The first section says "Impact & Delivery." The second says "Technical Leadership." The third says "Collaboration & Mentorship." Fine categories if you write code. You did not ship code this quarter. You shaped a product strategy, killed a feature before it burned eight weeks of engineering time, and convinced a VP to shift the roadmap. None of that fits in those boxes.
Most brag doc advice is written for people who produce artifacts: pull requests, system designs, latency improvements with measurable numbers. Product managers produce decisions. Decisions are harder to attribute and harder to remember three months later when review season hits. An engineer's brag doc entry says "reduced P99 from 800ms to 220ms." Yours says "decided to prioritize billing over the feature leadership asked for." One is concrete. The other needs a paragraph of context to land.
That context problem is why most PMs either abandon their brag doc or fill it with entries that read like project status updates. Neither helps when your manager has two minutes in calibration to answer the question that decides your promotion: "What did the PM actually do?"
You need a different system. Not a different tool. Different categories.
Why the standard brag doc fails PMs
The widely shared brag doc framework from Julia Evans tracks projects shipped, design docs written, mentorship, learning, and company building. It works well for engineers because those categories map to how engineering performance gets evaluated (which is why the engineering brag doc template exists as its own thing). Calibration committees evaluate PMs differently.
ProductPlan's research on PM performance confirms the structural problem: product management is primarily soft skills and strategy, which makes PM impact harder to quantify than engineering output. PMs do not write code, test products, or create marketing pitches. Their impact happens upstream of anything you can count, and that upstream quality is exactly what makes PM wins slippery.
You made the call that saved the quarter. The engineer built the thing that saved the quarter. By review season, the engineer has a pull request to point to. You have a Slack message from April that nobody remembers.
A PM brag sheet built on the right categories does not just help during review season. Used in 1:1s throughout the year, it gives your manager concrete evidence to advocate for you before calibration even starts.
Five categories your PM brag sheet needs
1. Product decisions with reasoning
This is your primary evidence. Not features shipped. Not projects completed. Decisions you made, why you made them, and what happened because of them.
Every entry follows the same pattern: what you decided, what the alternative was, and what the outcome was.
"Decided to cut the admin dashboard from v1 scope because usage data showed only 4% of admins used the existing one more than once a month. Redirected 6 weeks of engineering time to the API integration, which drove 3 new enterprise contracts."
The rejected alternative is what makes this PM evidence instead of project management evidence. Anyone can describe what shipped. Only the PM can explain what did not ship, and why that was the right call.
Track this after every roadmap review or prioritization meeting. These decisions are easiest to document while you still remember the reasoning.
2. Kills and deprioritizations
Every feature you scoped down and every initiative you pushed back on saved the team time they spent on something more valuable. Calibration committees care about this evidence because it proves judgment. But kills are invisible by default. Nobody celebrates the feature that did not get built.
Track three things for each kill: what you said no to, what the team worked on instead, and what resulted from the redirection.
"Killed the notifications overhaul after user research showed 72% of users had already disabled push notifications. Redirected that quarter of engineering time to the onboarding flow, which improved Day 7 retention by 11%."
You will forget these faster than anything else you do. The decision felt obvious at the time. Six months later, you will not remember you made it. Log kills within 24 hours of the decision.
3. Influence moments
"Drove alignment" means nothing in a calibration room. What holds up: specific instances where someone changed their mind because of you, and what that led to.
The entry format: who you influenced, what changed, and the downstream outcome.
"Engineering leadership wanted to prioritize the internal tooling migration. Presented customer churn data showing the billing UX was driving 12% of voluntary churn. VP shifted Q3 priorities to billing. Churn dropped to 8%."
This is the hardest category to track because influence moments rarely feel like wins at the time. They feel like meetings. But the meeting where a VP changed the roadmap because of data you presented is the strongest evidence a PM can bring to a promotion case.
Write the entry before you close your laptop after that meeting. What feels like "just another meeting" right now is calibration ammunition in six months.
4. Metrics you own through the decision chain
Product metrics belong to the product, not to you. Revenue went up. DAU grew. Churn dropped. None of those belong in your brag sheet without a chain connecting the metric to a decision you made.
The chain looks like this: you identified a problem, proposed a solution, justified building it over the alternatives, and the team shipped it. The metric moved. Each link in that chain is a separate piece of evidence.
Weak entry: Activation rate improved from 34% to 41%.
Strong entry: Identified that 63% of users were dropping off at onboarding step 3. Proposed cutting the 5-step flow to 2 screens. Engineering initially pushed for a full redesign. Scoped the cut to ship in 2 weeks instead of 8. Activation rate improved from 34% to 41%.
The difference is attribution. The first entry could be anyone's claim. The second traces the outcome back to your judgment. Only include metrics where you can draw a clear line from your decision to the number moving.
5. Customer intelligence turned into action
PMs sit closer to customers than anyone else on the product team. The insights you surface from customer calls, support tickets, usage data, and user research are raw material for product decisions. But most PMs let that intelligence evaporate after the meeting where they shared it.
Track: what you learned, where it came from, and what product action it triggered.
"Three enterprise customers flagged the same billing edge case during Q2 quarterly business reviews. Brought the data to the product review. Team prioritized the fix, which reduced billing support tickets by 40% in Q3."
A customer insight that did not change anything is not evidence of product judgment. The value is in what you did with what you learned.
The template (copy this)
Copy the template below into a Google Doc, Notion page, or any tool you already use.
PM BRAG SHEET -- [Your Name] -- [Year]
Role: [Title, team, company] Review period: [e.g., Jan 2026 - June 2026] Last updated: [Date]
Product Decisions
What you decided, what the alternative was, and what happened.
| Date | Decision | Rejected alternative | Outcome |
|---|---|---|---|
| Feb 8 | Cut admin dashboard from v1 scope based on 4% usage data | Engineering wanted to redesign the full admin experience (8-week estimate) | Redirected effort to API integration, which drove 3 enterprise contracts |
| Mar 22 | Prioritized billing UX fix over the feature leadership originally requested | Leadership wanted a new analytics dashboard for Q2 launch | Checkout abandonment dropped 18% in 6 weeks |
Kills and Deprioritizations
What you said no to, what replaced it, and what happened.
| Date | What I killed/scoped down | What we did instead | Result |
|---|---|---|---|
| Jan 15 | Notifications overhaul (72% of users had disabled push) | Onboarding flow rebuild | Day 7 retention improved 11% |
| Apr 3 | v2 of the internal reporting tool (3 stakeholder requests, but usage data showed declining adoption) | Mobile checkout optimization | Mobile conversion rate up 9% |
Influence Moments
Who changed direction because of you, and what that led to.
| Date | Who I influenced | What changed | Downstream result |
|---|---|---|---|
| Mar 10 | VP of Engineering | Shifted Q3 roadmap from internal tooling to billing UX based on churn data I presented | Voluntary churn dropped from 12% to 8% |
| Apr 18 | Design lead | Adopted my proposed onboarding simplification instead of the full redesign they scoped | Shipped 6 weeks earlier, same activation improvement |
Metrics I Own (through the decision chain)
Metrics tied back to specific decisions, not just team output.
| Metric | Before | After | My decision that caused it |
|---|---|---|---|
| Checkout abandonment | 23% | 19% | Prioritized billing redesign over analytics dashboard |
| Day 7 retention | 31% | 42% | Killed notifications overhaul, redirected to onboarding |
| Enterprise pipeline | 2 deals/quarter | 5 deals/quarter | Scoped API integration into v1 instead of deferring to v2 |
Customer Intelligence --> Product Action
What you learned from customers, and what it turned into.
| Source | Insight | Action taken | Result |
|---|---|---|---|
| 3 enterprise QBR calls (Q2) | Same billing edge case flagged by all three | Brought data to product review, team prioritized fix | Billing support tickets down 40% in Q3 |
| User research sessions (Mar) | New users could not find the core feature within first 3 minutes | Redesigned information architecture for onboarding | Task completion rate improved from 44% to 68% |
What I Want to Work On Next
Skills to build, types of decisions to own, scope to expand.
- Lead a cross-team platform initiative from 0-to-1
- Build a stronger data practice on the team so I am not the only one pulling usage analytics
- Get closer to the enterprise sales motion to understand what customers ask for vs. what they actually need
How to fill each section
Product Decisions. Every decision has three parts: what you chose, what you did not choose, and what happened. If you can only remember the decision but not the alternative, go back to the Slack thread or the meeting notes. The rejected alternative is what proves judgment.
Kills and Deprioritizations. The hardest section to maintain because the whole point is that nothing visible happened. Capture kills within 24 hours of the decision.
Influence Moments. After any meeting where someone changed direction based on something you presented or argued, write it down before you close your laptop. These moments dissolve from memory faster than any other category.
Metrics I Own. Only include metrics where you can draw a clear line from your decision to the number moving. "Revenue went up" is not a PM win. "Revenue went up because I chose to build X instead of Y" is.
Customer Intelligence. Log the insight AND the action it triggered. An insight that sat in a slide deck and changed nothing does not belong here.
When to update
PM workflows have natural rhythms that create good update triggers.
After every roadmap review or prioritization meeting. If you made a call about what to build or what to cut, that is a Product Decisions or Kills entry.
After every stakeholder meeting where direction shifted. If someone changed their mind, that is an Influence Moment. Write the entry before you context-switch.
After every customer interaction that surfaced something new. User research sessions, customer calls, quarterly business reviews, support escalations.
Friday afternoons, 10 minutes. Scan your calendar from the past week. If something from the list above happened and you did not log it, add it now.
Weekly updates work better than bi-weekly for PMs because PM work generates more small, forgettable moments of judgment than engineering work does. A decision you made on Tuesday can feel irrelevant by Thursday. It will not feel irrelevant in November when your manager needs ammunition for calibration.
The other benefit of updating weekly: you can share your brag sheet with your manager during 1:1s throughout the year. That removes the burden of them remembering your accomplishments. Your manager walks into calibration with concrete examples already loaded.
The payoff
The PMs who get promoted are not working harder than the ones who get passed over. They are tracking different things.An engineer's brag doc answers "what did you build?" A PM's brag sheet answers "what decisions did you make, and what happened because of them?" That second question is harder to answer from memory. It is also exactly the question the calibration room will ask about you.
If your brag sheet has 12 months of decisions, kills, influence moments, and metrics tied to your judgment, your promotion case is not something you build during review season. It already exists. Your manager opens the document and extracts talking points. Your PM self-review is an afternoon of editing, not a week of reconstruction.CareerClimb helps product managers track decisions and outcomes as they happen, so your promotion case builds itself while you work. Download CareerClimb
