Audience

One you’ve got your idea, the next thing to think about is your audience. Who do you want to tell this idea to, and who would be interested in it? That question informs a lot of what comes next.

Here’s an example from my experience. I do talks about container security, Docker and Kubernetes. If I take that talk to a Kubernetes conference like KubeCon, I can assume the audience already knows Kubernetes, so I won’t explain the basics there. But they may not know security, so I will explain the security side and won’t assume any security knowledge. If I give the same talk at a security conference, I flip it around: these people know security, so I don’t need to cover the basics, but I do need to explain Docker and Kubernetes because I can’t assume they’ll know it.

So think about the kind of people you want to reach, and it might be several different groups. Keep that in mind as you develop the talk, because it helps you decide what information you need to include. You don’t want to pile on introductory security material at a security conference, and equally you don’t want to dive straight into the deep end of your topic at a venue where the audience won’t have the all the necessary background knowledge like acronyms, industry terms, and so on. If they don’t have that grounding, you can lose the audience quite early on, the talk might be great, but they can’t relate it to what they know.

Keeping your audience in mind minimises that risk. For example if you were doing a talk about Cross-Site Scripting at a Javascript development conference, you could think, “If I were a JavaScript developer, what do I already know, and how do I get from there to the topic at hand?” Keep your audience at the back of your head the whole time you’re building the talk.