Junior PM Portfolio: Turn One Project Into a Case Study
Janus Choi, 26, sat down at his laptop and opened his portfolio page.
He was lining up companies to apply to as a junior product manager. His first move: put his capstone project on the front page.
He stared at the screen and stopped. Two service flow diagrams and a single line of description.
A peer-to-peer marketplace for college students.
He'd spent a full year on market research, user interviews, and an MVP beta — but only the deliverable diagrams made it onto the portfolio.
It might give the impression of "decent documentation," but what Janus had actually decided over that year, and why, wasn't visible at all.
Plenty of junior PMs hit this same wall. The good news: the missing information is actually quite specific.
Let's walk through what to add and how to add it, alongside Janus.
The trap of portfolios that only show results
The most common junior PM portfolio looks like this:
Project — College Student Marketplace App
Role — Product Planning, Market Research
Duration — 1 year (4-person capstone)
Tools — Figma, Notion, Miro
Deliverables — Service flow, IA, feature spec, MVP wireframes
Now imagine a recruiter or PM lead reading this. What goes through their head?
"OK, clean documentation."
That's where it ends.
Nothing reveals what market insight came up, why these features were chosen and what was cut, or what options were considered and discarded.
The form of the planning artifacts is there, but the decision-making behind them isn't.
The real value of a PM's portfolio isn't "what did you plan." It's "why this plan?"
Documentation alone only shows "they can produce planning artifacts." But what hiring teams really want to see in a PM is: does this person decide based on market and users?
For PMs especially, the decision process hinges on "what did you decide not to do?" A good spec isn't one that includes every feature — it's one where what got cut was cut precisely.
That's where the case study format comes in. A case study has three beats:
Problem — Process — Result
Fill in those three, and a person starts to emerge from the portfolio.
Let's walk through each beat using Janus's college marketplace.
Problem: What were you solving, and for whom?
This is the part most often skipped — the "in what market, for whose pain" question.
Janus's first draft read:
[Before]
Designed a mobile app so college students could buy and sell secondhand items safely and conveniently.
What can a hiring team actually pull out of this? Two things: the target is college students, and it's a marketplace app.
Nothing about what market context or user pain he actually found. It sounds like the project started from a generic premise — "student secondhand trading is inconvenient."
So we asked Janus: "Facebook Marketplace and OfferUp already exist. Why a separate college-only app?"
His answer:
That was exactly my first question, so I started with market research. I ran a survey with 30 students and did 10 follow-up interviews, mostly with people living off-campus. What came back was more interesting than I expected.
Students do use Facebook Marketplace and the campus 'Free & For Sale' group, but they get frustrated by specific things. 'I can't tell if the seller is actually a student.' 'Coordinating where to meet eats up half a day.' 'Off-campus buyers lowball everything and want me to drive 30 minutes to meet them.' What they really wanted was to trade with other students at their own school — but the existing tools didn't give them that as a unit, so a lot of trades just didn't happen.
That insight needs to go straight into the portfolio.
[After]
Existing options like Facebook Marketplace, OfferUp, and campus 'Free & For Sale' Facebook groups were already in use, but a 30-student survey plus 10 follow-up interviews surfaced three recurring pain points: uncertainty about whether the seller is actually a student, the friction of coordinating meetup logistics, and fatigue from off-campus lowballers. What students actually wanted was to trade within their own campus, but no existing tool packaged trades around that unit — and as a result, many students gave up on listing or buying. Solving that pain became the core goal of my capstone.
The After version is longer, but the information density is much higher.
What market context, whose specific pain, and why existing solutions don't address it — all of it is there.
Three questions to cover in the problem section:
Market context — What's already in this space?
User pain — What pain isn't being solved by existing tools? (Verified by research, not assumed.)
Entry rationale — Why now, and why is this the right angle to attack it?
In PM case studies especially, the first one — defining pain on top of market context — is decisive.
If you describe building something without acknowledging the existing options, the hiring team reads it as "this person doesn't look at the market."
Process: What went in, and what got cut?
This is the heart of a case study.
It's the easiest section to skip, and for a PM, the most valuable one to include.
Most junior PM portfolios stop at "what features I included":
[Before]
Defined core features including student verification, school-specific trade channels, campus pickup spots, and in-app chat-based payments.
This tells the reader, "OK, they wrote a feature spec." But that's not what PM leads actually want to know.
What they want is: "What did this person decide not to do, and why?"
The biggest planning decision in Janus's marketplace was: should the MVP be focused on a single campus, or connect students across multiple schools?
The initial concept was multi-school. Any college student in the country could sign up and trade. The rationale was market size and faster user acquisition.
But two insights came out of the user interviews:
"If I'm trading with students at other schools, how is this different from Facebook Marketplace?" — multi-school was actually blurring the differentiator
"I'm not driving to another campus to pick something up." — distance was a deciding factor in whether trades happened at all
Janus took those insights and narrowed the MVP scope.
[After]
The initial concept was a multi-school platform open to college students nationwide. The rationale was market size and faster user acquisition.
But two things surfaced in interviews. First, students saw no real benefit in trading with students at other schools. "Then how is this different from Facebook Marketplace?" came up in 7 of 10 interviews. Second, willingness to trade dropped sharply with distance, and cross-campus travel was effectively a deal-breaker.
Taking those in, I narrowed the MVP to single-campus focus. The addressable market shrinks, but the differentiator sharpens. Features only possible at a single-campus scope — designated campus pickup spots, in-classroom handoffs, student ID verification — became the core differentiators. Multi-school expansion got pushed to a later phase: "validate the model on one campus first, then replicate per school.".
Look at what's actually in that paragraph:
Started from a hypothesis → This person works from hypotheses.
Validated the hypothesis with users → This person tests their thinking against the market.
Narrowed scope based on what they found → This person knows how to decide not to do something.
Drew an expansion path alongside the cut → This person thinks short-term and long-term together.
The same "I planned a college marketplace" outcome lands completely differently depending on how it's written up.
Three things to cover in the process section:
Initial hypothesis — What did you start by believing?
Insight and scope decision — What did you find, and how did you narrow scope?
Tradeoffs and expansion path — What did you give up, and when will you revisit it?
The "expansion path" piece is especially powerful for PM portfolios.
A common trap for junior PMs is framing "what I couldn't do" purely as a limitation. But hiring teams trust the framing of "I decided not to do this now, and I know when and how to revisit it" much more.
"Multi-school expansion was deferred to a per-campus replication model after single-campus validation" reads far more three-dimensionally than "I wanted to build a national service but ran out of time, so I only did one campus."
Result: How did your hypothesis hold up?
The final beat is result. Many candidates stop at "I finished it," but result has to go further.
[Before]
Completed the MVP prototype and presented at the capstone showcase.
Almost no information. You only learn that they got to the finish line.
A PM's result section should carry two things together: the hypothesis that was validated, and the hypothesis to validate next.
Quantitative — what's measurable
Beta user count, trade completion rate
Pickup satisfaction, repeat trade rate
Signup conversion, average time to trade completion
Qualitative — what numbers can't capture
User quotes ("The campus pickup spot was the deciding factor")
Capstone showcase feedback or industry mentor reviews
Retrospective assessment of what got cut
Applied to Janus's capstone:
[After]
I ran a 4-week MVP beta with 50 students from one campus. Trade completion rate was 68% (vs. ~41% on Facebook Marketplace in the same category), pickup satisfaction averaged 4.3/5, and 52% of users who completed a first trade attempted a second within the beta period.
The most common phrase in post-beta interviews was "The campus pickup spot was the deciding factor." That felt like a direct signal that the core hypothesis behind the single-campus decision — "short distances make trades happen" — had been validated.
At the capstone showcase, the most frequent question from faculty and industry mentors was about the decision to drop the multi-school concept, and that became the project's central differentiator.
Both layers are present.
And the "single-campus hypothesis" runs as a consistent thread from start to finish. The result answers exactly the question the problem section opened with.
A tip for when your result feels thin:
Junior PM projects often have small beta populations or end within a single semester. When that's the case, be honest about it — but always pair it with "here's where I got to, and here's the next hypothesis I'd want to test."
The beta stopped at 50 students on a single campus over 4 weeks. The next step would have been adding one more campus to validate whether the "per-school replication" model actually works.
That one sentence shifts the read from "their data was thin" to "they know where they are and what hypothesis they'd test next."
What hiring managers actually read in a PM case study
Let's flip the perspective one more time.
When a PM lead or recruiter reads a junior PM's case study, the questions running through their mind sound like this:
Does this person look at both market and users? → revealed in the problem section
Is it clear what they decided not to do? → revealed in the process section
Do they treat mistakes as decisions? → revealed in hypothesis shifts and scope cuts
Can they verify a hypothesis? → revealed in quantitative + qualitative results
Do they have an honest read on where they stand, and can they plan the next move? → revealed in limits and next steps
When all five answers show up in a single case study, even a junior leaves the impression: this person knows how to work.
That impression doesn't require a brand name on the resume or full-time experience to back it up.
When the flow of decision-making is more visible than the neatness of the documentation, your portfolio finally becomes a place where how you worked is on display.
To close, here's what changed between Janus's one-line draft and the case study version.
[Before]
Capstone: College Student Marketplace App Role: Product Planning, Market Research Duration: 1 year, 4-person team Tools: Figma, Notion, Miro
[After — case study structure]
Project: College Student Marketplace App (4-person capstone, 1 year)
Problem — A 30-student survey + 10 interviews surfaced three pains with existing options: uncertain seller identity, friction in meetup coordination, and fatigue from off-campus lowballers. Students wanted to trade within their own campus, but no existing tool packaged trades around that unit, so many gave up.
Process — Initial concept was multi-school. Interviews surfaced "how is this different from Facebook Marketplace?" reactions and distance as a deal-breaker. Narrowed MVP to single-campus focus, with campus pickup spots, in-classroom handoffs, and student ID verification as the core differentiators. Multi-school expansion deferred to a per-school replication model.
Result — 50-student, 4-week beta on one campus. 68% trade completion rate (vs. 41% market average), 4.3/5 pickup satisfaction, 52% second-trade attempts. Dominant feedback: "The campus pickup spot was the deciding factor."
Role — Lead PM (market research, user research, MVP scoping) Tools — Figma, Notion, Miro Links — Product spec · MVP prototype · Beta operation report
Same project — but the four-line version and the full case study deliver completely different messages to a PM lead.
The first version says "they know the tools." The second says "they know what not to build."
A case study sized for one portfolio page is usually about this length.
Too long, and the hiring team won't read it all. Too short, and the person disappears. When all three beats are present on one page, one project shows enough.
This article covered turning one project into one case study from a PM's perspective.
If you want the developer version, see Part 1 of this series; for the designer version, see Part 2. All three share the same message — "a portfolio that shows how you worked" — approached from different angles.
How to select multiple projects and arrange them on a single page will be the next topic in this series. If one project's case study is a single essay, arranging multiple projects is closer to composing a book.