Handling Demo Questions

Option C is the professional out-of-scope question deferral during a demo:

Why this works:
1. Validates the question — "great area to explore" — not dismissive
2. Honest framing — "not part of this sprint's scope" — factual, not evasive
3. Explains why you're deferring — "don't want to do it justice off the cuff" — positions deferral as respect for the question, not avoidance
4. Makes a visible commitment — "let me note it down" + "I'll come back to you this week" — shows it won't be forgotten
5. Protects the meeting structure — "5 minutes at end for questions" — keeps agenda on track
6. Confirms the stakeholder is OK — "does that work?" — closes the loop

The parking lot technique: Many facilitators keep a real-time "parking lot" doc or whiteboard section where out-of-scope questions are noted visibly. Making the note visible to the room signals the question is genuinely captured, not just dismissed.

What to avoid:
• Ignoring the question entirely
• Going down the rabbit hole (the rest of the room loses their demo time)
• "That's not my area" — even if true, offer to get the right person

Option C is the professional response to skeptical stakeholder feedback during a demo:

Structure: Diagnose before defending
1. Acknowledge the concern — not "you're wrong" but "help me understand better"
2. Ask a diagnostic question — "is it the workflow, performance, or something else?" — turns a vague objection into a specific one you can address
3. Use their answer — distinguish between: concerns you designed around (explain the reasoning), and legitimate concerns you haven't fully addressed
4. Commit to analysis, not immediate capitulation — "discuss with the team and come back" — takes the concern seriously without abandoning your design on the spot
5. Honest framing — "wouldn't want to defend a decision without fully thinking through your point" — signals intellectual honesty

The asymmetry of live demos:
A stakeholder can critique in 10 seconds what took 2 weeks to design. Don't defend under time pressure. Use "I'll come back to you" freely — it shows maturity, not weakness.

When the old system objection is nostalgic rather than substantive:
"The old system did X" sometimes means "I'm uncomfortable with change." Asking specifically what aspect worked better usually separates legitimate technical concerns from familiarity preferences.

Option C is the professional live demo failure recovery:

Recovery formula:
1. Acknowledge clearly — "demo environment hit an unexpected issue" — state what happened without catastrophizing
2. Separate demo failure from product quality — "not behavior in production or staging" — this is critical. Stakeholders often can't distinguish "demo crashed" from "product has bugs"
3. Make the decision explicitly — "rather than debugging live" — shows you're in control of the agenda
4. Have a backup immediately — recorded walkthrough, screenshots, shared doc — never demo without one
5. Commit to follow-up — "investigate root cause and send written summary"
6. Reassure about evaluation continuity — "everything you need to evaluate is in the recording"

Prevention:
• Always test your exact demo flow 30 minutes before the call (not just "it works in dev")
• Have a screen recording of the working flow as backup
• Demo on staging, not local/dev
• If demoing a feature flag, test the flag is on in the demo environment

What makes Option B harmful:
"Always happens" trains stakeholders to be skeptical about your team's demo preparation. Even if it's true, saying it publicly damages confidence.

Option C handles the scope request during demo without over-committing or under-delivering:

Why "sure, we can do that!" is dangerous:
You just committed to something you haven't scoped in front of stakeholders. This creates a verbal contract without a delivery plan. When it either takes longer than expected or gets deprioritized, you lose credibility.

What Option C does right:
1. Validates the request — "interesting use case, I can see why" — not dismissive
2. Explains why you can't commit now — "haven't scoped technical complexity" — honest, not obstructive
3. Makes a concrete next step — "team conversation this week, back to you by [day]" — a specific commitment you can keep
4. Defines what the answer will look like — "rough effort estimate OR questions to resolve" — sets appropriate expectations
5. Asks the right question — "what's the campaign date?" — shows initiative and gathers the data needed to prioritize

The "rough estimate or questions to resolve" pattern:
Sometimes you can scope quickly; sometimes the first step is just defining what you need to know to scope. Being explicit about which one you're delivering prevents the "I asked for an estimate and got more questions" frustration.

The key here is to acknowledge the issue and offer assistance without immediately taking on the entire task. Acknowledging Sarah's urgency shows responsiveness while politely directing her to someone else if appropriate. Providing the exact details requested (like the error message) is crucial for efficient debugging, but prioritizing immediate communication is vital first.

David is offering constructive criticism focused on performance. Acknowledging his suggestion and stating your intention to evaluate it demonstrates openness to improvement without immediately dismissing his concerns. Offering a clear path forward – evaluating the queue – shows you're taking his feedback seriously and considering alternative solutions.

This scenario tests your ability to manage stakeholder expectations. Politely declining the request due to scope limitations is professional and prevents over-committing. Suggesting a discussion about it in the next sprint maintains an open line of communication while respecting the current sprint goals.

Code review comments often highlight areas for improvement. Responding by acknowledging the feedback and stating your intention to address it in a subsequent iteration demonstrates responsiveness and a commitment to quality. It's okay to acknowledge limitations while promising further refinement.

Transparency and immediate action are crucial in these situations. Rolling back the changes demonstrates accountability and prioritizes user experience. While acknowledging a potential issue (performance bottleneck) is important for investigation, admitting to the problem and taking corrective steps immediately builds trust.