I said something in a PM discussion last week that I’ve been thinking about since.
We were talking about what product managers actually do that AI can’t replicate – where the real value sits as execution gets automated. And I said: the thing you did to build it is the least interesting part of your story.
What’s interesting is: how did you figure out what to build? How did you get leadership to agree when they were skeptical or actively resistant? How did you know – before you’d built anything – that this was the right problem to solve?
Every PM in the room nodded. Because they know this. The value isn’t in the features shipped. It’s in the judgment calls – the “we should build this and not that” decisions that are invisible in the finished product.
Then those same PMs go home and write resumes that describe what they built.
What a resume usually says
Here’s a bullet I see constantly on senior PM resumes:
“Led development of new onboarding flow, reducing time-to-value by 40%.”
That’s a fine result. But it raises more questions than it answers. Why was onboarding broken? How did you know 40% was even achievable? Who did you have to convince? What did you have to sacrifice to get there?
The bullet describes an output. It says nothing about the judgment behind it.
Hiring managers – the good ones, anyway – are trying to assess whether you can solve their problems. Not whether you’ve shipped features before. Everyone has shipped features. They want to know: can you figure out which problems to solve, and can you build the organizational will to go solve them?
A bullet that says “led development of X, achieved Y” doesn’t answer either of those questions.
What hiring managers are actually evaluating
Think about what a hiring manager is facing when they pick up your resume. They have a real problem – some combination of: growth is stalling, the product is technically sound but users aren’t adopting it, the team is shipping but the metrics aren’t moving, a competitor just launched something they didn’t see coming. The job description is a rough approximation of what they think they need. The real job is solving that problem.
So when they read your resume, the question running in the back of their mind is: has this person solved something like what I’m facing?
That question can only be answered if your resume shows the problem, not just the solution.
Which means the most valuable thing you can put on your resume is the context that made your work hard. Not a list of what you shipped.
The two things most PM resumes leave out
When I work with senior PMs on their resumes, there are two questions I ask about every bullet:
What was the problem that made this necessary? Not the technical problem – the business problem. What was going wrong, or not happening, or getting worse? What was at stake if nothing changed? This is the context that makes your result legible. Without it, “40% improvement in time-to-value” is a number floating in space.
How did you get permission to do it? This is the one most people never think to include. But getting organizational buy-in for a difficult initiative – especially one that required resources, required killing something else, or required convincing someone powerful who was skeptical – is one of the hardest and most valuable things a senior PM does. If you did it, that’s part of the story.
The resume that answers both questions reads completely differently than the one that doesn’t. It reads like a case study, not a job description. It shows judgment, not just output.
What this looks like in practice
Here’s that onboarding bullet rewritten with both questions answered:
“New users were churning within the first week – usage data showed most never reached the feature that drove retention. After six months of stakeholder alignment (the sales team had locked in onboarding as-is as part of enterprise contracts), redesigned the onboarding flow around the activation moment. Time-to-value dropped 40%; 90-day retention improved 22%.”
That’s longer. Worth it. Because now the hiring manager knows: you identified a problem that wasn’t obvious, you navigated organizational resistance to fix it, and you delivered results that mattered to the business. Not just feature shipped, metric improved.
That’s the story that gets you interviews. And, not coincidentally, it’s the story you’ll need to tell in the interview itself – so writing it down first is useful practice.
Why PMs are trained to leave this out
It’s not that PMs don’t know this part of the story. They lived it. They know exactly how hard the stakeholder alignment was, what the politics were, which assumptions they had to challenge.
The problem is that every resume template ever made trains you to describe outputs. “Led,” “managed,” “delivered,” “achieved.” The template has no field for “here’s the business problem this solved” or “here’s how I got three skeptical executives to sign off on this.”
So that context – the most valuable part of the story – never makes it onto the page.
Your resume isn’t failing because you’re not qualified. It’s failing because you’re describing what you built when you should be describing why it mattered and how you made it happen.
Those are very different documents. And only one of them gets you interviews.
If your resume is getting lost in the stack, I work with senior PMs to build out the full story – not just the output. Book a free resume review here – I’ll show you exactly where yours is underselling you.