Need someone to lead product management at your software company? I create software for people that create software and I'm looking for my next opportunity. Check out my resume and get in touch.

Speaking for Geeks: Writing Your Talk

Freshness Warning
This blog post is over 8 years old. It's possible that the information you read below isn't current and the links no longer work.

Once you’ve settled on what you’re going to speak about and have had your talk accepted by an event, it’s time to write your talk.

Step one: don’t wait until the night before the talk to write it. Crazy, I know, but it doesn’t yield great results. You’d be surprised how often at conferences I hear “Can’t go out tonight, I have to write my talk for tomorrow.” Your audience has taken time out of their lives to be here. They’re giving you their time. Perhaps they’ve even spent a lot of money to come. You owe them the courtesy of being prepared.

You should start preparing at least a month before your talk. Even longer is better. I find that additional ideas and thoughts percolate after I’ve written the initial draft. You’ll also want time to rehearse your presentation at least 10 times (more on that later).

Writing your talk does not mean you open up PowerPoint or Keynote. While you might create slides to use during your presentation, presentation software isn’t very good for writing. When you try and write your talk in Powerpoint, you tend to focus on the style and design instead of the content.

You’ll use the story framework to guide your talk, but you don’t need to start thinking about the story yet. You just want to get all your thoughts on the subject down.

Sit down and think about what you want to say. What message you want to get across, what do you want people to know or do when you’re done. Write down all the concepts and ideas that come to you as you think about your talk. Don’t edit, try and decide if it’s good, or organize your ideas yet. This will come later. I like to use a mind-mapping tool for this. The key is to just dump all your thoughts on the page and be able to organize them later.

Mind Map Brainstorm

My initial brainstorm is always a disorganized mess. I’m just dumping thoughts out in a stream of consciousness. Once I’m done, I decide the purpose of my talk. Am I trying to teach, persuade, or inform, as I’ll need a different level of detail in the presentation for each of these. I think of central themes or topics I wish to cover. To keep your talk from being a disorganized mess, you want to have one Big Purpose and a series of themes that support the Big Purpose.

Having a single Big Purpose helps you keep your talk focused. It prevents you from wandering from subject to subject and losing your audience. Everything you say in your talk should go toward advancing the Big Purpose, and if it doesn’t cut it from the talk entirely.

For my talk on Public speaking, the Big Purpose is “Make you a better speaker” and the supporting themes match the subjects of each of these blog posts: why you should be speaking, session submission, where to speak, writing your talk, and so forth. The items from my brainstorm are then organized under each of those topics. Items that don’t fit a topic go in an “everything else” topic. Those might get refined to better fit a topic, they might become the basis for a new topic, or they might just get left out of the talk.

Now it’s time to go through all your topics and see if you find more information that you’d like to cover for that topic. You have the bones of the skeleton, start making sure they’re all fleshed out.

Organized Topic Mind Map

You’re planning on making your talk into a story, right? Now’s when you can start mapping that out. Making a storyboard or a roadmap that shows one topic leading to the next can help you visualize this and organize it better.

Story Map

Once I’ve mapped out the story and decided on the beginning, middle, and end, It’s time to start writing the content. My mind-map gets converted into an outline (most mind mapping packages will do this for you) and I’ll start filling in the outline. Writing shot blocks of text - not enough to make a paragraph, but enough that if I read one of the independently a year later, I’ll know what I meant by it. I’ll usually write it just how I wrote it out here: starting, stopping, skipping around as I come up dry on one line of thought, and picking up on another.

It’s a lot like writing anything else. Create your major themes, hang supporting bits off those. If you spend too much time on one theme, either prune it back or consider if you have two themes. Incidentally, the “Tell a Story” theme was originally part of “Writing your talk” one, but it grew so large, it became it’s own.

If you want, you could start writing in PowerPoint now. Don’t worry about the design or how much you have one one slide. These slides are going to get stripped back later anyway. But by putting things in PowerPoint now, you can start seeing how your talk will break up and flow. It becomes easy to re-arrange the order of your content to find the most logical format. Basically, you’re treating PowerPoint as a big outlining package.

Now read it, critically. You are your own editor. Are you making the same point twice where doing it once would do? Do all your points tie to the central Big Purpose? Are you rambling or providing irrelevant details? Keep asking yourself, “what’s in it for me?” from the standpoint of your audience, and if you find things that don’t answer that question, change or remove them.

If you’re trying to inform, are you getting too detailed and turning it into a training class? If you’re trying to train, are you glossing over important parts? If you’re trying to persuade, do you have any arguments with weak or no supporting statements?

Once you’ve got it all down, rehearse it out loud. This isn’t your finished content, and certainly not your finished slides, but reading them out loud like you’re giving the talk will point out places where your talk doesn’t flow well. Think of each slide in terms of prerequisites: what does the audience need to know before they’ll understand this slide, and have you already given it to them?

Now you know what you’re going to say. Most tech presentations use slides as some supporting material. Next up, I’ll talk about the process of creating those.

This is part of a series on becoming a better public speaker. Read the rest of the series.

Recently Written

Mastery doesn’t come from perfect planning (Dec 21)
In a ceramics class, one group focused on a single perfect dish, while another made many with no quality focus. The result? A lesson in the value of practice over perfection.
The Dark Side of Input Metrics (Nov 27)
Using input metrics in the wrong way can cause unexpected behaviors, stifled creativity, and micromanagement.
Reframe How You Think About Users of your Internal Platform (Nov 13)
Changing from "Customers" to "Partners" will give you a better perspective on internal product development.
Measuring Feature success (Oct 17)
You're building features to solve problems. If you don't know what success looks like, how did you decide on that feature at all?
How I use OKRs (Oct 13)
A description of how I use OKRs to guide a team, written so I can send to future teams.
Build the whole product (Oct 6)
Your code is only part of the product
Input metrics lead to outcomes (Sep 1)
An easy to understand example of using input metrics to track progress toward an outcome.
Lagging Outcomes (Aug 22)
Long-term things often end up off a team's goals because they can't see how to define measurable outcomes for them. Here's how to solve that.

Older...

What I'm Reading

Contact

Adam Kalsey

+1 916 600 2497

Resume

Public Key

© 1999-2024 Adam Kalsey.