What a product manager
portfolio should include.
A product manager portfolio should be two or three case studies, each showing a problem you were handed, the discovery that reframed it, the decision you made, and the metric that moved as a result. Hiring managers are reading for judgement under uncertainty, so the interesting part is the tradeoff you chose and why, not a feature list. Never publish a confidential roadmap, unreleased pricing, internal revenue, or anything under NDA. Below is the full list of what to put in, the terms a product recruiter actually searches, and which of the Portfolio designs suit a case-study format.
The sections a PM portfolio needs.
A product manager is hired on demonstrated judgement, so the portfolio is built around a few deep case studies rather than a wide list of shipped features. Work through these, and read the flagged block before you publish anything from a current employer.
Two or three deep case studies
Each case follows the same arc: the problem and its context, what you learned in discovery, the options you weighed, the call you made, and what happened. Depth is the signal here, so a case a reader can interrogate beats a portfolio of shipped screenshots.
The metric you moved
State the outcome in real terms: activation, retention, conversion, cycle time, or revenue, with the direction and rough magnitude. If you cannot share the exact number, give a relative change and the baseline, and say why the metric was the right one to chase.
Discovery and evidence
Show how you decided what to build: user interviews, support tickets, funnel data, a competitive read. A PM who starts from evidence rather than opinion is the one a hiring manager trusts with a roadmap, so make the research visible.
Prioritisation and tradeoffs
Explain what you chose not to do and why. The clearest signal of seniority is a defensible cut, so describe the framework you used, RICE, opportunity sizing, or plain reasoning, and the thing you deprioritised.
An experiment or bet
Describe one hypothesis you tested, how you measured it, and what the result changed. Even a bet that failed reads well when you show what you learned and how it redirected the next release.
How you worked with the team
A short note on how you partnered with engineering, design, and data. Product is a cross-functional job, so a line about how you unblocked a team or resolved a disagreement says more than a title ever will.
Never include: a confidential roadmap or internal numbers
No unreleased roadmap, no internal revenue or margin, no unannounced pricing, no strategy deck, and nothing an NDA covers. A public case study that leaks your employer's plans is a breach that can end the relationship and follow you into references.
Write about shipped, public work, or abstract the sensitive parts: "reduced onboarding drop-off on a B2B product" is safe. Posting next quarter's unreleased plan, even to look impressive, is not, and interviewers notice when a candidate overshares.
Terms a product recruiter searches.
Product recruiters filter their applicant tracking system for the methods and artefacts a PM owns. If these describe how you actually work, use the exact words, because the system matches strings, not intent.
Paste your resume into the free ATS score checker with a real PM posting to see which of these terms the posting uses and your resume is missing.
Which designs suit a case-study portfolio.
A PM portfolio is mostly long-form narrative with a few diagrams, so the design has to make reading easy without hiding the outcomes. Of the 60 Portfolio designs and 48 resume layouts, these fit.
Choose a design that lets each case study run as a readable article with headings, a pull quote for the outcome, and space for one or two diagrams. Avoid the image-heavy gallery designs, which reward pictures over reasoning.
Of the 48 resume layouts, pick a single-column one so your impact bullets stay in reading order through a parser. Lead each role with a metric, not a responsibility.
Put the result near the top of each case so a skimming hiring manager sees the payoff, then let the narrative explain how you got there. Front-load the number, back-load the method.
Use a calm design and plain language. A PM who can explain a hard decision simply reads as more senior than one who hides behind frameworks, and the layout should give that writing room to breathe.
Who a product manager portfolio is not for.
A portfolio helps some PMs a great deal and is optional for others. Read this before you invest a weekend, because in parts of this field a strong network moves faster than a website.
Worth building if you
- +Are breaking into product from engineering, design, consulting, or founding, and need to show product thinking directly.
- +Are an associate or junior PM who cannot yet lean on a long track record and wants case studies to speak for you.
- +Work on internal or B2B products the interviewer cannot try, so a written case is the only way they see your work.
- +Want one link to send with applications that shows how you reason, not just where you have worked.
Skip it, for now, if you
- −Are a senior PM hiring through your network, where a warm intro and a portfolio interview do the real work.
- −Could only fill it by leaking confidential work. Wait until you have public or abstractable material.
- −Would treat it as a feature museum. A list of shipped things without the reasoning behind them can read as junior.
- −Have an interview loop next week. Prepare your case-study talk track and fix your resume first.
Questions product managers ask.
Straight answers on case studies, confidentiality, and what recruiters actually read.
How many case studies should a PM portfolio have?
Two or three, done in depth. A hiring manager will read one closely and skim the rest, so put your strongest work first and make it interrogable end to end. A portfolio of ten shallow features signals less than a single case where you show the problem, the tradeoff, and the outcome.
Can I write about work covered by an NDA?
Not in specifics. You can describe the shape of the problem and your approach in abstract terms, "improved activation on a B2B onboarding flow", without unreleased plans, internal numbers, or a named unannounced feature. If you cannot abstract it safely, leave it out and use public or personal projects instead.
What if I cannot share exact metrics?
Give the direction and a relative change with the baseline: "cut onboarding drop-off by roughly a third from a high starting point." State why that metric mattered and how you measured it. Interviewers care more that you chased the right number and can defend it than about the precise figure.
Do side projects count if I have never shipped at a company?
Yes, if you treat them like real product work. Show the user problem, the discovery, the decision, and what you learned from real users, even a handful. A well-reasoned side project can demonstrate product thinking more clearly than a role where you only wrote tickets.
Should I include a product teardown?
A teardown can work as one entry if it goes beyond critique into a decision: what you would change, why, and how you would measure it. Avoid a portfolio that is only teardowns, though, because it shows opinion without the harder evidence that you can ship and move a metric.
Where to go next.
Build the site, test your resume, or read how the paste-a-resume flow works.
Turn your product
resume into a site.
Paste your resume and Portfolio drafts a clean, case-study website in about a minute. Outcomes up top, no confidential roadmaps anywhere, published to your own domain with TLS handled for you.