How to write it
Outcomes, not the feature list
The default product manager resume is a list of things that shipped. It reads as a delivery record, and it invites the question every interviewer asks anyway: did any of it work? Answer that on the page instead.
"Shipped a redesigned onboarding flow" becomes "took trial-to-paid activation from 12% to 31%, worth $4.4M new ARR". The feature is implied. The judgement, the measurement and the commercial result are not, and they're what the job is.
What you killed is stronger evidence than what you shipped
Almost every product manager can name things they launched. Very few write down what they stopped, deprecated or refused, and it's the most senior signal available — it proves you can say no, and that you measure honestly enough to admit something isn't working.
"Killed two features with under 2% adoption, freeing a squad of five engineers and cutting support load 19%" is a bullet that makes an experienced hiring manager sit up, because it's the behaviour they most struggle to find.
Say how you decided
The credibility question about any product claim is whether you knew what you were doing or got lucky. You answer it by naming the method: interviews at a stated cadence, experiments with a stated count, a metric you defined, a pricing test, a churn analysis.
"Rebuilt discovery — 40+ customer interviews a quarter, continuous — replacing a roadmap set annually in a spreadsheet" describes a process change with a before and after. That's a stronger claim than any adjective about being customer-obsessed.
- Activation, retention, conversion, or engagement, before and after
- Revenue or ARR influenced, with your scope stated honestly
- Experiments run, and how many produced a decision
- Discovery cadence — interviews, surveys, win/loss analysis
- Things deprecated, and what that freed up
Be honest about scope, and specific about surface
Product managers are frequently caught overstating ownership, because the work is collaborative by nature and "led" is doing a lot of work in most bullets. The fix is to name the surface rather than claim the company's results: the self-serve funnel, the integrations line, the mobile app for 45,000 field users.
Naming the surface is more informative anyway. A hiring manager wants to know what you'd be trusted with, and "owned the self-serve growth surface" answers that precisely where "drove company growth" does not.
Show that engineering and design respected you
The failure mode hiring managers screen for is the product manager who writes tickets and calls it prioritisation. Evidence against it: technical specifics you clearly understand, tradeoffs you made with engineering, research you ran with design rather than commissioned.
Knowing SQL well enough to answer your own questions is worth listing, and worth demonstrating with an analysis you did yourself. It's the cheapest way to signal that you don't queue behind an analyst to learn what your own product is doing.