A product manager's portfolio is where the reviewer checks how you think, not just what shipped. Build two or three case studies that each move from a problem with a number, through the decisions you made, to a measured outcome. The resume lists the launches; the portfolio shows the reasoning behind them.
For: Product managers and service planners who want to show how they framed problems and shipped measurable changes
Open every case study with the problem the business had, stated with a number such as a drop-off rate, a support volume or a conversion gap. A reviewer who understands the problem in the first slide will read the rest as a story rather than a list of features. Keep it to one or two sentences and name who was affected. If the problem cannot be measured, describe how you discovered it and how often it happened.
Screens and roadmaps show what was built, but a PM is hired for judgment. Include the key trade-off in each case: which options you considered, what data or research pointed one way, and what you chose to leave out. A simple before-and-after flow, a prioritization table or a short excerpt of an experiment plan works better than a full PRD. Caption every image so it makes sense without your narration.
Product work is shared with design, engineering and data, so the reviewer needs to know what was yours. Put the period, your role and the team size on the first slide of each case, for example 'PM lead · team of 5'. Then describe your actions with verbs such as defined, interviewed, prioritized and ran. Credit the team for the build, and keep your own contribution specific enough to discuss in an interview.
BeforeImproved the checkout experience for the app.
AfterCut the checkout steps from 5 to 3 after 12 user interviews, lowering the address-step drop-off from 38% to 21% within 8 weeks.
The research, the change and the before-and-after number turn a vague claim into a case the reviewer can follow.
BeforeManaged the roadmap and worked with developers and designers.
AfterRan quarterly prioritization for a team of 7 using an impact-effort score, shipping 9 of 11 committed items on schedule.
Coordination is expected of every PM; a method and a delivery rate show how well you did it.
BeforeLaunched a new notification feature that customers liked.
AfterDefined and A/B tested restock alerts on 20% of traffic, raising 30-day repeat purchases by 11% before a full rollout.
Naming the experiment and its size shows product judgment, and the number replaces an opinion with evidence.
Two or three is usually enough. Choose the cases closest to the role you are applying for, and give each one enough depth to show the problem, your reasoning and the result. A short list of other launches can go on a single closing slide.
A failed experiment can make a strong case if you explain what you learned and what you changed next. For confidential figures, use ratios and relative changes such as 'drop-off down by 45%', and refer to the company by industry if needed. Remove internal code names and customer data from every screenshot.
Yes, if you made them. Rough wireframes, user flows and experiment plans are useful evidence of how you shaped the product. Label them as your own working artefacts, and make clear which final screens were produced by the design team.
The button opens a portfolio filled with this example in the editor. You need to sign in; change the text, images and layout of every slide freely and download it as PDF or PPTX. Drop your own work onto the image spots.
Start with this example ↗