Phase 4: Writing AI Product Requirements · 140 min · Product Compass AI PRD template · Markdown · Python

Project: Full AI Feature PRD

This is the document a hiring manager actually reads. Everything else in this phase was practice for writing it once, completely, under real constraints.

Hiring signal: The build plan's portfolio-hiring research is unambiguous: 'a working AI prototype + PRD with documented trade-offs (latency/cost, hallucination framework)' is named as one of the highest-leverage project types for a transitioning AI PM candidate. This capstone produces exactly that artifact, for the same feature carried from the Phase 2 opportunity assessment — a single, coherent, portfolio-ready PRD that a hiring manager can read start to finish and see every skill this phase taught applied to one real decision, not five disconnected exercises.

What you will learn

Assemble a problem statement, success criteria, non-deterministic acceptance criteria, prompt spec, failure design, guardrails, and cost model into one coherent PRD
Write eval criteria as a PRD section that hands off cleanly into the Phase 5 evaluation plan
Produce a 3-stage cost and latency model for a specific, previously-scoped feature rather than a hypothetical one
Identify and document the explicit handoff points from this PRD into the Phase 5 eval plan and the Phase 7 responsible AI review

The Problem

A candidate applying for an AI PM role submits a portfolio with five separate exercises: a problem statement, a success-metrics table, a prompt spec, a failure-mode list, and a cost model — each polished, each from a different hypothetical feature, none of them connected. The hiring manager reading it gets five demonstrations of isolated skill and zero demonstration of the thing the job actually requires: holding all of those decisions in your head at the same time, for one real feature, where the acceptance criteria constrain the prompt spec, the prompt spec has cost implications, the cost model forces a guardrail tradeoff, and the guardrails shape what the eval plan needs to check. A PRD is not five separate deliverables stapled together — it's one coherent argument where every section is load-bearing for the others, and a portfolio that can't show that coherence hasn't actually demonstrated the skill, no matter how good any individual section is in isolation.

This project exists to fix that. You're not writing a new hypothetical PRD — you're writing the complete, real PRD for the exact feature you scoped in Phase 2's opportunity assessment, using every skill this phase built: a problem statement that survives having "AI" deleted from it (Lesson 1), acceptance criteria specified as a behavior range instead of an exact output (Lesson 2), a versioned prompt spec (Lesson 3), explicit failure-state and escalation design (Lesson 4), and a 3-stage cost and latency model grounded in real token economics (Lesson 5). This lesson adds the two pieces that turn those five sections into a shippable document: eval criteria that hand off cleanly to Phase 5, and an explicit statement of what carries forward into Phase 7's responsible AI review. When you're done, this single document should read the way a real PRD reads to an engineering team that has to build from it — not as a demonstration that you learned five separate concepts, but as one decision, fully reasoned through.

Why Eval Criteria Belong in the PRD, Not Just the Eval Plan

It's tempting to treat evaluation as entirely Phase 5's problem — write the PRD now, figure out how to test it later. That sequencing produces PRDs whose acceptance criteria sound rigorous but were never actually checked against "could someone build a test from this." Writing eval criteria as a PRD section, even in outline form, is a forcing function: if you can't state roughly how you'd verify a given acceptance criterion or guardrail is being met, you probably haven't specified it precisely enough yet, and it's far cheaper to discover that now than after Phase 5 tries to build a golden dataset against underspecified criteria. This PRD's eval-criteria section doesn't need the full rubric, scoring methodology, or golden dataset design that Phase 5 will build — it needs to name, for each major acceptance criterion and guardrail from Lesson 2, what category of eval would check it (a rubric-scored human eval, an automated faithfulness/grounding check, a red-team-style adversarial test, a simple pass/fail assertion) so that Phase 5 starts from a mapped list instead of a blank page.

A PRD that names its eval approach per-criterion is a fundamentally different artifact than one that doesn't
Compare "the system should not leak confidential information" (a guardrail with no stated verification approach) against "the system should not leak confidential information — verified via an automated red-team suite of 50+ adversarial prompts run on every prompt-spec version before deployment" (the same guardrail, with its verification method named). The second version is checkable, assignable, and arguable in a design review; the first is a hope. You don't need Phase 5's full rubric here — you need one sentence per major criterion naming the verification category, which is exactly the discipline a hiring manager is checking for when they read this section of your portfolio PRD.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers Assembling the Document, Build It, What to Practice — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.