Taste at Speed

The story

Consider a senior PM at a B2B SaaS company who's been writing PRDs the same way for 12 years. The cycle is familiar: 4 weeks of discovery, 2 weeks of PRD writing, 2 weeks of stakeholder review, 6 weeks of build, 2 weeks of QA, 2 weeks of launch ramp. 18 weeks per major feature. The cycle worked. The PRD was the artifact that aligned engineering, design, and stakeholders. The PM's leverage was in writing it well.

Then a junior PM on the same team — using Claude Code, Cursor, and a stack of prototyping tools — ships a working prototype of an AI feature in 4 days. It's rough. The UI is generic. The error handling is incomplete. But it's functional: a real user can interact with it, real data flows through it, real outputs come out. Engineering can run it. Design can iterate on it. Stakeholders can experience it.

The senior PM's 18-week cycle just got obsoleted. Not because the PRD was bad. Because the prototype-first cycle produced better evidence faster. The stakeholder who reviewed the PRD had to imagine the experience. The stakeholder who reviewed the prototype experienced it. The feedback was an order of magnitude more useful, and it arrived 14 weeks earlier.

This is the death of the traditional PRD. Not metaphorically. The 6-week PRD review for AI features is now actively harmful — it slows feedback, locks in assumptions before reality tests them, and consumes the PM's leverage on an artifact that the team has better alternatives to. The PM's leverage shifts from writing requirements to editing prototypes with taste.

Consider a second team — Anthropic's own product team, building Claude Code. Their public documentation describes a workflow where features are prototyped in days, evaluated against the team's own usage, and refined through rapid iteration. The PRD-equivalent artifact is a short intent document — a paragraph or two that captures the goal, the user, and the success criteria. The detailed specification is the prototype itself. Stakeholders interact with the prototype, suggest changes, and watch them ship in days, not weeks.

Consider a third team — David's Bridal building an MCP-powered assistant. The team treats the MCP server (Model Context Protocol — the standard that lets AI agents access external tools and data) as the spec. Adding a new capability means adding an MCP tool with a clear schema and description. The agent's behavior emerges from the available tools plus the user's request. There's no PRD describing the assistant's behavior in the abstract — the spec is the toolset, and the toolset is editable in hours.

The pattern across all three: the PRD as a 30-page document of requirements is dead. The PRD as a short intent statement plus a fast-iterating prototype is alive. The PM's job is to evaluate prototypes against intent with taste. That's the skill that compounds. That's the skill the 12-year PRD veteran has to learn faster than they're losing it.

The core idea

Traditional SaaS PM rests on the assumption that building is expensive and reviewing is cheap. The PRD existed because the cost of building the wrong thing was high and the cost of writing requirements was low. The PRD was the lever — it made building cheaper by reducing rework.

AI breaks this assumption. Building a working prototype is now cheap (Claude Code, Cursor, MCP tools, scaffolding-as-code). Reviewing a prototype is also cheap (stakeholders run it). But writing a comprehensive PRD that anticipates every requirement is now expensive relative to the alternative — and the alternative produces better evidence.

The PM's leverage shifts. The new high-leverage skill is taste at speed: the ability to evaluate a working prototype against the user's actual needs, identify what's missing, and direct the next iteration in hours rather than weeks. Taste replaces specification as the dominant PM artifact.

The concept — visualized

The 5 Lenses of pretotyping

Pretotyping (a term from Alberto Savoia at Google) is the discipline of testing whether the right thing should be built — before testing whether the thing is built right. AI pretotyping uses 5 lenses to evaluate a prototype on dimensions that predict PMF:

Each lens produces a different type of evidence. A team that runs all 5 lenses on every major prototype catches the failures the PRD review would have missed — because the PRD review can't test workflow restructuring or unit economics.

Where this hits in production

The Anthropic Claude Code workflow is the public reference for taste-at-speed. Features ship in days. The team uses the product daily, dogfooding their own prototypes. The intent document is short. The prototype iterations are visible in the public changelog. The discipline is evaluative, not specificatory. This works at Anthropic because the team has the harness mastery (L1-T01) and the eval discipline (the entire AI Evals series) to know when a prototype is ready to ship.

The David's Bridal MCP example is the tool-as-spec pattern. The team's "spec" for new capabilities is an MCP tool definition: a clear schema, a clear description, a clear set of permissions. Adding a capability means adding a tool. The agent's behavior emerges from the toolset. The PRD-equivalent artifact is the tool catalog. Reviews happen on the catalog, not on a separate document. Iteration speed: hours.

The 1-week prototype sprint is the operational pattern for the rest of us. Block 5 days. Day 1: write the 1-page intent document (goal, user, success criteria). Day 2–3: ship a working prototype with the lowest-rung mechanism from L1-T04 (rules > APIs > RAG > fine-tuning). Day 4: dogfood with 3 target users; collect raw feedback. Day 5: write the next iteration's intent document or kill the project. The cycle replaces the 18-week PRD-build-launch cadence with a 1-week iteration that produces real evidence.

The bias against this pattern is organizational. Senior leaders trained in SaaS PM resist it because the PRD was their leverage. Engineering teams trained in waterfall resist it because they want completed specs before they build. Design teams resist it because they want pixel-perfect mockups before development. The fix is not to litigate the resistance but to demonstrate the result: the team that runs 1-week sprints produces better products faster than the team that runs 18-week PRD cycles. The evidence is the case for the cadence shift.

The trap

Trap 1: Treating "fast prototyping" as a process tweak rather than a craft shift. Teams that adopt 1-week sprints without the taste-at-speed craft produce more prototypes faster, none of which are sharper than the previous ones. The cadence isn't the leverage; the evaluative skill is. Run sprints with weak taste, and you're just generating prototype debt.

Trap 2: Skipping the intent document. Without a 1-page intent statement (goal, user, success criteria), prototyping drifts. The team builds increasingly clever prototypes that solve the wrong problem. The intent document is the smallest unit of upstream alignment that prevents drift. Even at speed, that paragraph is non-negotiable.

Trap 3: Confusing prototypes with products. A prototype that survives 5 lenses earns the right to become a product. A prototype that only passes the demo lens is still a demo. The 5-lens discipline prevents demo-driven shipping — which is the failure mode that makes the Cursor invoice public.

Trap 4: Demanding pixel-perfect prototypes. A 4-day prototype with rough UI tests the concept. Beautifying the prototype before testing wastes the cycle. The fix: test on what's working, not what's beautiful. UI polish comes after the 5 lenses pass.

Remember this

In practice

Step 1: Replace your next major PRD with a 1-page intent document plus a 4-day prototype. Run the experiment on one initiative. Compare the evidence quality and the time-to-evidence against the team's normal cycle. The result is usually decisive.

Step 2: Adopt the 5 Lenses as the standard prototype review checklist. Every prototype review explicitly answers: will-they-use, will-they-pay, will-they-keep-using, will-it-restructure-the-workflow, will-it-make-economic-sense. Each lens produces a different evidence type. Together they replace the PRD review's "did the team think of everything?" with "does the prototype survive realistic pressure?"

Step 3: Build the intent-document template. A defensible intent doc has 5 sections: goal (1 sentence), user (specific persona, not abstract), success criteria (numerical, time-boxed), out-of-scope (what we're explicitly not solving this round), eval suite seed (5–10 cases the prototype must handle). Make it 1 page. Refuse longer.

Step 4: Create a prototype review cadence. Weekly. Stakeholders, engineering, design, plus 2–3 target users. Run the 5 Lenses out loud. Decisions: ship, iterate, or kill. The friction of "kill" is feature, not bug — most prototypes shouldn't survive their first review.

Step 5: Practice the editor craft. A senior PM's leverage in this world is seeing what's wrong with a prototype faster than it can be re-prototyped. That craft is built by repetition. Run 12 prototype reviews in a quarter. Compare your week-1 reviews to your week-12 reviews. The improvement is the leverage.

The practice — visualized

References