Skip to content

PRD as Destination, Not Compiler Spec

matt-pocock's stance on the role of the product-requirements document in an agentic workflow: it is a reference destination that orients subsequent sessions, not an input to a "specs-to-code compiler."

"We're going to write a product requirements document … it's the destination documents. And it sort of doesn't matter what shape it is. … All we're really doing is summarizing the design concept that we have so far." — Pocock, 30:35–31:10

Position

Pocock explicitly argues against the "specs-to-code movement":

"You don't need to worry about the code. You just sort of keep editing the specs and eventually you just keep going. And I tried this. I really tried it. And it sucks. It doesn't work. Because you need to keep a handle on the code … the code is your battleground." (13:09–13:42)

The PRD's job is therefore minimal:

  1. Summarise the alignment achieved during the grilling session so a fresh session can pick up the thread after a clear.
  2. Shape subsequent planning — it feeds the PRD→issues skill that emits vertical-slice Kanban tickets (see tracer-bullets).
  3. Die gracefully. Keeping old PRDs in the repo invites doc rot — agents will re-read a PRD whose requirements/file-structure have since diverged, and degrade. Pocock deletes or closes them once the feature lands (he stores them as GitHub issues and marks closed).

Corollary: don't over-polish

Asked whether to run a deep-reasoning model to iterate the PRD toward optimality, Pocock rejects it: "I don't think there's a lot of value in that. … The place that you need to be putting the work is in QA." (~2:04:00)