Skip to content

10 · Project — Write a Complete PRD

This project combines every module in Level 1 into one real deliverable: a complete PRD for a sample feature, built the way a working PM actually would — starting from a chosen product and a real (or realistically invented) signal, through discovery, prioritization, and requirements, ending in a document engineering and design could genuinely build from.

What you'll produce

One PRD document containing all of the sections below, for a feature of your choosing on a product you pick (a real product you use, or one you invent with a clear description). Use the sample scenario below if you'd rather work from a provided starting point than choose your own.

Sample scenario (use this, or substitute your own product + signal)

Product: "ListUp" — a B2B SaaS tool for small e-commerce sellers to manage product listings across multiple marketplaces (their own site, plus two third-party marketplaces).

Signals received this month: - 7 support tickets from sellers asking "why didn't my price update show up on Marketplace B" (turns out: sync has a 4-6 hour delay, undocumented). - A churn-exit interview citing "I stopped trusting the tool because prices looked wrong to customers." - Weekly active usage is flat among sellers who list on 2+ marketplaces, while it's growing among single-marketplace sellers.

Step 1 — Discovery (Module 3)

Write a validated problem statement using the template from Module 3: who is affected, what pain, what situation, what consequence, and what evidence supports it. Do a rough opportunity sizing pass (Module 3's sizing table) — how many accounts affected, what's the business risk if unsolved, how confident are you in the cause.

Step 2 — Prioritization (Module 4)

Invent 2-3 other plausible competing initiatives ListUp could work on instead (e.g., a new marketplace integration, a bulk-editing tool, a mobile app). RICE-score all of them, including your chosen initiative, in a table. Justify in 1-2 sentences why your initiative should (or perhaps should not!) win the top spot — it's fine if your honest RICE scoring doesn't rank it first, as long as you explain the reasoning.

Step 3 — Requirements (Module 5)

Write the full PRD using the standard sections from Module 5:

  • Problem statement (from Step 1)
  • Goals / success metrics (tie to a North Star or AARRR stage — Module 7)
  • Non-goals (at least 3 — be specific about what's explicitly excluded)
  • User stories with acceptance criteria (at least 3 stories, each with Given/When/Then acceptance criteria)
  • Open questions (at least 2 genuine unknowns)
  • Launch plan (rollout approach)

Step 4 — Collaboration notes (Module 6)

Add a short section: a 3-5 sentence design brief you'd hand a designer before they sketch anything, and one tradeoff you anticipate coming up during the build (speed vs. scope, or similar), noting who you'd loop in to help decide it.

Step 5 — Roadmap context (Module 8)

Add one paragraph placing this initiative on a Now/Next/Later roadmap theme — which theme does it belong to, and what horizon/confidence level.

Step 6 — Stakeholder plan (Module 9)

Add a short stakeholder map (at least 4 stakeholders, using the influence/interest grid) and a sample status update (using the 4-question structure) as if you're reporting progress two weeks into the build.

Self-review checklist

Before considering the PRD done, check it against these questions — this is the same bar a real design/engineering review would hold it to:

  • [ ] Would two different engineers reading this build roughly the same thing, or is there room for very different interpretations?
  • [ ] Does every user story have acceptance criteria specific enough to test against?
  • [ ] Are the non-goals specific enough to prevent a real scope-creep argument, not just generic filler?
  • [ ] Is the success metric numeric, with a stated baseline?
  • [ ] Could someone unfamiliar with the backstory read the problem statement and understand why this matters, without asking you to explain it out loud?

How It Actually Works

A complete PRD earns its cost by acting as a shared, falsifiable artifact that converts implicit assumptions into explicit, arguable claims before money is spent building them. The mechanism is that any unstated assumption is, by definition, untested — and untested assumptions surface as expensive surprises at the worst possible time (mid-build or post-launch) rather than the cheapest possible time (a five-minute read-through). Sectioning a PRD into problem, goals/non-goals, requirements, and success metrics works because it maps directly onto the four places a project can silently fail: solving the wrong problem, solving an unbounded problem (scope creep from missing non-goals), building the wrong thing (ambiguous requirements), or being unable to tell afterward whether it worked (no success metric defined upfront, which lets everyone retroactively declare victory regardless of the actual outcome — a well-known bias called outcome reframing). Non-goals specifically function as a pre-negotiated scope fence: without them, every stakeholder's pet feature is implicitly "maybe in scope," and every one of those ambiguities becomes a negotiation that happens live, under deadline pressure, instead of calmly on paper weeks earlier.

Exercise

Assemble the complete PRD from Steps 1-6 above into a single document (use whatever editor you like — Google Docs, Notion, plain markdown). Run it through the self-review checklist and revise anything that doesn't hold up.

Completing this project means you're ready for Level 2 · Intermediate.