Step 332. Building Seminar Talk Materials — Designing What the Audience Takes Home

Level 4 — Professional | Difficulty ★★★☆☆ | Estimated time: 2 days (half a day of topic selection + 1 day of slide building + half a day for 2 rehearsals)

Prerequisites: Step 331’s mentoring session materials (your material warehouse), the note habits of Steps 329–330. You must be able to pull out one signature technique from your main track.

What you need: a slide tool (PowerPoint, Google Slides, a Markdown slide tool — anything), a stopwatch or phone timer (for measuring rehearsal time), and a demo-recording tool (a screen recorder). This chapter is a document-production assignment, so every deliverable example is a screen example.
Caution: when including real bug-bounty reports or CVE analysis in talk materials, always confirm publication approval (embargo lifted) first.
⚠️ All exercises in this chapter are for your own lab and legal platforms only. Applying them to unauthorized systems is a crime. Talk demos are also performed only in your own lab environment.

A good technical talk is not "a listing of what I know" but "a design of what the audience takes home." Even carrying the same knowledge, what separates a talk that stays in the audience’s head from one that doesn’t is not the amount of knowledge — it’s the structure.

Today you complete a 30-minute seminar talk from scratch. The basic structure is fixed — problem statement (why this topic matters) → background (what the audience won’t know) → core content (demo included) → summary (the one sentence to take home). Pick one signature technique from your main field as the topic, lay 15–20 slides onto this structure, and polish it through rehearsals — that’s today’s assignment.

1. Learning Objectives

By the end of this chapter, you will be able to:

Select a talk topic by the criterion of "among what I’m good at, what’s useful to the audience"
Define the audience level (beginner/intermediate) and tune depth to match
Design a 30-minute talk’s 4-part structure (intro 3 min → background 5 min → core + demo 17 min → summary 5 min)
Build 15–20 slides on the "one message per slide" principle
Complete the talk by cutting excess material through 2 rehearsals (with time measurement)

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

Category	Details
Language/environment	A slide tool (any), a screen recorder (for demo backup), a timer
Today’s command	Design tools, not commands — the topic-selection table, the 4-part structure, the slide outline, the rehearsal record sheet
Concepts needed	Audience-centered design, one message per slide, live-demo failure variables, rehearsal cut editing
Today’s deliverable	A 30-minute talk deck of 15–20 slides + a recorded demo backup + 2 rehearsal records

2-1. Audience-Centered Design — The Difference Between Listing and Designing

The first mistake of talk preparation is "putting in everything I know." An audience remembers no more than 3 things from a 30-minute talk — so even if you put everything in, only 3 remain. The problem is that which 3 remain is random.

Designing means the speaker makes that selection on the audience’s behalf. Decide "the one sentence this talk must convey" first, and boldly discard everything unrelated to that sentence. That one sentence is both the blueprint of the entire talk and the editing criterion.

2-2. The 4-Part Structure — Allocating 30 Minutes

Part	Time	What it does
Intro (problem statement)	3 min	Why this topic matters — presented as the audience’s problem
Background	5 min	Only what the audience won’t know — no re-explaining what everyone knows
Core + demo	17 min	The main body. The demo must run 5+ minutes to avoid boredom
Summary + Q&A	5 min	Repeat the one sentence to take home; take questions

The intro’s criterion is "the audience’s problem." Not "today I’ll talk about IDOR," but starting from the audience’s seat — "what if changing one number in the URL of the API you built exposed someone else’s data?" The background’s criterion is "only what the audience won’t know" — five minutes re-explaining HTTP basics to a beginner audience wastes both sides’ time.

2-3. Slide Rules — One Message per Slide, Code Big

There are three slide rules.

Rule	Details	Symptom of violation
One message per slide	One claim per slide	The audience reads instead of listening
Code big	Readable from the back row (24pt+)	The mid-talk question "I can’t see it"
Demo with recording backup	Live + pre-recorded in parallel	A demo failure halts the entire talk

Especially the third — a live demo always has failure variables. Network, environment, nervous hands. The reason even pro speakers prepare a recording backup is not lack of skill but probability management. With a recording ready, you can attempt the live demo boldly — if it fails, you just switch.

2-4. Rehearsal — A Talk Is Not Written, It’s Whittled

A first-draft talk is almost always too long — the result of putting in everything you know. Rehearsal’s purpose is not practice but editing. Twice, out loud, alone, with a timer — then cut the excess.

The cut-editing criterion is 2-1’s "one sentence." A slide not on the path to that sentence gets discarded no matter how splendid. And a preview talk at Step 331’s mentoring session is the best rehearsal — a real audience’s faces tell you "do they get bored here."

3. Follow Along

3-1. Selecting the Topic — The Intersection of Three Conditions

Pick the topic from the intersection of three conditions.

Topic-selection table (screen example):
Condition 1. What I'm best at — a technique I've repeatedly succeeded with in my track
Condition 2. Useful to the audience — can listeners use it next week
Condition 3. Fits in 30 minutes — is it one self-contained story

[Candidate evaluation example]
- "Finding IDOR in the wild"         : 1 O / 2 O (beginners can try right away) / 3 O  <- selected
- "Intro to kernel exploitation"     : 1 O / 2 △ (audience must be intermediate) / 3 X (exceeds 30 min)
- "My bug bounty grand total"        : 1 O / 2 X (fun to watch, nothing to take home) / 3 O

How to read it: topics that fail condition 2 are the most common trap — "what I worked hard on" and "what the audience takes home" are different. Topics like "intro to CTF pwnables," "analyzing vulnerabilities via patch diffs" — are good because the listener’s next action is clear.

3-2. Defining the Audience and the "One Sentence"

Once the topic is set, define the audience in a sentence and write the talk’s one sentence.

Audience definition and one sentence (screen example):
- Audience: 6 months to 1 year into security. Know web basics (HTTP,
  sessions), have never done vulnerability assessment. 20 people.
- The one sentence this talk must convey:
  "IDOR starts with just changing the number — you can verify it in your
   own lab today."
- The 3 things the audience takes home:
  1. Can explain what IDOR is in one sentence
  2. Know the procedure to reproduce it in their own lab
  3. Know the legal practice grounds (own lab, bug bounty scope)

How to read it: the "3 things to take home" become the slide chapters. Content not on this list is a discard candidate for the entire production process ahead.

3-3. Designing the Slide Outline — Laying Out 15–20 Slides

Complete the outline first; fill the slides later. Here’s an outline example for a 30-minute talk.

Slide outline (screen example) — "Finding IDOR in the wild," 30 min, 17 slides total:
 1. Cover — title, name, affiliation
 2. [Intro] Problem statement: "I changed one number in the address bar
    and saw someone else's order history"
 3. [Intro] How common this actually is — one slide of stats and cases
 4. [Background] IDOR defined in one slide — "the absence of an
    authorization check"
 5. [Background] Authentication vs. authorization — one diagram
 6. [Background] Where it hides — URLs, parameters, API paths
 7. [Core] Procedure overview — a 4-step diagram (observe → tamper →
    compare → confirm)
 8. [Core] Step 1: Observe — finding identifiers in my account's requests
 9. [Core] Step 2: Tamper — changing numbers; what if it's a UUID?
10. [Core] Step 3: Compare — cross-checking with two accounts
11. [Core] Step 4: Confirm — truly vulnerable or intentionally public
12. [Demo] Reproduction in my lab — 5-min screen recording (live + backup)
13. [Core] Cautions in the field — legal scope and ethics
14. [Core] How to fix it — one slide on server-side authorization checks
15. [Summary] Today's one sentence (repeated)
16. [Summary] The 3 takeaways + where to practice
17. Q&A — contact and materials-publication URL

How to read it: two laws of placement. ① The demo (#12) sits at the talk’s center — audience attention sags mid-talk, so you place the strongest content (live action) at the sagging point. ② "How to fix it" (#14) is included — a talk covering only attacks is half a talk for a beginner audience; the defensive view completes the understanding of "why this is a vulnerability."

3-4. Building the Slides — Two Completed Examples

Fill each outline slide with "one message per slide." Here’s slide 4 (the definition) completed.

[Slide 4 completed example — screen example]
┌─────────────────────────────────────────────┐
│                                             │
│   IDOR = the server never checks            │
│          "is this data yours"               │
│                                             │
│   (small figure below: browser → /order/1001│
│    → server → responds "without asking who  │
│    owns 1001")                              │
│                                             │
└─────────────────────────────────────────────┘
Speaker notes: "IDOR's formal name is Insecure Direct Object Reference,
but you may forget the formal name. What to remember is this one line —
the server doesn't ask. Not whether you're logged in (authentication),
but whether this data is yours (authorization)."

How to read it: the slide body has one message line and one figure; the explanation lives in the speaker notes. This separation is the implementation of "one message per slide" — what you show the audience (slide) and what you tell them (notes) must be different channels, so the accident of reading-instead-of-listening can’t happen. Slides carrying code (like #9) must stay within 5–7 lines, at 24pt or larger.

3-5. Preparing the Demo — Redundancy of Live and Recording

Prepare the demo (slide 12) in two copies.

Demo-preparation checklist (screen example):
[ ] Live demo environment — final check of my lab the day before
    (in snapshot/backup state)
[ ] Live demo script — what I'll type prepared in a text file
    (prevents nervous typos)
[ ] Pre-recorded video — an mp4 screen recording of the same demo
    (≤5 min, with captions/zoom)
[ ] Transition cue — pre-written in speaker notes: "if the demo fails:
    'the environment isn't cooperating. Let me show you the recording'
    + play the video"

How to read it: the "transition cue" is the difference between pro and amateur — failure is a matter of probability, but a smooth post-failure transition is a matter of preparation. Audiences forgive a failed demo; they remember 30 seconds of flustered silence.

3-6. Two Rehearsals — Time Measurement and Cut Editing

With the completed deck, deliver it out loud alone twice and record.

Rehearsal record (screen example):
[Run 1] Total 38 min — 8 over. By section: intro 4 / background 9 (4 over)
        / core+demo 19 / summary 6
        Observed: auth-vs-authz explanation ran long in background;
        rambled at slide 9 (UUID)
        Action: deleted background slide 5 (audience already knows it);
        added keywords to slide 9
[Run 2] Total 29 min — intro 3 / background 5 / core+demo 17 / summary 4
        Observed: slide 10 (cross-check) stalled again in run 2 —
        preview talk scheduled at the mentoring session

How to read it: with per-section times visible, cut editing’s targets get set scientifically — not "somewhere is long" but "background is 4 minutes over." And run 1 at 38 min → run 2 at 29 min is the normal trajectory. If it’s 30 minutes from the start, that may not be luck — it may mean the material is thin.

4. Missions & Exercises

Mission — Complete a 30-Minute Seminar Talk Deck

Pick a topic with 3-1’s selection table and record whether it passes the three conditions.
Write the audience definition, the "one sentence," and the "3 takeaways" in 3-2’s format.
Design a 15–20 slide outline like 3-3 — with the 4-part structure and time allocation marked.
Build the slides — one message per slide, code at 24pt+, speaker notes included.
Redundancy-prepare the demo (live + recording) with 3-5’s checklist, and perform 2 rehearsals with time measurement, recording them.

Exercises

Exercise 1. Explain the implication of "the audience remembers no more than 3 things" for talk preparation, through the difference between "a talk with everything in it" and "a designed talk."

Exercise 2. Explain why the demo is placed at the talk’s center (midway) in the 4-part structure, connecting it to the audience attention curve.

Exercise 3. Explain why separating slide body and speaker notes is the implementation of the "one message per slide" principle.

Exercise 4. From the perspective that rehearsal’s purpose is "editing," not "practice," explain why per-section time measurement is the precondition of cut editing.

5. Model Answers & Completion Criteria

Mission Model Answer

Check against these verification criteria.

Grounds for the topic: is the three-condition evaluation (good at / useful / self-contained) recorded — "it sounded fun" is not grounds.
Existence of the one sentence: were the "one sentence to convey" and "3 takeaways" written before deck production.
Outline structure: are the 4-part structure (intro, background, core+demo, summary) and time allocation marked on the outline, with the demo midway.
Slide discipline: pick any slide — does it carry one message, are code slides in large fonts, do speaker notes exist.
Evidence of rehearsal: are there 2 runs of per-section time records with corresponding actions (deletions, fixes).

Exercise Answers

Answer 1. A talk with everything in it abandons the choice of which 3 things remain to the audience’s random selection — there’s no guarantee what the speaker most wanted to convey survives, and the more information, the shallower each item’s imprint. A designed talk has the speaker pre-select those 3 things and arranges every slide to converge on them — deepening the imprint through repetition and structure. The implication is the direction of editing — a talk’s quality is decided by the skill of deletion, not addition, and the deletion criterion is the "one sentence to convey." The urge to put everything into the deck is a normal impulse every speaker faces; restraining that impulse with one sentence is design.

Answer 2. Audience attention sags deepest 15–20 minutes into a talk — the point where the intro’s novelty has worn off and the main body’s density rises. If text slides continue at that point, the sagged attention doesn’t recover, but a demo (live action) causes a channel-switch effect — from watching to observing — and pulls attention back up. So the demo goes neither early (attention is still high, so it’s wasted) nor late (already scattered, so unrecoverable) but at the center. The rule "the demo must run 5+ minutes to avoid boredom" is the concrete implementation of this curve management.

Answer 3. If a slide carries many sentences, the audience starts reading — and while reading, they don’t hear the speaker: the visual and auditory channels compete for the same content. Separating body (one message line + figure) and notes (detailed explanation) divides the two channels’ roles — the slide is the anchor of "what this is about," and the speaker’s voice carries the explanation loaded onto that anchor. Only with this separation does "one message per slide" work as a physical constraint rather than a slogan — because two messages simply don’t fit on one slide.

Answer 4. A first-draft talk almost always runs over time, so rehearsal’s essence is the decision of "what to remove." But knowing only the total (38 min) leaves where to cut to intuition — and cutting by intuition makes the mistake of keeping the part you’re attached to (usually not the core but the part that took effort). Per-section times expose where the excess lives — knowing "background is 4 minutes over" makes clear which cell of the 4-part structure to cut, concentrating the "one sentence" criterion’s restraint on that cell. Editing without measurement is sentiment; only editing with measurement is reproducible skill.

Completion Criteria Checklist

[ ] I picked a topic that passed the three conditions (good at / useful / self-contained) with the selection table
[ ] I documented the audience definition, the "one sentence to convey," and the "3 takeaways"
[ ] I completed a 15–20 slide outline with the 4-part structure and time allocation marked
[ ] Every slide has one message and speaker notes
[ ] Code slides are 24pt+ and within 5–7 lines
[ ] The demo is redundant (live + pre-recorded) with a transition cue in the notes
[ ] I confirmed publication approval for content requiring it (bug reports, CVEs)
[ ] I performed 2 rehearsals with per-section time measurement and recorded the actions taken

6. Common Pitfalls & Fixes

Wall 1. I wanted to include everything and ended up with 40 slides

Symptom: it’s a 30-minute talk but the outline reached 40 slides, over an hour estimated.

Cause: exactly 2-1’s trap — the design started as "a listing of what I know."

Fix: reverse the procedure. ① Fix "the one sentence to convey" and the "3 takeaways" first (3-2). ② Allocate only 4–5 slides to each of the 3 takeaways. ③ Push everything else into "appendix" slides — material you pull out during Q&A when a related question comes. The appendix isn’t deletion but standby, so the psychological resistance to cutting drops. And remember — the audience remembers 3 things anyway. A 40-slide talk lets the audience choose the 3; a 17-slide talk has the speaker choose for them.

Wall 2. In rehearsal I stall at every slide — is the deck wrong?

Symptom: delivering out loud, transitions between slides break, and at some slides nothing to say comes to mind.

Cause: one of two things — the slide order doesn’t match the story’s causality (a structure problem), or the speaker notes are empty (a preparation problem).

Fix: the distinction — a slide that still stalls after the notes are filled is a structure problem. That slide has no answer to "why does this slide come after the previous one." Write transition sentences into the notes ("having seen ~, the remaining problem is ~"), and a slide whose transition sentence won’t write gets reordered or discarded. Stalling is not lack of speaking practice — it’s the material signaling a structural problem.

Wall 3. Recording the demo, the on-screen text is too small

Symptom: you recorded a terminal demo and the commands are unreadable in the video.

Cause: a font comfortable on your monitor is too small for video and projectors — resolution compression and viewing distance.

Fix: before recording, double the terminal font from your usual (usually 24pt+), and record the window at half size rather than full screen — the smaller the window, the relatively bigger the text looks. Reinforce key input portions with screen zoom or captions. Finally, verify — move the recorded video to your phone. If it reads on a phone screen, it reads from the back row of a lecture hall.

Wall 4. I want to include a vulnerability I reported, but I’m not sure it can be public

Symptom: you want to use a case reported in Steps 318–319 as an example, but you’re unsure whether naming the service is okay.

Cause: publishing report content depends on the program’s disclosure policy and whether the embargo has lifted.

Fix: the rule is simple — without explicit publication approval, strip identifying information. Remove the service name, domains, and identifying elements from screenshots, generalizing to "a certain commerce service." Use named cases only when the patch is complete and the program permits disclosure. When uncertain, anonymization is always correct — the talk’s value is in the technique, not the service’s name. And demos are done only in your own lab environment, unconditionally.

Wall 5. Two rehearsals and I’m still at 35 minutes — I can’t see what else to cut

Symptom: you measured per-section times, but every slide seems too precious to remove.

Cause: a speaker’s attachment forms from their own perspective — the limit of rehearsing alone.

Fix: borrow an audience — do a preview talk at Step 331’s mentoring session. In front of a real audience, "bored faces" and "nodding faces" get recorded per slide. Slides with no audience reaction are the slides to cut. If that still fails, change the question — not "what do I remove" but "if I could keep only one slide, which is it?" This extreme question exposes the ranking of your attachments.

7. Summary

Today’s Concepts

Concept	One-line explanation
Audience-centered design	Listing what you know ✕, designing what they take home ○
The one sentence to convey	The talk’s blueprint and the deletion criterion
4-part structure	Intro 3 → background 5 → core+demo 17 → summary 5 (for 30 min)
One message per slide	Separation of body (anchor) and speaker notes (explanation)
Demo redundancy	Live + recording backup + transition cue — probability management
Rehearsal = editing	Per-section time measurement is the precondition of cut editing

Today’s Tools & Commands

Tool/form	What it does
Topic-selection table	Evaluates the three conditions: good at / useful / self-contained
Audience definition + one sentence	Fixes depth tuning and the editing criterion
Slide outline	4-part structure, time allocation, demo placed centrally
Speaker notes	The physical implementation of one message per slide
Demo-preparation checklist	Environment check, script, recording, transition cue
Rehearsal record sheet	Per-section time measurement and record of actions

The Core Instinct

When the talk deck is done, a strange byproduct remains — your own understanding of that topic is far more organized than before the talk. Compressing into one sentence, splitting into per-slide messages, and fixing stalling transitions is the Feynman technique of Step 331 run at scale. Building talk materials is not an output of knowledge — it’s its final refinement.

Now the materials are complete and rehearsals done. What remains is the stage — in the next Step 333 you stand before a real audience, publish the materials, and receive feedback, closing this cycle. The materials are ready. Only the going-out remains.

Once every box is checked, Step 332 is complete.