A strong product management portfolio has three to five deep pieces, each showing the user problem, the decisions you made, how you measured success and what you would change. In 2026 include at least one AI feature spec with an evaluation set, ship threshold and fallback.
Hiring managers do not want screenshots.
The 6 projects
Product teardown with three ranked improvements
The question: Who uses this product for what job, where does it frustrate them and what would you change first?
- Start with
- An app you use daily, plus 5 short user interviews or 20 app-store reviews you read and code by theme.
- Steps
- Define one user and the job they hire the product for.
- Walk the main flow and mark friction points with screenshots.
- Back each friction with evidence (interview quote, review count).
- Propose three changes; score with RICE and rank them.
- State one metric you would watch for the top change.
- Measure
- Each proposal links to evidence and states the metric it should move.
- Ship
- A 3 to 5 page document.
- Why it counts
- Shows structured product thinking from a single, accessible artefact.
Wrote a teardown of [product]: coded [n] reviews and [m] interviews, ranked 3 improvements with RICE and defined success metrics.
Onboarding funnel audit from real event data
The question: Where do users leave between first view and purchase, and which experiment would you run first?
- Start with
- Retailrocket e-commerce events or the Olist tables, as in the analytics projects.
- Steps
- Build the funnel and step-to-step conversion.
- Split by new vs returning users and by device if available.
- Choose the biggest, most fixable drop.
- Write the hypothesis, change and success metric for one experiment.
- Measure
- Counts reconcile at each step and the hypothesis names a primary and a guardrail metric.
- Ship
- Funnel chart and a one-page experiment brief.
- Why it counts
- Evidence-based prioritisation, the heart of the job.
Audited a [n]-event purchase funnel; found the largest drop at [step] and specified an experiment with primary and guardrail metrics.
AI feature PRD with an evaluation pack
The question: How will you know an AI feature is good enough to ship, and what happens when it is wrong?
- Start with
- Pick one feature, for example an LLM that drafts support replies, summarises meetings or suggests product descriptions.
- Steps
- Write the problem, users and success metrics as in a normal PRD.
- Add the AI sections: model approach and why, data needs, risks and abuse cases.
- Build a golden set of 30 cases tagged happy path, edge and adversarial; write the ideal output for each.
- Set a ship threshold and a separate rollback threshold (for example pass rate, harmful-output rate, cost per request).
- Define fallbacks, human review and a staged rollout.
- Measure
- Every requirement ties to a test in the golden set and an owner for the decision to ship.
- Ship
- PRD plus the golden-set sheet and a rollout one-pager.
- Why it counts
- Directly matches what AI product teams ask for and what most portfolios lack.
Wrote an AI feature PRD with a 30-case golden set, ship and rollback thresholds, fallback design and staged rollout plan.
Eval library for an AI product
The question: Can you define quality for an AI product in a way a team can test?
- Start with
- A product you can access, such as a chatbot, a writing assistant or a search feature.
- Steps
- List 15 to 20 behaviours that matter (accuracy, tone, refusal, safety, format).
- For each, write 3 input examples, the expected output and a scoring rubric.
- Run a model on all of them and score the results.
- Identify the three worst failure types and propose product fixes.
- Measure
- Rubrics are specific enough that two people would score the same way.
- Ship
- Eval sheet and a two-page findings memo.
- Why it counts
- Evidence that you can turn vague quality goals into testable ones.
Built an eval library of [n] test cases with scoring rubrics for [product]; identified [k] failure patterns and proposed mitigations.
Experiment plan with sample-size maths
The question: How large must the test be, how long will it run and what decision rule will you use?
- Start with
- Choose a real metric, for example checkout conversion at 10% with a hoped-for lift to 11%.
- Steps
- State hypothesis, primary metric and guardrails.
- Compute sample size per variant (worked example below).
- Convert to run time from daily traffic.
- Pre-write the decision rule: ship, stop or extend.
- Measure
- The plan can be run by someone else without extra questions.
- Ship
- One-page experiment plan.
- Why it counts
- Experiment design is a staple of PM interviews.
Designed an A/B experiment plan with power analysis (n = [x] per variant) and pre-registered decision rules.
North Star metric and metrics tree dashboard
The question: Which single metric best captures the value users get, and which inputs move it?
- Start with
- Any product with public numbers, or your own side project.
- Steps
- Define the value moment and choose a North Star.
- Break it into 3 to 4 input metrics (breadth, depth, frequency, efficiency).
- Add guardrail metrics.
- Mock up the dashboard and write what each chart would change.
- Measure
- Each input metric has an owner and a lever.
- Ship
- Metrics tree diagram and dashboard mock-up.
- Why it counts
- Shows you can connect strategy to measurement.
Defined a North Star and input-metric tree for [product]; specified guardrails and a dashboard used to prioritise roadmap bets.
12 more project ideas
Shorter briefs for when you want a different angle. Apply the same rules: a real source, a baseline, a number and a README.
Pricing page redesign case
BeginnerDocs, a survey, competitor screenshots
DataA SaaS product you use
Stand-outWillingness-to-pay evidence from 20 responses
Churn interview synthesis
IntermediateInterview notes, affinity mapping
Data10 users who stopped using a product
Stand-outThree root causes with quotes and a ranked fix list
Feature-flag rollout plan
BeginnerDocs, metrics tree
DataAny feature idea
Stand-outKill criteria written before launch
Accessibility audit and roadmap
IntermediateWCAG checklist, screen reader
DataA public app
Stand-outIssues ranked by user impact with effort estimates
Metrics definition document
IntermediateSQL, data dictionary
DataA product with event data
Stand-outEvery metric with a query, owner and known gaps
Onboarding redesign with prototype
IntermediateFigma, user tests
DataA product's first-run flow
Stand-outTask completion rate before and after on 5 testers
Competitive teardown of three AI features
IntermediateDocs, screenshots, eval prompts
DataCopilots in three products
Stand-outQuality scored on the same 20 prompts across products
Go-to-market plan for a campus product
BeginnerDocs, spreadsheet
DataA real student problem
Stand-outChannel plan with cost per acquisition estimates
Support-ticket to roadmap pipeline
BeginnerSpreadsheet, tagging
Data200 public app reviews
Stand-outTheme sizing by frequency and severity
Retention cohort story
IntermediateSQL, charts
DataAny event dataset
Stand-outOne insight that changes a roadmap decision
AI feature risk register
IntermediateDocs
DataAny AI feature idea
Stand-outAbuse cases, mitigations and owners
Product requirements for an MCP-based integration
AdvancedDocs, API reading
DataA tool you want an assistant to use
Stand-outPermissions model and evaluation plan
Worked example: sample size for an A/B test
Baseline conversion 10%, you want to detect a lift to 11% (1 percentage point), 5% significance (two-sided) and 80% power. Using the standard two-proportion approximation gives about 14,750 users per variant.
from math import ceil
z_alpha, z_beta = 1.959964, 0.841621 # 5% two-sided, 80% power
p1, p2 = 0.10, 0.11
p_bar = (p1 + p2) / 2
n = 2 * (z_alpha + z_beta) ** 2 * p_bar * (1 - p_bar) / (p2 - p1) ** 2
print(ceil(n)) # about 14,752 per variantWith 2,000 eligible users a day split across two variants, that is roughly 15 days. Halving the detectable lift to 0.5 points roughly quadruples the sample. Say that trade-off in your plan.
Case-study template that gets read
- Problem: who, what job, what evidence.
- Approach: methods and why you chose them.
- Decisions: options considered and the trade-off you accepted.
- Evals and metrics: how success was measured, with the baseline.
- Outcome: results or expected impact, with limits.
- What I would do differently.
Additions to a PRD when the feature uses AI
| Add this | Why |
|---|---|
| Example input, bad output, good output | Makes quality concrete for engineers and reviewers |
| Golden set (30+ tagged cases) | Lets you test changes and compare models |
| Ship threshold and rollback threshold | Decides in advance when to launch and when to pull back |
| Fallback behaviour | What the user sees when the model is unsure or wrong |
| Human review path | Where a person approves or corrects |
| Cost per request and latency budget | Constraints that change the design |
| Abuse and privacy cases | Prompt injection, personal data, harmful content |
Formats that work
| Format | Best for |
|---|---|
| Three deep case studies on a Notion page | Most applications; easy to link |
| GitHub repo plus live demo with a product README | AI PM and technical PM roles |
| PRD plus eval pack plus rollout one-pager | AI product roles |
| Public writing (a series of posts) | Building a reputation and attracting inbound interest |
Aim for three to five finished pieces. One excellent case study beats ten thin ones.
Frequently asked questions
What projects should I include in a product management portfolio?
Include a product teardown, a data-based funnel audit, an experiment plan and, for AI roles, an AI feature PRD with an evaluation set. Three to five finished pieces are enough.
How do I build a PM portfolio with no experience?
Use public products and public datasets. Interview a few users, analyse real event data and write decisions with evidence, as in the teardown and funnel audit.
What is an eval pack in an AI PRD?
A set of tagged test cases with expected outputs and scoring rubrics, plus ship and rollback thresholds, used to decide whether an AI feature is good enough to launch.
How many case studies should a PM portfolio have?
Three to five. Quality and depth matter more than volume.
Do product managers need to code or know SQL?
Not necessarily, but SQL for funnels and basic experiment maths make your case studies more credible.
Where should I host a PM portfolio?
A Notion page or a simple site, linked from LinkedIn and your resume, with a GitHub repo for any demo.
Learn this with mentors
Product management programmes with admissions open: live classes, mentors and project work.
