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.

The most professional response involves acknowledging the issue without causing panic. Halting the demo abruptly can damage confidence. Continuing with the next section demonstrates resilience while prioritizing investigation. Option A is too dismissive; option D avoids addressing the immediate problem.

Acknowledging and expressing willingness to investigate demonstrates professionalism and responsiveness. Simply dismissing the concern (option 3) is unhelpful and risks escalating the issue. Option 2 shows a commitment to fixing the problem. Option A minimizes the importance of the feedback, and option 4 directly contradicts the reviewer.

When presenting to stakeholders, technical jargon can be confusing. A brief, reassuring explanation combined with a workaround demonstrates competence without overwhelming them. Option A is too detailed; option C avoids transparency and risks appearing evasive; option D would further alienate the investors.

A thorough bug report with reproducible steps is crucial for effective debugging. This provides the development team with all the necessary information to quickly identify and fix the root cause of the inaccurate data. Option A is premature; option B avoids accountability; option D is unprofessional.

Maintaining composure and providing a brief explanation is key. This demonstrates professionalism and keeps the audience informed. Restarting (option 2) might not work and simply wastes time. Options 1 and 4 are entirely unacceptable.