Demo Craft
- Script a demo on the problem → magic → how → next arc, opening with the customer's pain
- Rehearse to a timing sheet, including the questions you hope nobody asks
- Recover from live failure gracefully using prepared fallbacks and honest narration
- Tailor the same demo to an executive room versus an engineering room
- Run demo-environment hygiene: seeded data, killed notifications, backup recording
| Spaced-rep warm-up: due cards incl. Day 166 ladder & labels | 10 min |
| ELI5 + tech read; write the arc and fallback ladder from memory | 15 min |
| Guided: script the demo + sabotage rehearsal | 40 min |
| Practice: same demo, two rooms | 15 min |
| Project: assemble the demo kit + follow-up email | 20 min |
| Quiz + flashcards | 10 min |
Builds on: Day 166 — Rapid prototyping — the thing being demoed · Day 161 — Production cutover — the real system behind the story · Day 105 — Explaining AI to non-technical stakeholders
Stage magicians obsess over an asymmetry: the audience remembers the thirty seconds of wonder, and forgets — if the show is built right — that everything around those seconds was engineered. The patter that frames the trick, the volunteer chosen on the aisle, the second deck in the left pocket for when the first is dropped: none of it is improvised. And when a trick genuinely dies on stage, the professional does not freeze; there is a line ready ("even the cards are nervous tonight"), a pivot, and the show continues. The audience judges composure more than perfection.
A product demo is stagecraft in service of truth. The arc is fixed: open with THEIR problem told back in their words (the room leans in when it hears itself), show the magic moment fast — their document, their jargon, the answer appearing — THEN explain how it works, then land on what happens next. Rehearsal is not optional and not once. The demo environment is a stage: seeded data you chose, notifications silenced, network fallbacks staged (a recording of the happy path is your second deck — disclosed as a recording if used). Live failure handled calmly — "good, that's the timeout fallback you'd see in production; here's the same flow from this morning" — often builds MORE trust than a flawless run, because everyone in that room has watched software fail.
Demos are decision points: pilots get funded, champions get armed, and skeptics get quieter — or none of that happens and momentum dies in a conference room. FDEs demo constantly (weekly checkpoint demos were baked into your Day 165 plan), and the interview loop nearly always includes one ("demo something you built" — your capstone, Day 180, is exactly this). The craft is disproportionately learnable: most technical demos fail on narrative order (how before magic), unrehearsed timing, and unmanaged environments — all fixable this afternoon, all instantly visible to a hiring panel.
Guided practice
Script the capstone demo on the arc
20 minWrite docs/demo_script.md for a 10-minute demo of your capstone (audience: Harbor & Vane's Dana + Marcus + the IT director — a mixed room, the hardest kind).
- Problem segment (write it word-for-word, 90s when spoken): open with three numbers from the Day 163 transcript. No product mention yet.
- Magic segment: choose the ONE moment. (Strong choice: paste a realistic claim question, watch the grounded answer appear WITH the policy-clause citation — because the citation is what the $40K miss was missing.) Script your exact words while it streams — silence while software thinks is where demos die; narrate what the audience is seeing, not the mechanism.
- How segment, two versions: (a) 90 seconds for Marcus — the boundary story, the human-in-the-loop, "every answer cites its source so Priya can verify in seconds"; (b) 2 minutes for the IT director — container diagram, where data flows, the eval harness pass rate, the fallback behavior. Mark in the script where you pivot depending on who leans in.
- Next segment: the dated ask, verbatim from your Day 165 proposal.
- Build the timing sheet: segment / clock / cut-line (what drops if you lose 5 minutes). Total must be 10:00 with 2 minutes of slack for interruptions — a demo with no interruption budget is a demo that runs over.
The sabotage rehearsal
20 min- Run the demo once, timed, out loud, to an empty room (yes, out loud — silent read-throughs rehearse nothing). Record it (phone is fine). Note where you exceeded the sheet.
- Sabotage run: before starting, roll a die for which failure you inject mid-magic-segment — (1–2) kill the network, (3–4) paste a document the system handles badly, (5–6) the model returns a wrong answer. Practice the recovery out loud: the honest narration line, the pivot to the fallback rung, the continuation. Script your three recovery lines afterward — they go in the demo script as a FAILURE PLAYS section.
- Wrong-answer drill specifically (it is the AI-demo special): practice the line that builds trust instead of panic — "good catch, and this is why the pilot has a human review step and an eval harness; let me show you how we measure exactly this." Never argue with your own demo, never blame the model, never silently retry and pray.
- Stage the fallback ladder for real: record this morning's happy path (screen recording, 90s), label it RECORDING in the corner, save it locally (not in the cloud — the wifi that killed the live demo also kills streaming).
- Prepare the hostile-question sheet: five questions from yesterday's honest notes + the two IT-director questions your Day 165 gauntlet surfaced, each with a rehearsed two-sentence answer.
On your own
Same demo, two rooms
15 minDeliver the demo twice, out loud, timed, adapting live:
Round 1 — exec room (Marcus + CFO, 6 minutes hard cap, phones present): problem 60s, magic 2 min, how 90s (boundary + control story ONLY — no architecture), next 60s. What did you cut? Did the cut-lines on your timing sheet survive contact?
Round 2 — engineering room (their tech lead + two engineers, 12 minutes, interruptions encouraged — have the AI tutor play a skeptical engineer who interrupts twice with real questions): magic can be shorter; the how expands — show the eval pass rate, the trace of one request (Day 142), the fallback drill evidence (Day 161).
Afterward, write the delta list: every concrete difference between the two deliveries (segment lengths, vocabulary, which artifact you showed). If the two rounds were nearly identical, you tailored neither.
The demo kit
Commit docs/demo_kit/ containing: (1) the final demo script with timing sheet, cut-lines, pivot marks, and the FAILURE PLAYS section; (2) the hostile-question sheet (≥7 questions with rehearsed answers); (3) the hygiene checklist as a runnable pre-flight (every item checkable in 30 minutes); (4) the labeled backup recording of the happy path; (5) the follow-up email template — subject line, what-you-saw summary with simulated-parts disclosure, owed answers section, dated next step — plus the filled example addressed to the Harbor & Vane room. This kit is the one you carry into Day 168's simulation, Day 174, and the Day 180 Demo Day.
Common mistakes & misconceptions
- Opening with architecture. The room doesn't care how it works until they've seen that it works on THEIR problem; how-before-magic is the #1 technical-demo killer.
- Demoing five features instead of landing one moment. Attention is a budget; the demo exists to make one memory.
- Rehearsing silently, or once. Timing, transitions, and recovery lines only exist if they've been said out loud; the first out-loud run must not be in front of the customer.
- Treating a wrong AI answer as a catastrophe. Argue with your demo and you lose the room; narrate it into your review-step-and-evals story and you gain credibility.
- Live-demoing on real customer PII without written clearance, or with notifications on. One popped Slack message or leaked record can end more than the demo.
- No follow-up within 24 hours. The demo's decision energy decays fast; the email with owed answers and the dated ask is where the demo actually converts.
Q1. Why does the arc put the magic moment BEFORE the architecture explanation?
Q2. Mid-demo, the assistant gives a confidently wrong answer. The strongest recovery is…
Q3. Which pre-demo hygiene failure is the most severe?
Go deeper — curated resources
- Watch one great keynote demo critically — Pick any famous product-launch demo and mark the arc segments with timestamps: where is the problem, when does magic land, how long before any mechanism is explained? The pattern is remarkably consistent across two decades.
- Demo delivered out loud ≥3 times including one sabotage run
- Backup recording made, labeled, stored locally
- demo_kit committed complete with hostile-question sheet and email template
- Quiz ≥ 2/3
← Back: The thing being demoed is Day 166's prototype backed by Day 161's real production evidence; the two-room tailoring extends Day 105's stakeholder translation; the failure narration uses Week 23's reliability vocabulary as a trust asset.
Forward →: Day 168's simulation requires a demo plan from this kit. Day 171 deepens the exec-vs-eng communication craft, Day 174 stress-tests the demo under objections, and Day 180's Demo Day is this skill, graduated.
Unlocks: D168 Week 24 Checkpoint: FDE Simulation I · D178 Capstone Ship & Document