second-brain

prototype-and-prune

7 min read

Prototype-and-Prune

AI-era product development model replacing the brainstorm→mocks→PRD→code→launch pipeline with rapid parallel experimentation.

Last updated: 2026-04-24

Overview

The traditional product development process — brainstorming, mocks, PRD, code, launch — was designed for monthly software cycles and a stable technology landscape. AI invalidates both assumptions: it can generate 50 ideas instantly, working prototypes beat static mocks, and AI capabilities shift fast enough that lengthy PRDs are obsolete before they’re acted on.

Julie Zhuo’s replacement model centers on maintaining an Idea Garden of unexplored concepts and running rapid prototypes in parallel, pruning ruthlessly based on what actually works. The emphasis shifts from planning to experimentation.

The Five Stages

  1. Idea Garden — maintain a long list of unexplored concepts; don’t commit, just accumulate
  2. Prototype-and-Prune — build rapid prototypes testing three questions per idea:
    • Capability: can the technology actually do this?
    • Accuracy: does it produce consistent results?
    • Speed: is it performant enough for real use?
  3. Polish-and-Productionize — refine the survivors for launch
  4. Launch — deploy to customers
  5. Further Pruning — remove underperformers post-launch

Key Points

  • The three-legged stool is dead: the classic Engineer + PM + Designer team mimicked monthly-cycle software. AI-enabled iteration breaks this model
  • Mocks and docs become liabilities: working prototypes beat static designs; PRDs that take weeks to write are obsolete before they’re acted on
  • AI favors tiny parallel teams: 1–3 people exploring multiple ideas simultaneously beats larger coordinated groups
  • Blurred functional roles: engineers design interfaces, designers write copy, PMs analyze data — functional identity matters less than problem-solving ability
  • Good taste is the bottleneck: distinguishing excellent from mediocre execution is the scarce resource, not headcount
  • High agency over consensus: bias toward action without waiting for permission is the winning disposition
  • For leaders: hire generalists, track feature velocity, reward execution over discussion
  • For ICs: identify as a problem-solver, not a functional role; treat AI as constant collaborator

Critiques & Open Questions

Who listens to customers?

The framework’s biggest unresolved gap. Zhuo dissolves the PM role into a generalist “problem-solver” disposition, but the PM’s most important function wasn’t writing PRDs — it was being the person who actually talked to customers and brought that signal back to the team.

ICs (engineers, designers) are generally poor at this. Not because they’re incapable, but because:

  • Customer listening requires a different mode — patience, open-ended questions, resisting the urge to jump to solutions
  • ICs are trained to build, which creates a bias toward validating their existing ideas rather than genuinely exploring customer problems
  • Context-switching between deep technical work and customer discovery is cognitively expensive

Zhuo’s implicit answer — “faster feedback loops via shipping” — substitutes usage data for customer understanding. These are not the same thing. Usage data tells you what people do; customer conversations tell you why, and what they’d do if things were different.

The framework may work well for B2C products with large user bases where behavioral data is rich. It’s weaker for B2B, early-stage, or complex domains where customer context is irreplaceable and a wrong bet is expensive to unwind.

Open question: does the model require a dedicated customer-facing role that Zhuo hasn’t named, or does it assume a founder/domain-expert who carries customer knowledge intrinsically?

Torres’s research on 9 AI product teams offers a partial answer: the teams that succeeded either had deep domain expertise (a former teacher, a former SRE, a former government official) that substituted for some discovery work, or they maintained continuous customer contact throughout — not just post-launch. Domain expertise is load-bearing where customer access is limited, but it doesn’t fully replace it. See teresa-torres.

Rabois Perspective: PM Dissolution and Shopify Demo Culture

Keith Rabois reaches similar conclusions from an investing/operating angle. Year-long roadmaps are incoherent when capabilities change month-to-month. The PM’s actual value isn’t document production — it’s business acumen + commercial instincts + knowing what to build. In the AI era this skill commands a premium independent of role title.

Shopify demo culture (observed by Rabois): Shopify banned PowerPoint/Keynote for all product presentations over two years ago. Everything must be a workable demo. PMs are expected to build, not describe. This is the Prototype-and-Prune model adopted at organizational scale.

Rabois’s counter on customer feedback: for consumer/SMB products, customer interviews are actively harmful because subconscious decisions get described inaccurately. This challenges Torres’s continuous discovery model for that segment and reframes the “foundational insight” source in Zhuo’s framework — insight comes from understanding human psychology, not from interviewing customers. See keith-rabois.

Design Perspective: Field’s Diverge/Converge Framing

Dylan Field (Figma CEO) describes the same underlying pattern from a design angle. Process isn’t linear stages — it’s diamond shapes (diverge → converge) stacking in any order. You start anywhere (code, canvas, doc, conversation) and hop between stages as the work demands.

Field’s principles align tightly with Prototype-and-Prune:

  • Diverge widely first: AI generates a broad possibility space; human judgment prunes it
  • Direct prototype over document: “Get any stake in the ground you can try and use” — even a rough prototype teaches more than extended internal review
  • Non-linear hops: stop a third of the way through a design exploration if you have enough to build with; you’ll learn more from using it than from completing the exploration first
  • 60% non-designer making: Figma Make shows most designs come from non-designers (PMs, researchers) — validating Zhuo’s “blurred roles” prediction in practice
  • Canvas as natural divergence tool: the infinite canvas lets you see all possibilities simultaneously, making it structurally suited to the diverge phase

See design-taste-craft and dylan-field.

The Risk: AI Enables Over-Shipping

The same force that enables Prototype-and-Prune creates a failure mode: AI makes it too easy to say yes.

Steve Jobs’ formulation: great products come from saying no to 999 things and yes to one. Traditional engineering cost enforced this discipline — shipping was expensive, so teams thought carefully before starting. AI removes that gate.

Tuomas Artman (Linear CTO) identifies this as the most important near-term trend going wrong: when every feature request can be immediately shipped, you end up with convoluted software that doesn’t serve the end customer. The competitive dynamics make it worse — when everyone has access to the same AI shipping capacity, you’re always racing someone who can match your feature set. The temptation to out-ship rather than out-prune is strong.

The Uber parallel: Uber went through hypergrowth at all costs, shipping constantly. Every feature race, every fire fought, maximum velocity. The result was a product that accumulated quality debt until competitors who cared about craft started winning users back slowly, imperceptibly, in ways no A/B test would capture.

The Prototype-and-Prune model only works if the prune step is ruthless. AI removes cost from the prototype step; it doesn’t remove the judgment required to prune. That judgment — knowing which idea is worth pursuing, which feature request represents a real problem vs. a surface preference — is taste. Without it, Prototype-and-Prune becomes Prototype-and-Ship-Everything.

See design-taste-craft for the quality discipline practices (Quality Wednesdays, zero bug policy) that operationalize taste at the engineering level.

Connections

  • thin-harness-fat-skills — same underlying pattern: minimize overhead, maximize the useful output layer
  • coding-agent — agents accelerate the prototype loop, collapsing the time between idea and working artifact
  • design-taste-craft — taste filters the divergence phase; craft refines the chosen direction; quality discipline prevents over-shipping
  • julie-zhuo — author; former VP of Design at Facebook
  • dylan-field — parallel framing from design/Figma perspective
  • tuomas-artman — over-shipping risk framing; quality as competitive moat; disciplined “no” as Linear’s differentiator

Sources

Graph View

Backlinks