Prompt-to-Prototype a Hypothesis in an Afternoon

Workflow area: Prototyping & Validation · Tier: Core · Hands-on time: ~40 minutes to first prototype

The economics of validation flipped. A testable prototype used to cost two sprint's worth of favors from engineering, so hypotheses queued for quarters and most died untested. Prompt-to-prototype tools collapsed that cost to an afternoon of PM time — which changes what a hypothesis is worth and removes the excuse for shipping unvalidated bets. The discipline that keeps this honest has two halves: write the hypothesis and its kill criteria before the tool makes something lovable, and be brutally clear about what five users clicking a fake can and cannot tell you.

When to use — and when not to

• Use it when the riskiest assumption is about the userwill they understand this flow, want this capability, tolerate this trade-off? Interactive fakes answer these faster than any spec review.
• Use it before the PRD hardensa prototype that converges the spec (and feeds pb-23's evidence pack) is worth ten review meetings of imagined behavior.
• Use it to make a stakeholder argument concrete"here, click it" resolves debates that decks prolong. Label it PROTOTYPE in the UI so nobody screenshots it as a commitment.
• Skip it when the risky assumption is technicalfeasibility, latency, model quality. A clickable fake proves none of that; run pb-35's feasibility spike instead.
• Skip it as a head start on productionprototype code is set-dressing: no auth, no error handling, no security review. The throw-away is a feature of the method, not a waste.

The recipe

1. 1.

   Write the hypothesis card first — before opening any tool. Four lines, committed to a doc:

   Copy

   HYPOTHESIS: Ops managers will delegate invoice approval to a
     rules-based auto-approve if they can see and edit the rules.
   RISKIEST ASSUMPTION: they trust rules they authored (not that
     the UI is usable).
   TEST: 5 ops managers complete "set up auto-approve for invoices
     under ₹50K" unprompted, then we ask if they'd turn it on Monday.
   KILL CRITERIA: 3+ of 5 refuse to enable it for real spend, or
     can't articulate what a rule they wrote will do.
   

   Without this card, the afternoon produces a demo in search of a question — impressive, and evidence of nothing.

2. 2.

   Generate the prototype with a scoped prompt. In Lovable (most forgiving for non-technical PMs), v0 (best UI polish), or Bolt (fastest full-stack): describe the user, the single flow, and the screens — not the whole product:

   Copy

   Build a clickable prototype for a B2B expense tool. User: an ops
   manager. ONE flow only:
   
   1. Dashboard listing 8 pending invoices (use the realistic sample
      data below — vendors, amounts in INR, dates).
   2. "Auto-approve rules" screen: create a rule with conditions
      (amount under X, vendor on trusted list) via plain-English
      chips, with a live preview showing which of the 8 pending
      invoices the rule would approve.
   3. Confirmation screen summarizing the rule in one sentence with
      an "Enable" toggle.
   
   Style: clean, dense, desktop-first. Label the header "PROTOTYPE —
   test data only". No login, no settings, no other pages.
   
   Sample data: [8 realistic rows]
   

   Iterate conversationally — "the preview should update as I edit the rule" — and stop when the flow supports the test, not when it's pretty. Two hours is a budget, not a floor.

3. 3.

   Instrument the fake. Ask the tool to add simple event logging — every button click and screen entry, with timestamps, dumped to console or a webhook. Ten minutes of instrumentation turns five test sessions from anecdotes into traces: where people stalled, what they clicked expecting it to work, which rule conditions they actually authored. If the hypothesis involves a future AI feature, what users typed and expected here is seed data for that feature's eval set (pb-26 and pb-37 pick this up).

4. 4.

   Run five users through the task, silently. Recruit from your actual persona — teammates roleplaying users validate nothing. Give the task, not the tour: "you want invoices under ₹50K from trusted vendors approved automatically — set that up." Watch where they hesitate, note what they say the rule will do (against what it would do), and only after the task ask the Monday question from your card. Record with consent; pb-01's notetaker habit applies to test sessions too.

5. 5.

   Judge against the kill criteria — in writing, same week. Three outcomes: validated (proceed to PRD, carrying the session evidence), killed (write the two-paragraph epitaph — what you believed, what five users showed instead — and circulate it; a cheap kill is this method's biggest win), or muddled (usually means the task tested usability when the assumption was about trust — sharpen the card, rerun Thursday). Then archive the prototype link and delete the deploy. The learning is the artifact; the code never was.

Make it yours

• The five-variant morning: generation is cheap enough to test framings, not just features — build the same flow with rules-first vs review-first emphasis and split your five users across both.
• Figma Make when design exists: if the team already has design files, importing frames preserves your design language — better signal when brand trust is part of the hypothesis.
• The validity-limits note: attach one paragraph to every prototype readout naming what this test cannot claim — n=5 finds usability walls and comprehension gaps, not demand curves; enthusiasm in a test session is not a purchase order; novelty inflates everything. Writing it every time is what keeps prototype evidence honest in front of execs (lab-04 drills exactly this).

Quality check

• The hypothesis card predates the prototypeif the test was designed after the build, the build designed the test; that's demo-making, not validation.
• Kill criteria are falsifiable and were written down"users like it" can't fail; "3+ of 5 refuse to enable it" can. The written version is what stops post-hoc rescue.
• Participants match the personafive real ops managers beat twenty colleagues; convenience samples validate your org chart, not your market.
• Claims match the instrument's reachthe readout says "5 of 5 authored a correct rule" and never "users want this"; demand claims need pb-26's painted-door evidence or real usage.
• The prototype died on scheduledeploy deleted, link archived, and nobody suggested "starting from" its code in sprint planning. If that suggestion survives, re-read the throw-away rule aloud.