Demo Failure Recovery

Option B is the professional way to recover from a live demo failure:

Structure:
1. Names the issue without panic — "that's odd" — calm, factual, not alarmed
2. Gives context that reassures — "passed in QA yesterday" — signals this is an anomaly, not a fundamentally broken feature
3. Commits to a concrete follow-up — "flag it for the team right after this call" — shows ownership without derailing the demo
4. Falls back to a prepared backup — switching to a recording is a legitimate, planned contingency, not an admission of failure
5. Promises closure — "follow up with a live retest" — stakeholders know they will see resolution, not silence

Why having a backup recording matters:
Experienced presenters always prepare a screen recording or set of screenshots of the "happy path" before a live demo. This isn't deception — it's risk management. Live software fails for reasons unrelated to code quality (network blips, stale test data, environment drift).

What to avoid:
• Long silence while debugging live — narrate or pivot within 5-10 seconds
• Skipping without acknowledgment — stakeholders noticed the error; ignoring it reads as evasive
• Catastrophizing ("this is embarrassing") — undermines confidence in the whole team's work, not just this bug

Option B demonstrates proactive failure disclosure — flagging a known limitation before it becomes a surprise:

Why get ahead of it:
Telling stakeholders about a gap before they discover it themselves preserves trust. Discovering it live (a blank screen, an error) reads as unpreparedness; announcing it in advance reads as transparency and control.

Structure:
1. "Quick heads up" — signals a small, manageable caveat, not a crisis
2. Specific, factual reason — "test account was reset this morning" — not vague ("something happened")
3. Offers an alternative — screenshots from a real test run — so the feature isn't invisible
4. Concrete follow-up offer — live walkthrough after the call, for anyone who wants full confidence

The "never leave a gap unfilled" principle:
Whenever a planned demo item can't be shown, always substitute something — a screenshot, a recording, a verbal walkthrough with the code open — rather than simply skipping. A skipped feature with no substitute makes stakeholders wonder if it exists at all.

What to avoid:
• Silent hope ("maybe no one notices") — the worst option; guarantees an unmanaged failure moment
• Vague dismissal ("not ready", "broken") — invites follow-up questions you're not prepared to answer calmly

Option B is the model response for acknowledging a visible bug caught by a stakeholder mid-demo:

Structure:
1. Thanks/credits the observer — "good catch" — makes the stakeholder feel heard, not dismissed
2. Gives an accurate, specific diagnosis — "display bug, not a data bug" — this distinction matters: a rendering glitch is lower severity than a data-integrity issue, and saying so precisely (if true) reassures without minimizing
3. Visibly logs it — "I'll log it as a bug right now" — demonstrated action beats a verbal promise
4. Gives a timeline — "next day or two" — concrete, not "we'll look into it"
5. Reframes the interruption positively — "exactly the kind of thing we want surfaced" — encourages stakeholders to keep engaging critically, which is the whole point of a demo

Why "yeah, known bug, moving on" fails:
It signals the bug was known and shown anyway without disclosure — which damages trust more than the bug itself. If something is a known issue, disclose it before the stakeholder has to find it.

Why guessing at causes you're unsure of is risky:
Never invent a technical explanation you're not confident in ("must be the demo environment") — if it turns out to be a real data bug, you've now made an incorrect claim on record. If unsure, say "let me confirm whether that's a display issue or a data issue and get back to you" instead.

Option B handles a technical disconnection during a live demo professionally:

Structure:
1. States the problem plainly — "screen share dropped" — no drama
2. Gives a time estimate — "about 15 seconds" — sets expectations so the pause doesn't feel indefinite
3. Fills the dead air productively — recaps what was just shown, in plain business terms ("reduces sign-up steps from 5 to 2") — keeps the audience engaged and reinforces the key takeaway rather than leaving silence
4. Resumes with an explicit orientation cue — "picking up right where we left off, at the profile setup screen" — re-anchors the audience quickly

The "narrate through dead time" principle:
Any pause longer than a few seconds during a demo should be filled with verbal content — a recap, a preview of what's next, or context — rather than silence. Silence during a technical hiccup reads as loss of control; narration reads as composure.

Why not reschedule immediately:
A single reconnection blip is rarely worth ending a 15-minute slot early. Reserve "let's reschedule" for genuinely unrecoverable situations (e.g., total environment outage) — jumping to it too quickly wastes stakeholders' time and signals low resilience.

Blaming your setup repeatedly ("this always happens") undermines confidence that you're prepared; a brief, neutral acknowledgment is enough.