second-brain

prototype-and-prune

10 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-26

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.

Spiegel’s Synthesis: Empathy Without Literalism

Evan Spiegel (Snap CEO) offers the most concrete practitioner example of how to resolve the Torres vs. Rabois tension on customer listening.

His position: you must talk to customers — but not to get requirements. The goal is empathy and insight. “It doesn’t mean you need to take people’s advice or feedback, but it’s really important to listen.”

The Stories example is the clearest illustration:

  • Customers were explicitly asking for: a “send all” button (to blast snaps to everyone easily)
  • Customers were also saying (in deeper conversations): social media feels judgmental (everything is permanent, likes and comments create pressure), and the reverse-chronological timeline was confusing (end of the birthday party appeared first)
  • Snap did not build a send-all button
  • Instead, they invented Stories: chronological (the way humans have always told stories), ephemeral (disappears after 24h), no public metrics (no likes/comments), easy broadcast without spamming
  • They built for the underlying need, not the stated request

The principle: customers articulate local frustrations accurately but rarely propose optimal solutions. Deep empathy reveals the underlying need; the team’s job is to invent a response to that need, not implement the suggestion. “We listened to all of that… but then we came up with something totally new and different.”

This is a third position in the ongoing discovery debate:

  • Torres: continuous discovery throughout, deep customer contact is load-bearing
  • Rabois: no customer interviews in consumer/SMB, subconscious decisions described inaccurately
  • Spiegel: go deep in conversations (not surveys), listen for feeling and frustration, invent independently

The practical reconciliation: all three can be right in different contexts. Rabois’s objection is specifically to asking customers about subconscious behavior and taking those answers literally. Spiegel and Torres both advocate listening for emotional experience and underlying need — which is precisely what doesn’t fall to Rabois’s critique.

See evan-spiegel.

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.

Tibo’s Evidence: Quantity Beats Quality in Practice

Tibo Louis-Lucas provides the clearest real-world data point for Prototype-and-Prune applied at maximum velocity. During the Tweet Hunter era, he and his co-founder shipped 10 products in 4 months — one per week — until something stuck. Nine failed with no traction. The 10th (Tweet Hunter) took off and was eventually acquired.

His framing: “You never know what’s actually interesting. My successful products surprised me too.”

He cites the Harvard pottery experiment: a class was split into a quantity group (10 essays, focus on output) and a quality group (one essay, focus on perfection). The quantity group produced the best individual essays — because more reps generate more real-world feedback, faster iteration, and better pattern recognition about what actually works.

The implication is direct: the best way to produce a high-quality product is to produce many products, not to plan one more carefully. AI collapses the cost of each attempt, making this strategy more accessible than ever — but the underlying insight predates AI.

Pivot signal detection is Tibo’s complementary practice: the clearest PMF signal is when users twist your product for a different use case than you built. When Typrame users started using his AI video assembly engine differently, he followed that signal, rebranded as Revid, and grew to $600K/month. “When you have a product that is made for one thing and people are actually twisting it into this other thing, that’s usually a very strong signal that you have to follow.”

See tibo-louis-lucas.

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
  • tibo-louis-lucas — empirical case: 10 products in 4 months; quantity→quality; pivot signal detection
  • evan-spiegel — empathy-without-literalism; Stories as the canonical case; third position in the Torres/Rabois customer listening debate

Sources