PM Portfolio Template

Most PM portfolios fail for one of two reasons: they read like a resume with more words, or they go deep on process and never show the outcome. This template fixes both. Use it as a fill-in guide for each section.

Portfolio Structure Overview

A PM portfolio is not a collection of everything you have worked on. It is a curated argument for why you should be hired for this specific role. Three to four case studies is the right number. More dilutes the signal.

  1. Introduction (1 page): Who you are, what you are optimizing for in your next role, and one clear sentence that captures your PM point of view.
  2. Case Studies (3-4 case studies, 2-4 pages each): Structured stories with real metrics. One per major product area you want to be hired for.
  3. Technical Depth Section (1-2 pages): Evidence that you can work with engineers and data scientists, not just translate requirements.
  4. Vision Piece (1-2 pages): A forward-looking product take. Shows how you think about the future of a space.

Introduction Section Template

Fill in the brackets with your content:

I am a PM with [X years] of experience in [domain]. I have shipped products that [brief impact statement - e.g., "reduced clinical documentation time by 40% for 2,000 physicians"]. I am drawn to roles where [what energizes you professionally - be specific, not generic]. My core belief about building great products is [one honest, specific sentence - not a platitude].

What to avoid: "I am passionate about technology and making users happy." This says nothing. Every PM says this.

Case Study Template

Use this structure for each case study. The fill-in guidance is in italics.

Header

Product Name | Company | Your Role | Timeline

Context (2-3 sentences)

What was the product? Who were the users? What was the business situation when you joined this project? One sentence on the market or competitive context if relevant.

Problem (3-5 sentences)

What specific problem were you solving? How did you know it was the right problem? What data, research, or signals led you to it? What was the cost of not solving it?

Approach (core of the case study - 200-400 words)

Walk through your process. Not every step - the meaningful choices. What options did you consider? What trade-offs did you weigh? Who did you need to align? What did you learn during discovery that changed your direction? Be specific about your decisions and why you made them, not generic about "I followed an agile process."

Metrics (4-6 bullet points)

This is non-negotiable. If you cannot show impact in numbers, this case study should not be in your portfolio. If the numbers are confidential, use percentages or relative comparisons ("improved X by 3x over baseline"). Cover: primary success metric, at least one guardrail metric, one leading indicator if applicable, and timeline to impact.

Learnings (2-4 sentences)

What would you do differently? What surprised you? This section builds trust with interviewers because it shows self-awareness. Do not write "I would do nothing differently." Nobody believes it.

Metrics Storytelling

You can present impact without revealing anything confidential by using these approaches:

  • Relative improvement: "Increased activation rate by 28% over a 6-week period" reveals the delta, not the absolute number.
  • Indexed comparison: "This cohort retained at 2.3x the rate of the previous cohort" shows magnitude without exposing raw data.
  • Scale without specifics: "Deployed to 150+ enterprise health systems" gives scope without a specific revenue figure.
  • Cost avoidance: "Reduced manual review time from 4 hours per case to under 20 minutes" is specific and compelling without touching financials.

One rule: never make up numbers or inflate results. Interviewers at senior levels have pattern recognition for this. A specific, honest metric beats a vague impressive-sounding one.

Technical Depth Section

You do not need to show code. You need to show that you understand what engineers are actually building.

Options for demonstrating technical depth:

  • Architecture narrative: A written explanation of how a system you built works - what components, what data flows, what the key technical constraints were. Use a simple diagram if helpful.
  • ML model decision log: If you worked on an AI product, describe how the model was trained, what the key feature choices were, and what you measured to know it was working. Explain any bias considerations you worked through.
  • API specification you wrote: If you defined an external API, show the endpoint design and explain the product decisions behind the structure.
  • Technical trade-off memo: A brief document where you evaluated two or more technical approaches and made a recommendation. Shows how you think alongside engineers without pretending to be one.

Vision Piece

A vision piece is a 500-800 word take on where a product space is going in the next 2-3 years and what a company in that space should build. It is not a prediction. It is an argument.

Structure to follow:

  1. The current state: What does the space look like today? What is broken or changing?
  2. The underlying shift: What is driving change? (technology, regulation, user behavior, economics)
  3. The opportunity: Given that shift, what becomes newly possible that was not possible before?
  4. What a smart team should build: Specific product bets, not vague directions. "A team should build X for Y user because Z." Make a call.
  5. The risks: One paragraph on what could make you wrong. This is where most candidates fail - they write a vision with no counterargument.

Worked Example: Case Study Outline

Here is a filled-in example outline for a Life Sciences & Life Sciences & Healthcare AI PM to model their own case study after:

Product: Prior Authorization Automation Tool | Life Sciences & Healthcare SaaS Company | PM | 14 months

Context: The product helped physician practices submit prior authorization requests through their EHR. Payer rules change frequently and manual PA takes 30+ minutes per request. The market context: CMS had just proposed new rules requiring faster PA decisions.

Problem: Abandonment at the point-of-care was high - physicians submitted a PA request, then gave up before getting a decision. Research revealed the core issue: too many back-and-forths to gather supporting documentation after initial submission.

Approach decisions to highlight: Chose to build document pre-fill over instant approval (too dependent on payers) because we controlled the data. Aligned with EHR partner to access clinical notes via FHIR. Made a call to launch in oncology first (highest PA burden, highest physician motivation to try new tools).

Metrics: Average time-to-submission reduced from 31 min to 12 min. First-pass approval rate increased from 61% to 74%. NPS among physician users: +42. Deployed in 3 EHR environments within 8 months of launch.

Learnings: Underestimated payer variability - built a rules engine that turned out to need 4x more maintenance than projected. Would have partnered with a payer data aggregator earlier instead of building payer logic in-house.

Design Tips

  • Length: 8-15 pages total. Anything longer and it will not be read.
  • Format: PDF is safer than a web link for sharing with hiring managers. Build in Notion, Google Docs, or Figma - export to PDF.
  • Visuals: One diagram per case study is plenty. Do not add screenshots of dashboards unless they are genuinely illustrative.
  • Density: Leave white space. Dense pages look like reports, not arguments.
  • Personalization: For each application, move the most relevant case study to the front. The reader should feel like you built this for them.

A good portfolio takes 20-30 hours to build the first time. It is worth every hour - it is your answer to half the questions you will get in a screen before you even speak to anyone.

Keep reading

Further Reading