Use this when the iteration is ending and you need to prepare for the weekly demo. Assigns presenters, writes narrative frames for each story, and generates talking points and anticipated questions.
Process
Step 1: Gather inputs
Ask the user to provide:
- Stories completed this iteration — titles, brief descriptions, and who built each one. Accept pasted text, iteration plan, or tracker data.
- Iteration goal — what did the team set out to accomplish?
- Audience — who will attend? (e.g., "client product lead + engineering manager" or "internal stakeholders only")
- Demo environment — where will demos run? (staging, production, local)
Step 2: Build the demo narrative
For each completed story, generate:
- User need framing — one sentence explaining the problem from the user's perspective
- What we built — one sentence describing the solution
- Demo flow — step-by-step walkthrough (what to click, what to show, what to call out)
- Key highlight — the one thing to make sure the audience notices
- Anticipated questions — 2-3 questions stakeholders are likely to ask, with suggested answers
Narrative arc: Shape the demo as a three-act story, not a feature tour:
- Setup (1-2 min): The user's problem and why it matters. Create stakes before showing the solution.
- Confrontation (bulk of demo): What we built, how it works, what surprised us. Each story should have a moment of tension or discovery.
- Resolution (1-2 min): What this means for users. What's next. The "so what?" for the audience.
Presence preparation: Before delivering the demo, prepare:
- Opening line: Rehearse the first sentence until it's effortless. Don't start with "so today we're going to show you..."
- Pace map: Slow down for key reveals, speed up for setup/transitions
- Pause points: After showing the most important feature, pause 3 seconds. Let the room absorb it.
- Physical plan: Know where you'll stand/sit, what you'll do with your hands, how you'll manage the screen + audience attention split
Related skills: See
/executive-presencefor full presence preparation,/narrative-arcfor story structure options.
Step 3: Generate the demo agenda
Output in this format:
Demo Agenda: Iteration (number) — (date)
Iteration goal: (the goal) Audience: (who's attending) Duration: (estimated — typically 30-45 min)
Opening (PM, 2 min)
- Remind audience of iteration goal
- Preview what they'll see today
Demo 1: (story title) — Presenter: (name), (X min)
User need: (one sentence) What we built: (one sentence) Demo flow:
- (Start here — show this state)
- (Do this action)
- (Point out this result)
Highlight: (the key takeaway) Likely questions:
- (Question) — (suggested answer)
- (Question) — (suggested answer)
Demo 2: (story title) — Presenter: (name), (X min)
(Same structure)
Feedback (5-10 min)
Prompt questions for the audience:
- (Specific question about what they saw)
- (Question about priorities for next iteration)
Closing (PM, 2 min)
- Preview next iteration's focus
- Note any decisions needed from stakeholders
AI system demo variant
When the iteration includes AI features where progress is quality improvement rather than new functionality, adapt the demo format:
Replace the standard narrative arc with:
- Baseline anchor (2 min): "Remember where we started" -- show the baseline score or a representative bad output from week 1
- Progress walkthrough (bulk): For each AI component, show: previous score → current score → what changed → before/after example
- What didn't move (2 min): Acknowledge flat or regressed dimensions honestly, explain the prioritization
- What's next (2 min): Target dimensions and scores for next sprint, SME sessions needed, decisions requested
Adapt the per-story template:
### AI Demo: {{component name}} -- Presenter: {{name}}, {{X min}}
**Baseline:** {{dimension}} was {{score}} in sprint 1
**Current:** {{dimension}} is now {{score}} ({{+/- delta}})
**What we changed:** {{plain-language explanation}}
**Example:** {{side-by-side before/after output}}
**What's next:** Targeting {{dimension}} improvement to {{target score}}
Stakeholder education (first AI demo only):
- "The UI may look the same. The improvement is in what the AI produces."
- "Each AI feature is like tuning a recipe -- the ingredients are set, but proportions take iteration."
- "'10% better' is significant -- it means {{X}}% fewer outputs need manual correction."
For a dedicated AI progress demo script, use
/ai-progress-demo.
Step 4: Review
Ask the user:
- Is the order right? (Lead with the most impactful demo)
- Are the presenter assignments correct?
- Any stories to skip or add?
- Any specific talking points to include for the audience?
Remember: this draft multiplies your output, not your judgment. You own the final narrative.
For unit economics context when demoing pricing or business model features, use unit-economics-analyzer.
Output location
Present the demo agenda as formatted text in the conversation for the team to reference during the demo.
Example Output
Input
- Stories completed: (1) "Bulk Invoice Upload" — drag-and-drop CSV upload for 50+ invoices at once, built by Priya Nair; (2) "Smart Duplicate Detection" — flags likely duplicate invoices before submission using vendor + amount + date matching, built by Tomás Herrera; (3) "AP Dashboard Redesign" — consolidated pending, flagged, and approved invoices into a single view with filter controls, built by Priya Nair + Jess Woo
- Iteration goal: Reduce manual data entry and processing errors for accounts payable teams handling high invoice volume
- Audience: Client product lead (Dana Fowler, Meridian Logistics) + Meridian's AP Manager (currently in beta) + internal engineering manager
- Demo environment: Staging (pre-loaded with Meridian's anonymized invoice data)
Output (abbreviated)
Demo Agenda: Iteration 6 — January 17, 2025
Iteration goal: Reduce manual data entry and processing errors for AP teams handling high invoice volume Audience: Dana Fowler (Meridian, Product Lead), Sandra Okafor (Meridian, AP Manager — beta user), Chris Delano (Engineering Manager) Duration: ~40 min
Opening — Presenter: PM, 2 min
- Dana and Sandra: last iteration you told us your team was re-keying invoices for 2–3 hours a day and catching duplicates by memory. That's what we went after.
- Today you'll see three things that directly attack that problem.
Demo 1: Bulk Invoice Upload — Presenter: Priya Nair, 8 min
User need: AP clerks at Meridian manually enter invoices one at a time, making high-volume weeks a bottleneck that delays payment runs. What we built: A drag-and-drop CSV upload that processes up to 500 invoices in a single action, with per-row validation feedback before anything is committed.
Demo flow:
- Open staging environment — show the current "Add Invoice" single-entry form so the audience remembers the old path
- Navigate to the new Upload tab; drag in the sample CSV (Meridian_Jan_invoices_50rows.csv)
- Show the validation summary screen — highlight the 3 rows flagged for missing PO numbers without blocking the other 47
- Confirm upload; show the invoices appear in the dashboard in under 4 seconds
Highlight: The partial-commit behavior — valid rows process immediately; problem rows don't hold the whole batch hostage.
Likely questions:
- What file formats will you support beyond CSV? — CSV covers the export format from Meridian's ERP (SAP B1). XLSX is on the backlog for Iteration 8; we can reprioritize if that's blocking other users.
- What's the 500-row limit based on? — Current staging performance benchmark. We haven't hit a wall; we set a conservative ceiling and will raise it after load testing next sprint.
- Who gets notified when rows are rejected? — Right now the uploader sees it in-session. Async email notification for rejected rows is scoped for Iteration 7.
Demo 2: Smart Duplicate Detection — Presenter: Tomás Herrera, 10 min
User need: Meridian's AP team has paid duplicate invoices twice in the past quarter — vendors occasionally resubmit, and humans catch it inconsistently under volume pressure. What we built: A matching engine that compares vendor ID, invoice amount, and date window (±3 days) against the last 90 days of invoice history, surfacing likely duplicates as a warning before submission — not a hard block.
Demo flow:
- Upload a single invoice for vendor "Hartwell Freight" — $4,840, dated Jan 14
- System surfaces a yellow warning banner: "Possible duplicate — Hartwell Freight, $4,840, submitted Jan 12"
- Show the side-by-side comparison drawer — same vendor, same amount, 2-day delta, different invoice number
- Demonstrate the override flow: AP manager can add a note ("confirmed separate shipment") and proceed — full audit trail captured
- Run the bulk upload from Demo 1 and show that 2 of the 50 rows trigger duplicate warnings inline in the validation screen
Highlight: The warning-not-block design. Sandra's team asked for this explicitly — they need human judgment to stay in the loop, not a system that refuses to process.
Likely questions:
- What's the false positive rate so far? — In beta with Meridian's anonymized data, we flagged 11 invoices; Sandra's team confirmed 8 were true duplicates and 3 were legitimate re-submissions. We're tuning the date window based on that feedback.
- Can we tighten or loosen the matching rules by vendor? — Not yet per-vendor, but global sensitivity settings (strict / standard / loose) are designed and scoped for Iteration 8.
- Does this work retroactively on existing invoices? — The 90-day lookback runs against all historical data in the system, not just invoices entered through the new upload flow.
Demo 3: AP Dashboard Redesign — Presenters: Priya Nair + Jess Woo, 8 min
User need: AP managers at Meridian were toggling between three separate screens to see pending, flagged, and approved invoices — losing context on what needed action right now. What we built: A unified dashboard that surfaces all invoice states in one view, with filter controls for status, vendor, date range, and flag type.
Demo flow:
- Show the old three-tab layout (screenshot) — set the baseline for what Sandra was navigating daily
- Open the new dashboard — point out the status summary bar at the top (47 pending, 3 flagged, 12 approved this week)
- Filter to "Flagged only" — the 2 duplicate warnings from Demo 2 appear here in context
- Demonstrate the vendor filter + date range together to isolate Hartwell Freight invoices this month
- Show that clicking any row expands inline — no page navigation required to review or approve
Highlight: The summary bar. In user testing, Sandra said "That's the first thing I'd look at every morning." Make sure she sees it acknowledged.
Likely questions:
- Can we customize which columns appear? — Column visibility toggles are in the design spec; not yet built. Targeting Iteration 7.
- Will this replace the existing reports, or run alongside them? — This is the operational day-to-day view. Existing reports (exports, period summaries) are separate and unchanged.
Feedback — 5–10 min
Prompt questions for the audience:
- Sandra, in a normal week at Meridian — which of the three things you saw today would save your team the most time?
- The duplicate detection is tuned to your data right now. Are there vendor relationships or invoice patterns we should know about where the matching logic might behave unexpectedly?
- We're planning column customization and XLSX support for Iteration 7–8. Given what you saw today, does that sequencing feel right, or is something else more urgent?
Closing — Presenter: PM, 2 min
- What this means: Meridian's AP team can now process a week's invoice volume in one upload, catch duplicates before they become problems, and manage exceptions from a single screen.
- What's next: Iteration 7 targets email notifications for rejected rows, column customization, and the first pass at approval routing rules.
- Decision needed: Do we keep the ±3-day duplicate detection window as the default, or does Sandra want to test a ±1-day window given Meridian's billing cycle patterns? We need a call or async answer by Jan 20 to configure before the next beta cohort onboards.