Prototype Over PRD

Sources#

• Designing with Claude: From prompt to production
• OpenAI Codex lead on the new shape of product work

Summary#

Dan Carey's account of how the Claude Design team replaced product requirements documents with prototypes during a ten-week build inside Anthropic Labs. The thesis: documents are imprecise; prototypes are concrete. Two people reading the same PRD build two different products in their heads, and usually neither matches what the author intended. A prototype removes that ambiguity — it is visceral, hands-on, and you feel the experience directly. Carey, a PM who has "been writing [PRDs] for almost two decades," says prototypes have "effectively replaced PRDs for me." This is the most extreme point on the wiki's spectrum of PRD-skepticism: not lighter PRDs (AI Native Product Cadence) and not PRD-as-downstream-of-alignment (Design Concept Grilling), but no PRD at all — the prototype is the spec.

The mechanic (the reusable part)#

Carey's repeatable flow, which got the team's prototyping cycle "down to a couple of minutes":

1. Talk it through with a teammate about the problem — and record the conversation.
2. Talk about why, not what. Explicitly: do not describe the feature, the buttons, the screens. Talk about why the problem matters and what the characteristics of a good solution are.
3. Transcribe the conversation (any transcription tool).
4. Hand the transcript to Claude / Claude Design and ask for "a few options" — three variations on a prototype that might solve it.
5. Get hands-on with the variations and react.

The "why not what" rule is load-bearing: it leaves the what to the model, so the prototype can surprise you instead of merely transcribing your prior assumptions into UI. This is the same under-specify-and-let-capability-fill move that HTML as the New Markdown applies to plans (and that the bitter lesson states as a principle).

Why a prototype beats a document#

"It's so easy for two people to look at the same doc and have two different products in mind… and usually those two ideas are not the same idea that the author had."

Docs are imprecise; prototypes are concrete, visceral, and let you "really feel the experience yourself." The artifact carries more information than the description of it — the same logic Fiona Fung applies to technical debates in Building Is Cheap, Arguing Is Expensive ("generate three PRs and compare" rather than whiteboard). Carey's contribution is to push that logic upstream from deciding between implementations to authoring the spec itself.

What the team deliberately did not do#

Carey lists the planning artifacts the team skipped, because "those things are great if you know exactly what you're building" — and they did not:

• No PRD written in advance
• Zero vision docs
• Zero OKR meetings
• No H1 annual staffing plan
• No two-year plan
• No press-release-in-advance

"All we knew is that we had a spark." Removing these is what Compounding Loop Optimization frees up time to reinvest in iteration, and is the planning-minimization half of AI Native Product Cadence.

Pitch-offs: the proof point#

The team's "pitch-off" ritual (brainstorm sessions where people try to recruit collaborators onto a bet) became the evidence that the prototype-as-spec approach worked. The first time they ran one with Claude Design, "100% of the pitches were prototypes or slides made with Claude Design… being made on the fly in the meeting." When the spec-authoring tool is fast enough to use live in a brainstorm, the prototype stops being a downstream deliverable and becomes the medium of thinking itself.

Where this sits among the wiki's PRD positions#

Position	Source	Stance on the PRD
Lighter PRDs	AI Native Product Cadence (Cat Wu)	1-pagers for ambiguous features; full PRD only for heavy infra
PRD as destination doc	Design Concept Grilling (Matt Pocock)	Reach the design concept by grilling first; the PRD is downstream of alignment and deleted after
Build to decide	Building Is Cheap, Arguing Is Expensive (Fiona Fung)	Generate three real PRs and compare; reduce design docs
Prototype is the spec	This page (Dan Carey)	Skip the PRD entirely; a why-conversation → Claude → 3 prototype variations replaces it
Pick the medium	Implementation Abundance Inverts Product Work (Andrew Ambrosino)	"PRDs are not dead" — abundance makes medium-choice the skill; a doc is right for product clarity, a prototype for stress-testing an interaction; the prototype is one option, not the default

The reconciliation the wiki already holds (from Building Is Cheap, Arguing Is Expensive): cheap building doesn't abolish design thinking — it relocates it into the built artifact. Carey takes the relocation furthest. The standing tension is Design Concept Grilling's warning that you still need a shared design concept before building; Carey's answer is that the why-focused conversation (recorded, fed to the model) is where that alignment happens, and the prototype is its first expression.

The counter-nuance: "PRDs are not dead — pick the medium" (Ambrosino)#

Andrew Ambrosino (OpenAI Codex) is the wiki's explicit dissent from the slogan Carey embodies. He names the "PRDs are dead, prototypes are in" line and says "I actually don't believe this at all." His reasoning tightens the whole cluster rather than contradicting it: because implementation got cheap across every medium (Implementation Abundance Inverts Product Work), the skill is no longer "prototype instead of writing" — it is choosing the right format for the point you're making:

• Jumping straight to a prototype is the temptation for non-engineers ("I've never been able to write code — let me just show you what I mean").
• Writing a wall of documents is the temptation for engineers — "a lot of documents that are not worth reading."
• The discipline: "if implementation is abundant, it's really important to pick the right format. If the point is product clarity around a vague area, it might be a document. If it's getting something in people's hands to stress-test an interaction pattern, it's a prototype."

So Ambrosino sits beside Carey, not against him: the prototype-as-spec is one correct medium-choice (visual/interaction problems), but promoting it to a universal replacement re-introduces the imprecision Carey was fleeing — this time as unread docs or over-anchored prototypes (Polish No Longer Signals Readiness). The wiki's PRD spectrum is best read as "match the medium to the risk," with Carey marking the prototype pole and Ambrosino naming the selection rule.

Connections#

• Dan Carey — articulates the method
• Design by Selection — the same loop at option-set scale: "generating 15 versions of a flow to collect feedback from colleagues" makes the circulated artifact the spec, and Nate Parrott states the payoff — as models get better at building production software, the work that matters moves earlier, to ideas, alignment, and early feedback
• Claude Design — the tool that makes the prototyping cycle fast enough to replace the PRD
• Compounding Loop Optimization — skipping planning artifacts is one step the team optimized away; this is its spec-authoring counterpart
• Build for the Next Model — you prototype the thing that almost works; prototype-over-PRD is how you author that bet quickly
• Building Is Cheap, Arguing Is Expensive — the sibling "built artifact beats abstract argument," applied to debates rather than specs
• Code as Source of Truth — the same rationale-capture gap from the other end: Fung deletes the doc because code is truth, Carey deletes it because the prototype is the spec; both leave the "why" homeless
• Design Concept Grilling — the productive tension: grilling reaches a design concept before building; Carey folds that alignment into the recorded why-conversation
• AI Native Product Cadence — lighter-PRD cadence; Carey is the limit case (no PRD)
• HTML as the New Markdown — opposite-direction bet: Thariq makes the plan artifact richer (interactive HTML); Carey replaces the plan artifact with a prototype; both keep the human engaged without a wall of prose
• Evals as Product Spec — the same relocation applied to eval-authoring: in Google's flywheel the coding agent writes the eval while the human states the worry and approves, as prototypes displaced PRD-writing here
• Implementation Abundance Inverts Product Work — Ambrosino's frame that the skill is medium-choice + curation, not prototype-by-default; the counter-nuance to prototype-as-universal-spec
• Polish No Longer Signals Readiness — why "just prototype it" backfires: the prototype looks shippable and over-anchors the team
• Andrew Ambrosino — voices the "PRDs are not dead" dissent
• Unknowns as the Agentic Bottleneck — a third use for the same artifact: Thariq Shihipar builds prototypes as elicitation instruments (several wildly different directions, to surface the I-know-it-when-I-see-it criteria) rather than as the spec
• Prototype Fidelity After Cheap Polish — the fidelity question this method leaves open: if the prototype is the spec, how polished should it be, and what does the polish do to the feedback it is meant to gather

Open Questions#

• If there is no PRD, where does the rationale ("why we chose variation B") live for future readers? Same rationale-capture gap flagged in Building Is Cheap, Arguing Is Expensive. Partially answered: Where Does the Why Live? — the why is well-homed at authoring time (it is the recorded why-not-what conversation) but orphaned at read time, since the artifact that carried it is deleted. Still open: whether a durable read-time home exists that doesn't reintroduce the PRD.
• The prototype-as-spec must not become the prototype-as-validation trap Problem-Solution Fit Discipline warns about: a fast prototype proves the build was solvable, not that the problem is real.

Resolved Questions#

• Where does prototype-over-PRD break down? Carey's domain is a visual design tool where a prototype is the product surface; for backend/infra/data work the prototype may not capture the spec (cf. AI Native Product Cadence's "full PRD for heavy-infra features"). Answered: Playbook Boundary Conditions: the Devil's-Advocate Substrate and the Prototype's Edge — the boundary is observable-surface-vs-invariant, not backend-vs-frontend: every domain has its own tracer artifact (three PRs, vertical slice, ten evals, design_system.html), so what breaks at the backend is the clickable prototype, not artifact-over-document; the PRD survives where no artifact's surface covers the risk — cross-cutting invariants and cross-team coordination.

Derived#

• The PRD-Replacement Spectrum at AI-Native Speed — the right pole of the spectrum: the prototype is the spec; both this page's open questions (orphaned rationale, prototype-as-evidence) are the spectrum's two unsolved debts
• Where Does the Why Live? — focused answer to this page's rationale open question: the why is well-homed in the recorded why-conversation but orphaned for future readers
• Playbook Boundary Conditions: the Devil's-Advocate Substrate and the Prototype's Edge — resolves the breakdown-boundary question: the cut is observable-surface-vs-invariant, and each non-visual domain substitutes its own tracer artifact rather than reverting to the PRD

Sources#

• Designing with Claude: From prompt to production
• OpenAI Codex lead on the new shape of product work — Ambrosino: "PRDs are dead, prototypes are in… I actually don't believe this at all"; pick the medium for the point