Presentation and Storytelling Questions

Direct Answer

Structure the 10-minute outline around what each of the four functions needs to walk away knowing: one slide with the actual evaluation results in plain language everyone can follow, then one slide each translating the implication for legal, sales, and engineering specifically, so no single group sits through detail meant only for another team.

Structured Elaboration

Slide 1, "What we tested and why" (1 minute).

• We evaluated the customer-support assistant, an AI system, a large language model or LLM, that drafts or answers support replies, against a held-out set of real past support tickets.
• Today's goal: decide whether it's ready for a limited pilot.

Slide 2, "Results in plain terms" (2.5 minutes).

• The assistant produced an acceptable response on a strong majority of tested tickets, with the main failure mode being overly generic answers on unusual tickets rather than incorrect ones.
• We're presenting this in "acceptable / needs review / incorrect" categories rather than a single technical score, since that maps directly to what a support agent would actually decide.

Slide 3, "For Legal: what this means for liability and disclosure" (2 minutes).

• No response is sent to a customer without a human support agent reviewing it first in this pilot; the assistant only drafts.
• We flag zero cases in testing where the assistant gave legally risky advice, e.g., promising a refund it can't authorize, but this is an explicit thing we tested for and will keep monitoring.

Slide 4, "For Sales: what you can and can't say about this" (1.5 minutes).

• You can tell customers support responses may be assisted by AI tooling reviewed by a human agent; you shouldn't promise instant AI-only resolution yet, since the pilot still requires human review.
• Don't commit a rollout date to a customer; the pilot's scope and timeline are still being finalized.

Slide 5, "For Engineering: what's next technically" (2 minutes).

• The main technical gap is generic answers on rare ticket types; the next step is expanding training examples for those specific categories, not a full model change.
• We'll track the same acceptable/needs-review/incorrect breakdown weekly during the pilot to catch regressions early.

Slide 6, "Decision and ask" (1 minute).

• Recommendation: proceed to a limited pilot with human review on every response.
• Ask: approval to start the pilot with a defined subset of ticket types next sprint.

Worked Example

If a sales rep in the room asks "can I tell a customer this is fully automated," the slide 4 bullets give you the exact answer to hand back live: no, human review is still required in this pilot, so the correct customer-facing language is "assisted by AI, reviewed by a person," not "automated."

Trade-offs and Pitfalls

Explaining the evaluation methodology in full statistical detail on the shared results slide loses the sales and legal parts of the room immediately; keep slide 2 in plain outcome categories and reserve deeper technical detail for a follow-up conversation with engineering specifically. Giving each function its own slide but repeating the same generic disclaimer on all four wastes everyone's limited slide time; sales needs "what can I say," legal needs "what's our exposure," engineering needs "what do we fix next," and blending those into one shared bullet serves none of them well.

Direct answer

A one-page decision memo puts the recommendation first, states the noise honestly in one sentence rather than burying it in an appendix, and still lands on a bounded action with explicit risk mitigation, because a decision memo has to actually decide, not just describe the uncertainty.

Framework: memo structure and statistical honesty about noise

Structure:

1. Recommendation (one to two sentences, stated as an action).
2. Why now / context (one to two sentences).
3. What the data shows, and where it's noisy (a short honest paragraph naming which segments agree and which don't, and why).
4. Risk if we act versus risk if we wait (explicit two-sided framing).
5. Mitigation plan (what specifically gets monitored, and the trigger to pause or reverse).
6. Attached supporting analyses (a short list): the segment-level breakdown table, the range or interval around the estimate, a sensitivity check on the weakest segment (re-running the recommendation's math under a couple of different plausible assumptions about that segment, for example assuming its real effect is zero, to confirm the recommendation doesn't flip), and a one-paragraph methodology note.

Statistical honesty about small samples and marginal p-values. A p-value is the probability of seeing a result at least this extreme if there were actually no real effect; results below about 0.05 are conventionally called statistically significant. A marginal p-value from a small sample is not evidence the effect doesn't exist there, it just means the sample is too small to tell the difference between a small real effect and noise. The memo should say so directly rather than treating a borderline segment as proof of "no effect."

Worked example

Segment A: plus 9% lift, sample size 1,200, p-value 0.01, clearly significant. Segment C: plus 6% lift, sample size 800, p-value 0.03, significant. Segment B: plus 2% lift, sample size only 90, p-value 0.07, marginal. Memo language: "Segment B's result is not strong evidence of no effect. A sample of 90 with a p-value of 0.07 means we cannot yet distinguish a small real effect from noise. We recommend proceeding company-wide, with a specific monitoring trigger on segment B, rather than waiting for it to reach significance on its own, which could take months at its current volume." This is internally consistent: the two larger segments are genuinely significant, and the smallest segment is correctly labeled inconclusive, not contradictory, and not silently smoothed over.

Trade-offs and pitfalls

• Quietly smoothing over the noisy segment to make the recommendation look cleaner is a credibility risk if it surfaces later.
• Hedging every single section equally leaves leadership unable to tell what you're actually recommending; a decision memo still has to decide.
• Treating a marginal p-value as proof an effect doesn't exist in that segment is a specific, nameable statistical misread worth calling out directly rather than glossing over.

Direct answer

When an influential leader publicly challenges your conclusions and demands an immediate decision, do not get pulled into defending every number in the heat of the moment, and do not cave to an immediate decision you can't stand behind. Acknowledge the concern specifically, separate what you're confident in from what's genuinely uncertain, and redirect to a concrete, time-boxed next step.

Framework: a four-beat in-room response

1. Acknowledge without conceding. "That's a fair challenge, let me make sure I understand what's driving your concern." This buys a beat and signals you're taking it seriously without agreeing you were wrong.
2. Ask a clarifying, non-defensive question. Surface exactly what the disagreement is about: the underlying data, the interpretation of it, or the recommended action built on top. These are three different objections and need three different responses.
3. Separate confidence levels out loud. State plainly what you're confident in and what you're not, rather than defending the whole thing as equally solid.
4. Propose a concrete, time-boxed next step instead of an immediate decision. Name a specific deliverable and a specific deadline, not a vague "we'll look into it."

Worked example

Leader: "I don't buy this, we need to decide today."
You: "That's a fair pushback. Can I ask what specifically feels off, is it the underlying numbers, or the recommendation we're drawing from them?"
Leader: "The recommendation. You're telling us to cut the budget and I think that's premature."
You: "Got it, that's actually the part I'd put the least confidence behind too. The data on the usage decline is solid; the budget recommendation is my interpretation layered on top of it. Rather than lock in a budget call in this meeting, can I get 24 hours to run the one scenario you're worried about and come back with either a sharper recommendation or a reason to change it?"

This de-escalates because it acknowledges the challenge without publicly caving, it preserves the integrity of the analysis by honestly separating the solid data from the more uncertain interpretation instead of over-defending everything, and it creates a productive next step through a concrete 24-hour follow-up with a named deliverable.

Trade-offs and pitfalls

• Caving immediately to make the tension go away undermines the analysis's credibility long term, people learn that conclusions bend to whoever pushes hardest in the room.
• Digging in and re-litigating every number publicly turns a disagreement into a standoff and rarely changes anyone's mind live.
• Treating the challenge as a personal attack rather than a legitimate signal about where confidence is actually weakest wastes the useful information hidden inside the pushback.

Direct answer

A practical peer-review rubric scores four dimensions independently on a 1 to 5 scale, with a written behavioral anchor (a description of an observable behavior, not a personality trait) at scores 1, 3, and 5 for each dimension, so two different reviewers watching the same talk are likely to land on similar scores.

Structured elaboration

Making this practical for peer review: score each dimension independently before summing them, since a reviewer who scores holistically first tends to anchor every dimension to their overall gut feeling. Calibrate reviewers with one shared example talk scored together before using the rubric on real sessions. Use at least two reviewers per talk for consistency, since a single reviewer's scores drift more than a pair's average does.

Worked example

A hypothetical talk scores 1 on persuasiveness (a fact dump with no argument), 4 on clarity (mostly followable with one confusing tangent), 3 on evidence (claims backed by anecdote rather than measured data), and 4 on delivery (fluent, slightly over time). Total: 1 + 4 + 3 + 4 = 12 out of a possible 20 (4 dimensions times a maximum of 5 each). The written feedback this rubric produces is specific rather than vague: "the recommendation needs a supporting argument, not just a conclusion" is actionable in a way that a single overall number never is on its own.

Trade-offs and pitfalls

Using this rubric punitively rather than developmentally kills honest peer feedback fast; frame it as a coaching tool, not a scorecard for ranking presenters against each other. Confusing charisma, which is closer to an intrinsic trait, with the delivery dimension's actual anchors, which describe learnable behavior (pacing, handling questions, not reading from notes), produces unfair scores for quieter presenters who are otherwise clear and well-evidenced. Finally, anchors written as vague adjectives ("good," "great") instead of observable behaviors make scores inconsistent between reviewers, which is exactly the problem behavioral anchors are meant to solve.

Direct answer

Sequence the six slides so the board sees the headline gap first, then its decomposition into named drivers ordered by size, then a corrective action tied to each driver, and close with the revised outlook and a specific ask. Every slide title pairs one data point with one proposed action, never a data point alone.

Structured elaboration

The ordering principle: open with the number so nobody suspects you're building up to bad news slowly, decompose it so the board can see which drivers are business shortfalls versus something else entirely, address the largest drivers in their own slides, and close with what you're asking the board to approve.

Worked example

Walking the numbers through: the board opens on an 80 million dollar actual against a 100 million dollar forecast, a 20 million dollar miss. Slide 2 shows that gap is not one problem but three: 12 million from a genuine slowdown in one market segment, 5 million from deals that are real but simply closed later than expected, and 3 million that turns out, on investigation, to be a reporting bug that overstated last quarter's baseline rather than a real shortfall this quarter. That third component matters enough to earn its own slide (5), because it is not the same kind of problem as the first two. Slides 3 and 4 give the segment and pipeline drivers their own corrective plans and owners, and slide 6 shows the revised range once the corrected baseline replaces the buggy one, closing with a specific ask rather than a vague commitment to keep watching the numbers.

A distinct trigger worth naming explicitly: this narrative changes shape depending on whether the root cause is a genuine performance shortfall or a data-quality incident. A market slowdown needs a business recovery plan. A reporting bug needs an evidence pack, the specific artifact proving what actually happened, how it was caught, and that the corrected baseline is now trustworthy, and part of the "20 percent miss" narrative has to be honestly reframed as smaller than originally reported, not quietly folded into the business story as if it were the same kind of miss.

Backup materials to prepare for likely board questions: the evidence pack documenting the data-integrity finding (what broke, how it was found, the corrected numbers); a one-page reconciliation of the full 20 million dollar gap with links back to source data; a sensitivity table showing the recovery forecast under a few different close-rate assumptions for the delayed deals; and a named-owner contact list for each corrective action so board members can follow up directly rather than through you.

Trade-offs and pitfalls

Burying the headline number on a later slide is the fastest way to lose the board's trust, they notice immediately if slide 1 doesn't state the miss plainly. Presenting root causes without a corrective action attached to each one leaves the board with an autopsy instead of a plan. A vague ask, "we'll keep monitoring" instead of a specific approve or no-approve request, wastes the one chance you have for the board to actually decide something in the room. And treating a data-integrity finding the same way you'd treat a real performance shortfall, folding it into the same recovery-plan language, undersells the fact that part of the bad news wasn't actually true and erodes credibility once someone on the board later learns the distinction.