LAB 09 · PRODUCT● READY
Prototype a product in a day
OUTCOME / A TESTABLE PROTOTYPE
- STACK
- ChatGPT · Claude · Codex
- LEVEL
- Advanced
- TIME
- 120 minutes
PULLS OFF THE SHELFLoading the window The command line Steering the average
What you’ll walk away with: a live prototype scoped to your idea’s riskiest assumption, a test script with a decision rule you set before anyone touched the thing, and a verdict — persevere, pivot, or kill — earned from what real people did, not what they said. The build fits in two focused hours; the learning arrives over the week that follows.
You need: the same toolchain as Launch a website from one conversation (Claude Code, GitHub, Vercel — or your preferred builder), a ChatGPT or claude.ai account for the thinking steps, a pain you’ve witnessed real people have, and 3–5 of those people willing to try something. A worked example runs through this lab in italics — Renata, a fictional caterer who loses tasting-appointment requests across Instagram DMs, texts, and email — so you can see what each step looks like done.
● VIDEO WALKTHROUGH
Watch, follow, or move the work to your desktop.
Play the full walkthrough here, pause at each handoff, then continue into Step 1 below.
Step 1 — Start from witnessed pain, not a loved idea
Here’s a pain I’ve watched real people have: [who, when it happens, what they do about it today, what that workaround costs them — and one specific incident I saw]. Interview me until the pain is sharp. Then restate it: WHO experiences it, WHEN, today’s WORKAROUND, and the COST. If my evidence is secondhand or hypothetical, say so plainly.
The incident is the signal. Ideas without witnessed pain produce the average startup — plausible, fluent, and attached to nobody. Renata: three inquiries last month got answers four days late; two booked a competitor. The workaround is “check five inboxes”; the cost is real revenue.
Step 2 — Write the falsifiable hypothesis
Turn it into: IF we give [who] [the smallest interface], THEN they will [observable behavior] within [timeframe], BECAUSE it beats [today’s workaround]. Then name the RISKIEST assumption — the one that, if wrong, kills everything. Propose the smallest prototype that tests ONLY that assumption; everything else gets faked or done by hand behind the scenes.
Wizard-of-Oz is legitimate — fake the backend, answer manually, pretend nothing is automated yet. The one thing you never fake is what happens to people and their information: if the form collects contact details, they go where you said and nowhere else. Renata’s riskiest assumption: inquirers will use a request page instead of DMing. Prototype: one page, one form, submissions land in a sheet she answers by hand.
Step 3 — Build the one flow
Folder, plan.md, then Claude Code:
Read plan.md. Build only the flow that tests the assumption: [the page, the form, the confirmation]. Fake everything behind it — submissions go to [a sheet / an email]. Make it feel real enough that a stranger takes it seriously: real words, real names, no placeholder text. Git repository, commit as you go, show me how to run it locally.
Deploy it. Describe, don’t debug, when something’s off — and Ship an internal tool’s line applies here too: a public URL is fine while it handles test data people gave you willingly; anything sensitive earns the access talk first.
Step 4 — Write the test BEFORE the testers
Write the test plan: (1) five tasks a tester performs, phrased as goals, not instructions — “book a tasting,” never “click the green button”; (2) the think-aloud ask; (3) what we measure — completed or not, where they stalled, what they said verbatim; (4) THE DECISION RULE, right now, before anyone tests: what result kills this, what result continues it.
The pre-committed rule is this lab’s signature move. Set the kill threshold while you’re still neutral — after five people compliment your colors, you won’t be. It’s steering pointed at yourself: the average founder reads any result as encouragement; the rule doesn’t. Renata’s rule: send the link to the next five inquiries; if fewer than two use it, the page dies.
Step 5 — Test with real people, capture verbatim
Run the sessions — or field-test, like Renata sending the link to real inquiries as they arrive. Capture what people DID and what they SAID, word for word. Behavior outranks opinion: “would you use this?” is worthless; whether they finished is the data.
Step 6 — Synthesize in a fresh window, then let the rule decide
Here are the hypothesis, the pre-set decision rule, and the raw notes and transcripts. (1) What did people DO, versus what the hypothesis predicted? (2) The strongest evidence for; the strongest against. (3) Apply the rule as written: persevere, pivot, or kill — and if pivot, toward which assumption? Do not soften the verdict.
Fresh window, on purpose: the window that built the prototype is a proud parent. And the rule decides, not your mood — yesterday-you, who was neutral, outvotes today-you, who is attached. Renata: four of five used the form, two asked for a date picker. Persevere — next riskiest assumption: will she keep answering same-day?
Check your understanding: why is the decision rule written before the first tester — and what may the prototype fake, versus never fake?
Use this process to test other ideas. Witnessed pain falsifiable IF/THEN riskiest-assumption prototype pre-committed rule verbatim capture fresh-window verdict. It tests a feature as well as a company, a service offering as well as an app — anything you’re tempted to build for a quarter before asking anyone.