live-presentation

name	live-presentation
description	Plan and deliver engaging 1:M physical presentations — conference talks (AWS Summit, re:Invent), internal sessions (Floor 28, team all-hands), meetups, and customer briefings. Use when a user is preparing a live in-person talk for an audience.

Live Presentation (1:M Physical)

Scope

Any in-person presentation where one speaker (or co-speakers) presents to a seated audience:

• Conference breakout sessions (AWS Summit, re:Invent, community days)
• Internal knowledge-sharing (Floor 28, brown bags, tech talks)
• Customer-facing briefings and demos
• Meetup and community talks
• All-hands and town halls

Planning Process

1. Define the session — topic, audience level (L100-L400), duration, venue constraints
2. Research — use deep_research for content depth, competitor talks, audience expectations
3. Structure — build the narrative arc
4. Create deliverables — slide outline, speaker notes, demo plan

Session Structure Template

Opening (10-15% of time)

• Hook — surprising stat, provocative question, or relatable pain point
• Credibility — brief intro establishing why you're the right speaker
• Promise — what the audience will walk away with (be specific)
• Agenda preview — 3-4 bullet road map

Body (70-80% of time)

• 3-5 key points — each with its own mini-arc:
  • Assertion → Evidence → Example → Takeaway
• Progressive disclosure — start broad, go deep
• Pattern interrupts every 7-10 minutes:
  • Live demo or code walkthrough
  • Audience poll or question
  • Story or anecdote
  • Shift from slides to whiteboard
• Transitions — explicit bridges between sections

Closing (10-15% of time)

• Recap — 3 bullet summary of key takeaways
• Call to action — what should they do next?
• Resources — QR code to slides, repo, docs
• Q&A — leave 5-10 min

Best Practices

Content Design

• One idea per slide — if you need a "build" use animation or multiple slides
• Maximum 3 bullet points per slide; prefer visuals/diagrams
• Every slide must pass the "so what?" test — why does the audience care?
• Include a "why should I care?" moment in the first 2 minutes
• L200+ sessions: lead with the architecture diagram, then drill down
• Never read your slides — they're visual aids, not a script

Delivery

• Rehearse out loud at least 3 times (not just in your head)
• Time yourself — cut 10% to leave breathing room
• Arrive early — test A/V, walk the stage, feel the room
• Make eye contact with different sections of the room
• Pause after key points (3 seconds feels long, but works)
• Move with purpose — don't pace, but don't stand frozen either

Audience Engagement

• Ask a question in the first 5 minutes ("raise your hand if...")
• Use live polls (Slido, Mentimeter) for large audiences
• Build in "turn to your neighbor" moments for sessions > 30 min
• Acknowledge expertise in the room ("some of you probably know more about X")
• Have a backup plan if demos fail

Technical Talks Specifically

• Show the demo first, explain the theory second (invert the textbook)
• Use real-world scale numbers, not toy examples
• Include a "what can go wrong" section — audiences love war stories
• Link to code repos — attendees want to reproduce what you showed
• Architecture diagrams: start with the 10,000ft view, then zoom in

Common Mistakes

• ❌ Too many slides (>1 per minute of talk time)
• ❌ Starting with "about me" for more than 30 seconds
• ❌ No clear takeaway — audience leaves unsure what they learned
• ❌ Reading from slides or notes
• ❌ Skipping rehearsal — "I'll just wing it"
• ❌ Demo-heavy without backup screenshots/video
• ❌ Ending with "any questions?" to silence (prime Q&A with a planted question)
• ❌ Running over time — shows disrespect for audience
• ❌ Assuming homogeneous audience level

Checklist

2 Weeks Before

• Session structure finalized
• Key messages defined (max 3)
• Slides in draft
• Demo environment prepared
• Backup plan for demo failures (screenshots/video)

1 Week Before

• Full rehearsal (timed)
• Slides reviewed by a peer
• Speaker notes complete
• QR code/short URL for resources
• Tech check scheduled (A/V, screen resolution, clicker)

Day Of

• Arrive 30 min early
• Test display, audio, clicker, internet
• Water bottle ready
• Phone on silent
• Opening line memorized (don't fumble the start)
• Backup slides on USB drive

After

• Share slides/recording within 24 hours
• Collect feedback (survey link or verbal)
• Note what worked and what didn't for next time

AWS-Specific Tips

• For Summit/re:Invent: sessions are recorded — speak clearly for transcription
• AWS sessions use the "Builder" angle — always show how to DO it, not just what it IS
• Include a "get started in 5 minutes" moment
• Reference Well-Architected Framework pillars where relevant
• Floor 28 sessions: more informal, encourage interruptions, bring a live terminal