Product Manager project
Turn a one-line feature request into a real PRD
A vague ask like "add dark mode" rewritten as a full PRD — graded on whether it reasons from the user problem, not straight to the solution.
The brief
Start from a vague, one-line feature request grounded in a real product you use (e.g. "add dark mode", "let users export their data"). Write a full PRD covering the problem statement, the target user, success metrics, explicit scope and non-goals, and at least two open questions you would raise with engineering before work starts.
Suggested stack
What you hand in
- A published, viewable doc link (Google Docs or Notion, set to "anyone with the link can view")
- The PRD includes problem statement, target user, success metrics, scope/non-goals, and open questions as separate labeled sections
- A one-paragraph note on what you'd cut first if the timeline got cut in half
Grading happens against the rubric below, so read it before you start — not after.
How this is graded
Published in advance and weighted out of 100. Nothing here is a surprise.
The problem statement describes what's wrong for the user today, not a restatement of the requested feature as the problem.
Metrics are specific and tied directly to the stated problem (e.g. "reduce data-export support tickets by X%"), not a vague vanity number.
The non-goals section names things this PRD deliberately does not cover, preventing the obvious scope-creep additions a stakeholder would suggest.
The open questions show awareness of real technical or design trade-offs, not generic questions like "how long will this take?".
No console errors or crashes, no broken layout, no leftover placeholder text or commented-out code.
Why this project is worth your weekend
- Turning a one-line ask into a scoped PRD is the actual daily job, and it's exactly what most junior PM candidates skip past straight into solutioning.
- Success metrics tied to the real problem are what separates a PM from a project coordinator who just tracks a feature to completion.
- A stated non-goals section is what prevents a real team from scope-creeping a two-week feature into a two-month one.
Where people lose points
- Writing a PRD that describes the solution ("add a toggle in settings") without ever stating the user problem it solves.
- Success metrics that are vanity numbers ("increase engagement") with no defined way to actually measure them.
- No non-goals section, so the doc invites scope creep from every stakeholder who reads it.
Other Product Manager projects
Two or three of these turn an empty resume into a portfolio.
Built it? Get it scored against this rubric.
Submit your work and get a score on every criterion above, written feedback, and three resume bullets you can use straight away.