Prototype Over PRD

Sources#

• Designing with Claude: From prompt to production

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

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.

Connections#

• Dan Carey — articulates the method
• 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
• 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

Open 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").
• 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.
• 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.

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

Sources#

• Designing with Claude: From prompt to production