Events, Keynotes and Demos

Marketing runs the event. The PM owns the product claims: what gets announced, what the demo shows, what is ready and which customer evidence supports it.

Why this matters

A flagship event sets the story that sellers, customers, analysts and press repeat. Demo claims become buying expectations. Gaps between the demonstration and the shipped product create support costs, stalled deals and credibility problems.

AI adds variable outputs and actions that need approval. Every announcement needs evidence, a readiness label and a failure plan. This chapter connects the event portfolio, announcement sequence, keynote, demos and customer proof to those controls.

How events fit B2B go-to-market

The event portfolio

Match each event to its audience and purpose. Reserve flagship keynote time for strategic launches and use other channels for education and deal support.

Chapter 25 assigns launch tiers by business impact. Tier 1 earns keynote time, tier 2 gets breakouts and blog posts, and tier 3 gets release notes. Use that policy to resolve requests for extra keynote content.

Analyst relations covers briefings, client inquiries, evaluation submissions, analyst days and site visits. Keep the keynote and briefing-room claims consistent.

Readiness labels

Every claim you make at an event needs a readiness label, printed on the slide, in the press release and in the briefing book. Use four, and define them in writing before the event:

Readiness labels tell buyers what they can use and bound presenters’ improvised claims. Apply them consistently, including to polished videos of roadmap items.

Announcement sequencing and embargoes

Sequence pre-briefings before the keynote so each audience receives accurate news from you first.

A news embargo gives a journalist advance access on condition that publication waits until an agreed time. Usually an informal trust arrangement, it supports considered reporting and coordinated coverage. An outlet that breaks it risks losing early access.

Adapt this recommended sequence to your company. The timings are guidance, not an industry standard.

1. Internal enablement (about four weeks before). Sales, support and partners are briefed. The FAQ, pricing position and readiness labels are final. Chapter 27 covers the enablement itself.
2. Analyst pre-briefs under NDA (one to three weeks before). Analysts hear the strategy and the specifics early, so their first notes are informed.
3. Press pre-briefs under embargo (days before). Reporters get the release, the briefing book and a spokesperson.
4. Press release at embargo lift (shortly before or at the start of the keynote).
5. The keynote.
6. Breakouts, hands-on labs and webinars (the same day and the days after), where the detail lives.
7. Customer and partner follow-up (the weeks after), including advisory boards and account reviews.
8. General availability when the readiness criteria are met, which may be weeks or a quarter later.

Salesforce’s Agentforce launch in 2024 is a public example of separating the news from the stage. The press release announcing Agentforce went out on 12 September 2024, ahead of the company’s Dreamforce conference, and set general availability for late October. Because the news was already out, the conference could spend its time on demos and customers instead of the announcement itself.

Prepare a briefing book: fact sheet, readiness table, architecture, approved customer references, pricing position, competitive framing, hard questions and embargo terms. Identify confidential numbers explicitly.

Keynote narrative: what is and what could be

Nancy Duarte’s Resonate (2010) and 2011 TEDxEast talk describe persuasive speeches alternating between what is and what could be. The audience is the hero, and the presenter is the mentor.

Duarte’s sparkline starts in the audience’s current world. The call to adventure introduces the gap. Contrasting current and possible futures builds the case. A call to action precedes the closing new bliss. Plan one S.T.A.R. moment, “Something They’ll Always Remember,” that listeners can retell.

Here’s how this book adapts the sparkline for a 25-minute B2B product keynote. The timings are a starting point, not a rule.

Serve three audiences: users need working software, buyers need outcomes and commercial context, and analysts and press need strategy and claim boundaries. Give each a clear beat. Chapter 35 covers presentation delivery.

Demo-led keynotes: what the public record teaches

These demonstrations show why software, staging, state and disclosure need separate preparation.

Engelbart, 1968. The Mother of All Demos showed windows, hypertext, the mouse, video conferencing and collaborative editing to roughly a thousand people. It connected San Francisco to a computer in Menlo Park through leased-line and microwave links. Bill English directed video switching onto a 22-foot screen. Dedicated technical direction made the demonstration possible.

iPhone, 2007. Apple introduced the iPhone at Macworld in January and shipped it in the US on 29 June. Fred Vogelstein later reported that fragile prototypes required a rehearsed “golden path.” The demonstration showed capabilities that the eventual product delivered, while following a carefully controlled sequence.

iPhone 4, 2010. Audience Wi-Fi devices and hotspots disrupted the WWDC demonstration. Jobs asked attendees to disconnect and used backups. Include audience load in rehearsal conditions.

Pre-recorded keynotes. Apple’s online WWDC in 2020 replaced the live keynote with produced video. Recording improves production control while increasing the need to disclose editing and staging.

Cybertruck, 2019. Two “Armor Glass” windows shattered during Tesla’s unveiling. Musk later attributed the damage to an earlier sledgehammer strike. Reset shared state between demonstration beats.

Demo design and scripting

Do the last thing first. Peter Cohan’s Great Demo! method opens with the customer’s situation and the result, then shows the shortest path to it. Add detail when the audience asks. Avoid spending the demonstration on login and configuration.

Live, recorded or hybrid. Use a simple rule. Go live when the claim is about speed or interaction and you control the environment. Use a recording when dependencies sit outside your control or the output is nondeterministic, and label it on screen (“recorded”, “sped up 2x”, “edited for length”). The hybrid is usually right for a keynote: run the beat live, with a recorded version of the same beat cued and ready to switch to.

The demo environment. Run demos in a dedicated, isolated environment seeded with synthetic data that looks real. Freeze the version of every dependency. Write a reset procedure and run it before every rehearsal and before the show. Keep the demo off any network or service the audience shares. The 2010 iPhone 4 stall came from audience load, and so did the first of the two 2025 Meta Connect failures.

The failure plan. For every beat, specify an abandon trigger, a fallback recording, a switching line and a production-booth owner. For example: switch to the same beat’s recording after eight seconds without a response. Rehearse the switch.

Happy-path honesty. Every demo is a happy path. The honesty question is whether you imply the happy path is the typical path. Show one realistic imperfection (a product that asks for approval, or says it isn’t sure), say aloud what is seeded or scripted, and keep every capability shown inside its readiness label.

The pre-mortem. Apply Gary Klein’s method a few weeks before the event: imagine the demo failed and identify why. Convert the causes into the risk plan, with triggers, fallbacks and owners.

Customer stories on stage

Choose customers whose evidence supports the claim. A specific before-and-after result is stronger proof than a large logo with exploratory interest.

Structure the customer story as situation, turning point and result. Obtain written customer and legal approval for every number. Rehearse with the customer’s communications team and prepare for follow-up questions. Keep the customer’s voice and show preview labels where applicable.

Measuring event impact

Event reporting usually stops at attendance, session ratings and leads. Those are inputs. A PM should care whether the event changed what customers did.

Jack and Patti Phillips’s ROI Methodology, developed for training and program evaluation, gives a five-level skeleton that fits events well, plus two important additions: intangibles, and a step to isolate the program’s effect from everything else that happened.

Attendees are often more engaged already. Compare them with matched non-attending accounts and state the uncertainty, rather than attributing the whole difference to the event.

Add one measure that belongs to the PM: claim drift. Count the support tickets, sales calls and account reviews in which a customer expected the product to do something it only does in private preview or on the roadmap. Claim drift shows whether the readiness labels survived contact with the audience.

How to apply it

Here’s a method for a tier 1 announcement at a flagship event, counted back from the keynote. Start at twelve weeks if you can; eight is the practical minimum for anything with a live demo.

Twelve weeks out: decide what’s true.

1. Confirm with product marketing which launches are tier 1 for this event (Chapter 25), and agree that only those get keynote time.
2. Write the readiness table: every capability you might mention, with its label (generally available, public preview, private preview or roadmap) and the evidence for that label. Get engineering, legal and communications to sign it. This table governs every later artifact.
3. Draft the event plan: the keynote segment, breakouts, labs, partner sessions, analyst and press sessions, and which persona each one serves.
4. Pick the customer story. Choose for proof of the tier 1 claim, start the approval process for any number, and book time with the customer’s communications team.

Eight weeks out: build the story and the demo.

5. Outline the keynote on the sparkline. Write the what-is opening in the customer’s words, three contrast cycles, one S.T.A.R. moment, the customer proof and a call to action that matches the readiness label.
6. Write the demo script beat by beat: words, actions, expected screen, timing and the fallback cue. Open with the result, in Cohan’s sense, and keep every beat inside its label.
7. Stand up the demo environment: isolated, seeded with synthetic data, dependencies frozen, reset procedure written and tested.
8. Run the pre-mortem with the presenters, the demo engineer and the production lead. Turn it into the demo risk plan, with an owner for every risk.
9. Draft the announcement sequencing plan, from internal enablement through general availability, with the embargo time and who briefs whom.

Four weeks out: prepare the audiences.

10. Brief sales, support and partners. Give them the readiness table, the FAQ and the answers to the hard questions (Chapter 27).
11. Finish the briefing book and run the analyst pre-briefs under NDA. Note every question you couldn’t answer well and fix the answer before the press pre-briefs.
12. Start the rehearsal eval for any AI beat: run the demo script repeatedly against the demo environment and record the pass rate. Agree the threshold for going live in advance.

Event week: rehearse under show conditions.

13. Hold a dress rehearsal at the venue, on the show network, with the production booth, and with as many audience devices as you can simulate. Run the reset procedure between every beat.
14. Make a live-or-recorded call for each beat, based on the rehearsal eval and the dress rehearsal. Write it down, with the name of the person who made it.
15. Do a final claims review of slides, script and press release against the readiness table. Remove any sentence that outruns its label.

After the event: measure and correct.

16. At 30 days, report reaction, learning and application. At 90 days, report business impact against matched non-attendees, intangibles and claim drift.
17. Fix claim drift where you find it: update enablement, correct the website, and brief account teams whose customers expected more than was announced.

The AI lens

Demoing AI products

AI products bring four demo risks that deterministic software mostly doesn’t.

Nondeterminism. Pin the model, generation settings and retrieval index. Constrain inputs to a rehearsed set and retain a canonical recording. Run the script repeatedly as an eval, agree a pass threshold in advance and record the pass rate. Chapter 31 covers eval design.

The audience becomes part of the system. At Meta Connect in September 2025, two smart-glasses demos failed. CTO Andrew Bosworth said the cooking demo’s wake phrase activated glasses throughout the building and overloaded their shared development server. He attributed a missing call notification to a previously unseen race condition. Model audience devices and shared infrastructure as demo dependencies.

Disclosure. The public record now has a clear pattern of AI demos that misled through what they left out.

• Google Gemini “Hands-on” video, December 2023. The video appeared to show Gemini responding live to drawings, gestures and a cup game. TechCrunch reported that Google had prompted the model with still frames and text, not live video or voice; the video description noted that latency had been reduced and outputs shortened. A Google DeepMind leader said the video illustrated what experiences could look like. Alphabet’s share price rose after the launch, so the cost wasn’t financial on day one; it was credibility, and the story that Google’s best demo had been staged.
• Google Duplex, May 2018. The stage demo of an assistant booking a salon appointment drew criticism because the people on the call weren’t told they were talking to a machine. Google then said it was designing the feature with disclosure built in. What an AI does to third parties during a demo is also a disclosure question.
• Tesla We, Robot, October 2024. Attendees interacted with Optimus robots that many assumed were autonomous. Reports confirmed they were teleoperated by people. A human in the loop is fine. An undisclosed human in the loop is the failure.
• Apple personalized Siri, 2024 to 2025. Features shown at WWDC 2024 appeared only in a produced video and were never demoed live to press. In March 2025 Apple said the features would take longer than it had thought to deliver, and it pulled a TV ad that promoted them. A class action alleging false advertising followed. John Gruber, writing at the time, pointed out that the features had never been demoed live, and treated that absence as the warning sign.
• Google Bard, February 2023. A promotional example for Bard gave an inaccurate answer about the James Webb Space Telescope. Alphabet’s shares fell sharply around the launch event, though coverage linked the drop to the underwhelming launch as a whole, not to the one error alone. Fact-check every AI output that appears in a launch asset.

Label editing, speed changes, staging and human assistance on screen. Explain seeded conditions aloud and identify AI interactions. Label concept videos as concepts.

Regulation. Two developments make disclosure more than good manners. In September 2024 the US Federal Trade Commission announced Operation AI Comply, a set of enforcement actions resting on the principle that there is no AI exemption from consumer protection law: claims about AI are advertising claims and need substantiation. In the EU, Article 50 of the AI Act sets transparency obligations: people must be told when they’re interacting with an AI system unless it’s obvious, providers of generative systems must mark synthetic content in a machine-readable way, and deployers must disclose deepfakes. The Act’s general application date, 2 August 2026, covers Article 50, but the Act has since been amended, so check the current scope and any transitional provisions with your legal team before any event with an EU audience. A keynote with an AI-generated presenter, synthetic voices or synthetic customer footage needs a label. Chapter 33 covers the regulation.

Guardrails are part of the value. Show approval gates, audit logs and cited evidence. Buyers and security reviewers need to see how the system handles uncertainty and constrains actions.

Doing the work with AI

An AI harness with connectors to your documents, CRM, product analytics and support system changes most of the event workload.

• Briefing books. Give the harness the PRD, the FAQ, the readiness table and the positioning (Chapter 24), and ask for a first draft of the briefing book. Ask it to mark every claim with its source and to flag any claim that outruns its readiness label.
• Hard questions. Ask the harness to play an analyst, a skeptical reporter and a security reviewer, and to generate the questions each would ask. Write the answers yourself, and get the sensitive ones approved.
• Claim checks. Before the final review, have the harness compare the keynote script, slides and press release against the readiness table, line by line. This is tedious for people and quick for a model.
• Rehearsal evals. For AI beats, the harness can run the demo script many times against the demo environment and summarize where outputs diverged. A person still decides what counts as a pass.
• Impact reports. Ask questions in plain language through your connectors: “Of accounts that attended, how many enabled the preview within 30 days, compared with similar accounts that didn’t attend?” Ask for the evidence behind each number and for the matching method, and read both before you trust the answer (Chapter 19).

Use approved tools for embargoed news, pricing and customer data. Check every drafted claim against the readiness table.

The Beacon case: Beacon Agents at Northlight Live

The readiness table. You start with labels, because everything else depends on them. Correlate and Diagnose are generally available. Act, with the human approval gate, goes to public preview at Northlight Live (the opt-in early access program in Chapter 25), with general availability planned for the next quarter. Autonomous actions on a customer’s allowlist of low-risk steps are in private preview. Per-resolved-incident pricing (Chapter 15) is announced as coming, with no price on stage. Engineering, legal and communications sign the table, and every slide carries the label for what it shows.

The event plan. The keynote segment is one piece. Around it you plan a breakout (“Inside Beacon Agents: how the approval gate works”), a hands-on lab in a seeded sandbox, an MSP partner session that shows Leo’s multi-tenant view, an analyst roundtable, and a security deep-dive for Sam’s audience covering audit logs, least-privilege access and the AI Act documentation EU customers have been asking for.

The sequence.

The keynote outline. The segment follows the sparkline. What is: Dana’s 3 a.m. page, thousands of alerts, a chat thread and a runbook. The call to adventure: what if the first responder already knew what broke? Three contrast cycles follow. Correlate turns thousands of alerts into a handful of incidents. Diagnose proposes a root cause with cited evidence from logs, traces and a recent deploy. Act proposes a rollback, with the approval gate on screen. The S.T.A.R. moment belongs to a customer SRE lead in Priya’s role, from a design-partner company: they approve the rollback from their phone, the seeded incident resolves, and they open the audit entry that Sam’s team would review. The customer proof is one before-and-after MTTR result, approved in writing by the customer. The call to action is to join the public preview and the lab that afternoon. The new bliss is an on-call rotation where people sleep.

The demo. The demo runs against a seeded incident in a demo environment modeled on a fictional retailer. The model version, generation settings and retrieval index are frozen. The applied AI engineers run the demo script 50 times as an eval, and the team agrees in advance that the live beat goes ahead only if at least 48 of the 50 runs produce the same root cause with the same evidence; otherwise the labeled recording plays. Early runs miss the threshold because the retrieval index is still updating overnight. Freezing it fixes the problem, and the finding goes into the risk plan.

The script includes three honesty moments. You say aloud that this is a seeded incident in the demo environment. The agent shows one hypothesis it isn’t confident about and explains why. And the rollback visibly waits for a human approval. You also rehearse a beat drawn from the hallucinated-root-cause storyline: the agent’s evidence for one hypothesis is weak, and the responder rejects it. In the breakout, that beat shows the product working as designed, which is the point the security reviewers in the room care about most.

The risk plan. The pre-mortem produces seven risks: conference Wi-Fi; audience devices loading the network; an MCP connector to a third-party observability tool timing out; the agent proposing a different root cause on stage; the approval notification arriving late on the phone; state left over from rehearsal; and a presenter improvising a claim beyond the readiness label. Each gets a likelihood, an impact, a mitigation, a trigger, a fallback and an owner. The last one gets the most attention. Executives are most likely to say “and soon it’ll do this on its own” in the moment, so the script gives the CEO an approved sentence about autonomy that names private preview.

The briefing book. The book for analysts and press has a fact sheet, the readiness table, an architecture view of the connectors and MCP servers, a summary of the guardrails and AI risk documentation, a customer reference list with approvals, the pricing position (per-resolved-incident pricing is coming; no numbers until it’s available), competitive framing against AIOps features in observability suites, incident tools adding AI, and humans with runbooks, and the hard questions with approved answers. One line in the PM’s private notes matters more than most of the book: the drop in gross margin from 81% to 72% after the agentic features launched is internal and isn’t for external use. You write down the approved answer for questions about inference cost, so nobody improvises a number.

The impact report. You set the measures before the event, so nobody picks them afterward to fit the result. Reaction: session ratings for the keynote segment, breakout and lab. Learning: lab completions. Application: preview activations within 30 days by attending accounts. Business impact: pipeline created and accelerated in attending accounts compared with matched accounts that didn’t attend, and the diagnosis acceptance rate among preview customers. ROI: attributable gross margin compared with Beacon’s share of the event cost. Intangibles: the tone of analyst notes and whether press coverage got the readiness labels right. And claim drift: support tickets and sales calls where customers expected autonomous actions that are only in private preview.

Product 360 artifacts

# Event plan · [Event name] · [Product] · v[n] · [Date]

**Event owner (marketing):** [Name]   **Product owner:** [PM]   **Claims sign-off:** [Product, legal, communications]
**Event date:** [Date]   **Location / format:** In person / virtual / hybrid

## Launches at this event
| Launch | Tier (Chapter 25) | Readiness label | Channel at event |
|---|---|---|---|
| | 1 / 2 / 3 | GA / Public preview / Private preview / Roadmap | Keynote / breakout / lab / blog / release notes |

## Readiness table (signed)
| Capability | Label | Evidence for the label | Signed by | Date |
|---|---|---|---|---|
| | | | | |

## Sessions
| Session | Format | Persona served | Presenter(s) | Demo? (live / recorded / hybrid) | Owner |
|---|---|---|---|---|---|
| Keynote segment | | | | | |
| Breakout | | | | | |
| Hands-on lab | | | | | |
| Partner session | | | | | |
| Analyst session | | | | | |
| Security or compliance deep-dive | | | | | |

## Audiences and what each must leave with
| Audience | What they need to see or hear | Where they get it |
|---|---|---|
| Users | | |
| Buyers | | |
| Security and compliance | | |
| Partners | | |
| Analysts | | |
| Press | | |

## Customer proof
| Customer | Claim it proves | Number(s) shown | Customer approval | Legal approval |
|---|---|---|---|---|
| | | | Pending / Approved | Pending / Approved |

## Key dates
- Readiness table signed: [Date]
- Keynote outline locked: [Date]
- Demo environment ready: [Date]
- Dress rehearsal: [Date]
- Final claims review: [Date]

## Success measures (set before the event)
See the event impact report.

# Announcement sequencing plan · [Announcement] · [Event] · [Date]

**Owner:** [PM with product marketing and communications]   **Embargo lift:** [Date, time, time zone]

| When | Audience | What they learn | Format | Under | Owner | Ready? |
|---|---|---|---|---|---|---|
| T−[n] weeks | Sales, support, partners | Full detail, readiness labels, FAQ, hard questions | Enablement session, FAQ | Internal confidentiality | | |
| T−[n] weeks | Analysts | Strategy, specifics, roadmap boundaries | Pre-brief | NDA | | |
| T−[n] days | Press | Release, briefing book, spokesperson access | Pre-brief | Embargo | | |
| T zero | Public | The announcement | Press release at embargo lift | | | |
| T zero | Event audience | The story and the demo | Keynote | | | |
| T zero to T+[n] days | Practitioners | Detail and hands-on | Breakouts, labs, webinar | | | |
| T+[n] weeks | Customers and partners | Fit for their accounts | Advisory boards, account reviews | | | |
| GA | Everyone | Availability | Release notes, blog, pricing page | | | |

## Embargo terms
- Embargo lifts at: [date, time, time zone]
- What is under embargo: [release, briefing book, demo video]
- What is never for publication: [internal numbers, unannounced pricing]
- What happens if it breaks: [communications owner's plan]

## Readiness gate for GA
GA is confirmed when: [criteria, such as eval thresholds, support readiness, security sign-off]. Not before.

## Leak plan
If the news leaks before lift: [who decides, what we say, which audiences we contact first]

# Keynote outline · [Event] · [Segment] · [Length] · v[n]

**Presenters:** [Names and roles]   **Tier 1 launch:** [Name]   **Readiness labels shown:** [List]

| # | Beat | Minutes | What is said (in one sentence) | What is shown | Demo? | Label on screen | Audience served (users / buyers / analysts and press) |
|---|---|---|---|---|---|---|---|
| 1 | What is | | | | | | |
| 2 | Call to adventure | | | | | | |
| 3 | Contrast cycle 1 | | | | | | |
| 4 | Contrast cycle 2 | | | | | | |
| 5 | Contrast cycle 3 | | | | | | |
| 6 | S.T.A.R. moment | | | | | | |
| 7 | Customer proof | | | | | | |
| 8 | Call to action | | | | | | |
| 9 | New bliss | | | | | | |

## Checks
- [ ] The audience, not the product, is the hero of the opening.
- [ ] Each of the three audiences has at least one beat aimed at them.
- [ ] Every capability shown matches its readiness label.
- [ ] The call to action is something the audience can do this week.
- [ ] The S.T.A.R. moment is true, rehearsed and has a fallback.
- [ ] Every number on screen has a source and an approval.

# Demo script · [Event] · [Segment] · v[n] · [Date]

**Presenter(s):** [Names]   **Demo engineer:** [Name]   **Booth switcher:** [Name]
**Environment:** [Name, isolated / shared]   **Data:** synthetic / seeded / other: [describe]
**Pinned:** product build [x], model version [x], generation settings [x], retrieval index snapshot [x], connector versions [x]
**Reset procedure:** [link or steps by name]   **Rehearsal eval:** [n] runs, pass threshold [x of n], last result [x of n] on [date]

## Situation summary (what is, 30 seconds)
[The customer's problem, in their words]

## Beats
| # | Words (what the presenter says) | Action | Expected screen | Time | Live / recorded | Abandon trigger | Fallback and line to say |
|---|---|---|---|---|---|---|---|
| 1 | | | | | | | |
| 2 | | | | | | | |
| 3 | | | | | | | |

## Honesty lines (said aloud or on screen)
- What is seeded or synthetic:
- What is recorded, edited or sped up:
- Where a human approves or assists:
- Readiness label for each capability shown:

## Words we never say
[Claims beyond the label, such as "fully autonomous" for a private preview capability]

## Go / no-go for live
Decided by [name] on [date], based on rehearsal eval [x of n] and dress rehearsal result [pass / fail].

# Demo risk plan · [Event] · [Segment] · [Date]

**Pre-mortem held:** [Date, attendees]
**Prompt used:** "It's the morning after the event and the demo failed. What happened?"

| # | Risk | Likelihood (H/M/L) | Impact (H/M/L) | Mitigation before the show | Trigger on stage | Fallback | Owner |
|---|---|---|---|---|---|---|---|
| 1 | Venue network fails or slows | | | | | | |
| 2 | Audience devices load the network or service | | | | | | |
| 3 | Third-party connector or API times out | | | | | | |
| 4 | AI output differs from rehearsal | | | | | | |
| 5 | Notification or device step delayed | | | | | | |
| 6 | State left over from rehearsal or a previous beat | | | | | | |
| 7 | Presenter improvises a claim beyond the label | | | | | | |
| 8 | [Other] | | | | | | |

## Rehearsal record
| Date | Conditions (venue, network, load) | Runs | Pass | Issues found | Fixed? |
|---|---|---|---|---|---|
| | | | | | |

## Disclosure check
- [ ] Edited, sped-up, staged or human-assisted segments are labeled on screen.
- [ ] Anyone interacting with an AI during the demo is told so.
- [ ] Synthetic voices, faces or footage are labeled.
- [ ] Legal has reviewed the demo for markets with disclosure rules.

# Briefing book · [Announcement] · [Event] · [Date]

**Confidential until:** [embargo lift, date, time, time zone]   **Spokespeople:** [Names]   **Owner:** [PM with communications and analyst relations]

## 1. Fact sheet (one page)
- What we're announcing:
- Who it's for:
- What problem it solves:
- Availability:

## 2. Readiness table
| Capability | Label | Available from | Notes |
|---|---|---|---|
| | | | |

## 3. How it works
[Architecture view: components, connectors, data flow, where AI is used]

## 4. Guardrails and risk (AI products)
- Human approval points:
- Audit and logging:
- Data handling and residency:
- Evaluation approach:
- Regulatory documentation available:

## 5. Customer references
| Customer | Use case | Result | Approved to name? | Approved to quote numbers? | Contact |
|---|---|---|---|---|---|
| | | | | | |

## 6. Pricing position
[What we say about pricing; what we don't say yet]

## 7. Competitive framing
| Alternative | How we compare | What we don't claim |
|---|---|---|
| | | |

## 8. Hard questions and approved answers
| Question | Approved answer | Approved by |
|---|---|---|
| | | |

## 9. Internal only (never in the book that leaves the building)
[Numbers and facts spokespeople must know but must not share, with the approved deflection for each]

## 10. Embargo terms
[What is embargoed, until when, and the contact for questions]

# Event impact report · [Event] · [Product] · [30-day / 90-day] · [Date]

**Owner:** [PM]   **Sources:** [CRM, product analytics, support, survey, analyst and press coverage]   **Measures set before the event on:** [Date]

## Summary
[Three sentences: what we announced, what changed, how confident we are]

## Results by level
| Level | Measure | Target | Result | Evidence |
|---|---|---|---|---|
| 1. Reaction and planned action | Session ratings; intent to adopt | | | |
| 2. Learning | Lab completions; certifications | | | |
| 3. Application | Preview or feature activations within 30 days by attending accounts | | | |
| 4. Business impact | Pipeline created and accelerated, attendees vs matched non-attendees; product outcome metrics among adopters | | | |
| 5. ROI | Attributable margin vs the product's share of event cost | | | |
| Intangibles | Analyst note tone; press accuracy on readiness labels; share of voice | | | |

## Isolating the event's effect
- Comparison group and how it was matched:
- Other things that changed in the same period:
- Confidence in the difference (high / medium / low) and why:

## Claim drift
| Source (ticket, call, review) | What the customer expected | Actual readiness | Action taken |
|---|---|---|---|
| | | | |

## What we'd change next time
1.
2.
3.

Prompts

Goal: Get every capability you might mention at the event into one table with an honest readiness label.
Paste in: the PRD or launch brief, the release plan, current eval results and any known gaps. Use an approved tool for unannounced product information.

From the material provided for [product] at [event], list every capability a presenter, press release or briefing might mention.

For each capability give:
1. A readiness label: Generally available, Public preview, Private preview or Roadmap, using these definitions: [paste your definitions].
2. The evidence in the material for that label, with the document and section.
3. Any gap between how the material describes the capability and what the evidence supports.

Then list every phrase in the material that a presenter could easily stretch beyond its label (for example "autonomous", "fully", "any", "instantly"), and suggest a bounded rewrite.

Assign labels only from cited evidence. Mark missing evidence as an open question.

Check the output: confirm each label with the engineering lead who owns the capability. Any capability the model labeled GA without citing evidence goes back for review.

Goal: Draft a keynote outline that moves between what is and what could be, with each audience served.
Paste in: the positioning (Chapter 24), the readiness table, the customer story and the segment length.

Draft a [length]-minute keynote segment for [product] at [event], using Nancy Duarte's structure: what is, call to adventure, three contrast cycles between what is and what could be, one S.T.A.R. moment, customer proof, call to action and new bliss.

For each beat give: the one-sentence message, what is shown, whether it needs a demo, the readiness label on screen and which audience it serves most (users, buyers, or analysts and press).

Rules:
- The audience is the hero; the product is the mentor's tool.
- Open in the customer's words.
- Every capability stays inside its readiness label.
- The call to action must be something the audience can do this week.

Check the output: read the outline as each of the three audiences. If one of them has no beat, fix it. Strike any beat that shows a roadmap item with launch-level production.

Goal: Turn a demo idea into a beat-by-beat script that survives failure.
Paste in: the keynote outline, the demo environment description, the readiness table and the time available.

Write a demo script for [segment] at [event]. Follow Peter Cohan's "do the last thing first" approach: open with a short situation summary of the customer's problem, show the result early, then the shortest path to it.

For each beat give: the presenter's words, the action, the expected screen, the time, whether it runs live or recorded, the trigger to abandon it, the fallback and the line the presenter says when switching.

Add a section of honesty lines: what is seeded, what is recorded or edited, where a human approves, and the label for each capability. List risky claim phrases alongside the approved wording to use instead.

Check the output: time it aloud; the script should fit in 80% of the slot. Make sure every beat has a fallback a person in the booth can trigger in under ten seconds.

Goal: Find what will go wrong with the demo before the audience does.
Paste in: the demo script, the environment and dependency list, and venue details (network, expected audience size, devices).

Imagine it's the morning after [event] and the [segment] demo failed in front of the audience. Write the ten most likely explanations for what happened, including:
- network and venue failures;
- the audience's own devices or accounts acting as load or interference;
- third-party services, connectors or APIs;
- AI output that differs from rehearsal;
- state carried over from rehearsal or from an earlier beat;
- a presenter saying something beyond the readiness label.

For each, give likelihood and impact (high, medium, low), a mitigation before the show, the on-stage trigger, the fallback and a suggested owner role.

Check the output: add any risk your team has seen at past events that the model missed. Every high-impact risk needs a named person, not a role, before you're done.

Goal: Produce a first draft of the briefing book, with internal-only facts clearly separated.
Paste in: the PRD, FAQ, readiness table, positioning, pricing position, customer reference approvals and competitive analysis. This includes embargoed and confidential information: use only a tool your company has approved for it.

Draft a briefing book for [announcement] with these sections: fact sheet, readiness table, how it works, guardrails and risk, customer references, pricing position, competitive framing, hard questions with draft answers, and embargo terms.

Then:
1. Play three roles in turn (an industry analyst, a skeptical technology reporter and an enterprise security reviewer) and list the ten hardest questions each would ask.
2. Mark any fact in the source material that looks internal (margins, costs, unannounced prices, customer names without approval) and move it to a separate "Internal only" section with a suggested deflection.
3. Cite the source document for every claim.

Check the output: legal and communications approve the hard-question answers. Confirm the internal-only section is removed from any version that leaves the company.

Goal: Catch claims in the script, slides and release that outrun what is ready.
Paste in: the keynote script, slide text, press release and the signed readiness table.

Compare every sentence in the script, slides and press release with the readiness table for [product].

List each sentence that:
1. mentions a capability without its readiness label;
2. implies a capability is more available, more autonomous or more general than its label allows;
3. states a number without a source or approval;
4. shows or describes an AI-generated, edited or human-assisted segment without disclosure.

For each, quote the sentence, say which rule it breaks and propose a bounded rewrite.

Check the output: read the flagged sentences yourself. Then spot-check five sentences the model didn't flag, because over-trusting a clean result is the usual mistake.

Goal: Report what the event changed, with the evidence and the uncertainty visible.
Paste in (or connect the harness to): attendance and session data, lab completions, CRM pipeline data, product analytics for the announced features, support tickets and sales call notes from the 30 or 90 days after the event, and analyst and press coverage. Use an approved tool for customer data.

Draft an event impact report for [event] and [product] at [30 / 90] days, using these levels: reaction and planned action, learning, application, business impact, ROI and intangibles.

For each measure, show the target set before the event, the result and the evidence. For business impact, compare attending accounts with a matched set of similar accounts that didn't attend; describe how they were matched and what else changed in the period.

Then search support tickets and sales notes for claim drift: cases where a customer expected the product to do something that is only in private preview or on the roadmap. Quote each case with its source.

Check the output: read the matching method before the results. If the comparison group isn't similar, treat the business-impact numbers as directional and say so in the summary.

Anti-patterns

Checklist

• Only tier 1 launches have keynote time; tier 2 and 3 have the right lesser channels.
• A signed readiness table exists, and every slide, script line and release sentence carries the right label.
• The announcement sequence covers internal enablement, analyst pre-briefs, press pre-briefs, embargo lift, keynote, follow-on sessions and GA, each with an owner.
• The keynote outline follows the sparkline and gives users, buyers, and analysts and press each at least one beat.
• The demo opens with the result and keeps every beat inside its readiness label.
• The demo environment is isolated, seeded with synthetic data, version-pinned and reset before every run.
• Every demo beat has an abandon trigger, a fallback, a switching line and a named person in the booth.
• For AI beats, a rehearsal eval has run with a pass threshold agreed in advance.
• A pre-mortem has produced a demo risk plan with owners, including audience load and presenter improvisation.
• Edited, sped-up, staged, synthetic or human-assisted segments are labeled on screen, and legal has reviewed disclosure for every market in the audience.
• Every customer number on stage has written approval from the customer and from legal.
• The briefing book separates internal-only facts, and every spokesperson knows the approved answers to the hard questions.
• Impact measures were set before the event, and the report compares attendees with matched non-attendees.
• Claim drift is tracked for 90 days, and every case gets a correction.