How to write a product case study for your portfolio requires telling a specific story: the problem you identified, the decision you made under constraints, the outcome you produced, and what you learned — not a feature release summary dressed up as strategic thinking.
A product portfolio case study is your evidence that you can do the job. It is not a press release about your company's success. The difference matters: interviewers are not hiring the company; they are hiring you. The case study must make your specific contribution — your decisions, your judgment, your trade-offs — legible to someone who wasn't there.
The Four Required Components of a PM Case Study
H3: 1. The Problem (With Evidence)
Start with the problem you were trying to solve, not the solution you built. Describe:
- What user behavior or business metric signaled the problem existed
- How you confirmed the problem was real (user research, behavioral data, support volume)
- Why it was worth solving compared to other problems you could have worked on
Common mistake: starting with "We decided to build X." The problem should come before the solution every time.
H3: 2. Your Decision (Not the Team's)
This is the section most PMs write incorrectly. Use first-person language to describe your specific contribution:
- What options did you consider?
- What trade-offs did you make?
- What did you decide and why?
- What did you say no to, and why?
Avoid: "The team decided to..." Replace with: "I recommended Option B because... and the trade-off we accepted was..."
According to Lenny Rachitsky's writing on PM portfolios, the most common failure in product case studies is the passive voice problem — PMs describe what happened as if they were observers rather than decision-makers. Every case study should make your individual judgment visible.
H3: 3. The Outcome (With Metrics)
State the outcome and quantify it. The metric should connect directly to the problem you identified:
- If the problem was retention, the outcome should be a retention metric
- If the problem was activation, the outcome should be an activation metric
- If the problem was revenue, the outcome should be a revenue metric
Avoid vanity metrics: "We launched to 100K users" is not an outcome unless those 100K users behaved differently as a result.
If you cannot share exact numbers due to NDA, use relative metrics ("increased by 23%"), order-of-magnitude approximations ("added approximately $2M ARR"), or time-based proxies ("reduced average onboarding time from 12 minutes to 4 minutes").
H3: 4. What You Learned (Honest Reflection)
This is the section that separates strong portfolio case studies from weak ones. State:
- What assumption you made that turned out to be wrong
- What you would do differently
- What you learned that changed how you approach similar problems
Interviewers are looking for self-awareness and growth mindset. A case study that ends with pure success and no reflection is either fabricated or lacks intellectual honesty.
According to Shreyas Doshi on Lenny's Podcast, the case study that gets the most interview follow-up questions is always the one where the PM describes a decision that did not go as planned and what they learned from it — it signals maturity, honesty, and growth mindset simultaneously.
Structuring Your Case Study
H3: Recommended Structure
1. Context (2-3 sentences): What product, what stage, what your role was.
2. The Problem (1 paragraph): What you observed, what data you used to validate it, why it mattered.
3. The Approach (1-2 paragraphs): How you explored the problem space, what options you generated, who you involved, what trade-offs you made.
4. The Decision (1 paragraph): What you decided to build, what you said no to, and the specific reasoning.
5. The Outcome (1 paragraph): What happened, with metrics connected to the problem statement.
6. The Learning (1 paragraph): What assumption was wrong, what you would change, how this shaped your thinking.
Total length: 600–1000 words for a written case study. Longer is not better.
H3: Visual Evidence
Include at least one visual element if possible:
- A before/after screenshot (with NDA-compliant redaction if needed)
- A wireframe or mockup you created
- A data visualization showing the outcome
- A framework diagram you used to make the decision
Visuals make the case study more credible and easier to scan.
According to Gibson Biddle on Lenny's Podcast, the best PM portfolio case studies are structured like the best PM interviews — they show thinking, not just outcomes. A case study that only shows the final shipped product is like a chess player showing you the final board position without explaining the moves that got there.
What to Do About NDA
Most PMs can share more than they think without violating NDA. You cannot share:
- Unreleased product plans
- Specific revenue figures (without approval)
- Customer names (without approval)
- Proprietary technology details
You can usually share:
- Relative metrics (increased by X%)
- Anonymized customer quotes ("a mid-market customer in financial services")
- Product screenshots of features that are publicly released
- Your process and decision-making framework
When in doubt, ask your legal or people team. Most will say yes to relative metrics and anonymized examples.
FAQ
Q: What should a PM portfolio case study include? A: The problem with evidence it was real, your specific decision and the trade-offs you made, the outcome with metrics connected to the problem, and honest reflection on what you learned.
Q: How long should a product manager case study be? A: 600 to 1000 words for a written case study. Longer is not better — interviewers will not read it if it exceeds 1500 words. Focus on what was specific and non-obvious about your contribution.
Q: How do I write a case study without violating NDA? A: Use relative metrics like "increased by 23 percent," anonymize customer references, and only show screenshots of publicly released features. Most orgs will approve relative metrics and anonymized examples if you ask.
Q: What makes a product case study stand out in a PM portfolio? A: First-person ownership language, a specific decision with explicit trade-offs, metrics connected directly to the original problem, and honest reflection on what did not go as planned.
Q: Should I include failed projects in my PM portfolio? A: Yes. A case study about a product that did not succeed, with honest reflection on why, is more valuable than a success story with no learning component. Interviewers trust candidates who can analyze failure.
HowTo: Write a Product Case Study for Your Portfolio
- Start with the problem statement using behavioral data or a business metric to show how you identified the problem was real and worth solving
- Describe your specific decision using first-person ownership language — the options you considered, the trade-offs you made, what you said no to and why
- State the outcome with metrics that connect directly to the problem you identified rather than vanity metrics disconnected from the original hypothesis
- Use relative metrics if exact figures are NDA-restricted and include at least one visual element such as a before/after screenshot or decision framework diagram
- Write a reflection section describing what assumption turned out to be wrong and what you would do differently to demonstrate self-awareness and intellectual honesty
- Keep the total length between 600 and 1000 words — longer is not better and interviewers will not finish reading a case study that exceeds 1500 words