Need someone to lead product or development at your software company? I lead product and engineering teams 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 4 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

Domain expertise in Product Management (Nov 16)
When you're hiring software product managers, hire for product management skills. Looking for domain experts will reduce the pool of people you can hire and might just be worse for your product.
Strategy Means Saying No (Oct 27)
An oft-overlooked aspect of strategy is to define what you are not doing. There are lots of adjacent problems you can attack. Strategy means defining which ones you will ignore.
Understanding vision, strategy, and execution (Oct 24)
Vision is what you're trying to do. Strategy is broad strokes on how you'll get there. Execution is the tasks you complete to complete the strategy.
How to advance your Product Market Fit KPI (Oct 21)
Finding the gaps in your product that will unlock the next round of growth.
Developer Relations as Developer Success (Oct 19)
Outreach, marketing, and developer evangelism are a part of Developer Relations. But the companies that are most successful with developers spend most of their time on something else.
Developer Experience Principle 6: Easy to Maintain (Oct 17)
Keeping your product Easy to Maintain will improve the lives of your team and your customers. It will help keep your docs up to date. Your SDKs and APIs will be released in sync. Your tooling and overall experience will shine.
Developer Experience Principle 5: Easy to Trust (Oct 9)
A developer building part of their business on your product needs to believe that you're going to do the right thing for them and their customers.
Developer Experience Principle 4: Easy to Get Help (Oct 8)
The faster you can unblock a stuck developer, the better their experience will be.

Older...

What I'm Reading

Contact

Adam Kalsey

+1 916 600 2497

Resume

Public Key

© 1999-2020 Adam Kalsey.