How to write an abstract for your conference talk or webinar

Writers Block. Image credit photosteve101 (CC By 2.0)

For better or for worse, I’ve become an abstract-writing machine over the years. Whether it’s from writing my own abstracts for conference CFPs, or ghost-writing webinar abstracts for others, I’ve drafted a lot of abstracts. I’ve settled into a bit of a formula.

No one likes to admit they like formulaic writing, but it means that I can quickly churn out an abstract. When I follow that formula, I know that I’ve covered the key parts. Things can still go wrong, but I haven’t missed an important element. It’s also a check against belaboring a single point in an abstract.

In this article, I’m going to share some examples from abstract’s I’ve worked on with teammates. I’m not saying they are perfect. But striving for perfection in an abstract means you aren’t focused on the right thing.

Before I walk you through this formula, I want to share a bit about my philosophy on the topic. That philosophy is to not get too wrapped around the axel over an abstract. Remember that you’re not going to win a Pulitzer Prize for your abstract, no matter how great it is. It’s an abstract.

Why your talk wasn’t selected (spoiler alert: it probably wasn’t your abstract)

When you are submitting for a competitive conference call for proposals, it can feel like a lot is riding on that abstract. But the reality is you shouldn’t agonize over the abstract. If you’re spending hours on it, you’ve probably spent too much time. In the end, if your talk wasn’t selected, there are many other factors that were in play. Here are some to remember:

• How many other submissions were there for how many spots? The raw odds of being selected may have been very low.
• How many other submissions came from your company? Many conference organizers are mindful to not have a single vendor or company dominate a track. If lots of your colleagues were submitting to the same event, you may have been competing with each other.
• Did your title stand out? Your title is the most valuable real estate when selling your talk to a track organizer and prospective audience.
• Was your submission aligned with the conference or track? As a track co-chair, I’ve seen submissions that are way out-of-whack with the track’s purpose. Sometimes they look like a thoughtless copy-paste job from a generic talk or pitch. Sometimes it seems like the person picked the track that was “close enough” to what they wanted to talk about — but didn’t adjust their talk to be in line with what the track was about. Depending on how many submissions, that kind of “loose interpretation” can cost you.

It’s also unlikely that low webinar attendance is due to the abstract. Again, there are many factors, including title (again), promotion, and channel.

Now let’s get on with that formula.

Open with the pain. And maybe a question.

People are too quick to offer solutions. They don’t take a moment to bask in the pain. But if I’m searching for a solution to my problem, I’m first looking for someone who understands my problem. As a reader or audience member, I need to recognize myself (and my pain) first.

Here’s one where we establish a couple facts, including the pain points:

RabbitMQ is the most popular open-source message broker. It’s a de facto standard for message-based architectures. And yet, despite the abundant documentation and usage, developers and operators can still get tripped up on configuration and usage patterns.

Here’s another opening line that focuses on a specific pain:

Measuring the value of a platform on your organization can be difficult, and communicating it can be even more so.

Sometimes the pain is the uncertainty itself around a topic. When there are questions swirling around, it’s useful to state those question. There also might be question that people aren’t asking, but should. Again, stating the question is a useful way to prompt curiosity within your prospective audience.

Here’s using a question to highlight an inconsistency that demands further exploration:

Serverless computing has become a hot topic in developer communities. The use of ephemeral containers eliminates the need for always-on infrastructure. But the real payoff for serverless is greater code simplicity and developer efficiency. Sounds great! Except the open-source serverless framework space is crowded and complex. Each unique offering approaches functions differently, with varying methods for triggering, scaling, and event formatting. How is that efficient?

Articulate the pain up front. Make it clear that you understand the audience’s problems and questions.

Build interest and credibility with some nuanced facts and a point of view

You’ve made that connection with your prospective audience in the opening paragraph. Now you need to build trust and interest. You don’t want to go into the full detail of your talk. But you also don’t want to distill out so much that you’re left with generic platitudes.

The whole point of your talk or webinar is to leave the audience smarter. The second paragraph of your abstract is a moment to teach something to your audience even before they attend. Give the audience a taste for what kind of expert you are. Share some facts, some observations, or some opinions.

Here’s an example that starts with a simple definition and adds observations:

Continuous integration is the automation of building and testing new code. Development teams that use CI can catch bugs early and often; resulting in code that is always production ready. Compared to manual testing, CI eliminates a lot of toil and improves code quality. At the end of the day, it’s those code defects that slip into production that slow down teams and cause apps to fall over.

Here’s another example that hints at what will be covered, but with specific examples:

There are a lot of misconceptions about cloud portability. The term itself implies moving workloads with no work (not true), suggests completeness in what’s moved (mileage may vary), and ignores the laws of data gravity (at your peril!). Platforms, like Pivotal Cloud Foundry (PCF), can make it much simpler to move workloads between clouds. But PCF fits within a broader set of concerns and decisions that need to be made.

Provide some background in a sentence. Be specific about the challenges or benefits you plan to cover in your talk. Make your point of view clear. Use plain language to describe complex ideas.

Finally, list what the audience will learn

You’ve given readers a small taste of what the knowledge they will tap into. Now, step back and list what they will learn. What are the questions they can expect to have answered in the talk? Three to five bullet short bullet-points keeps it easy to scan.

Using question words helps align your language with what the audience is seeking. It also reminds you of other questions you may want to answer. For example, if you are preparing a talk about how to use a tool, consider also answering when or where the tool should be used. Or why use something. With anything that involves change, don’t forget to think about what to measure and how to measure progress. Thinking through your question words helps you cover your topic comprehensively.

Here is an example with a clear point of view and short list, using question words:

The journey to continuous integration maturity has some requirements. Join Pivotal’s James Ma, product manager for Concourse, and Dormain Drewitz, product marketing to learn about:

• How Test-Driven Development feeds the CI process
• What is different about CI in a cloud-native context
• How to measure progress and success in adopting CI

Here’s one that’s heavy on “how” questions, sometimes combined with “when” questions:

You’ll learn:

• How and when — and when *not* — to cluster RabbitMQ
• How to optimize resource consumption for better performance
• When and how to persist messages
• How to do performance testing

Here’s an example that does not use question words, but has concise outcomes:

Using a stringent methodology, Forrester highlights some of the benefits that Pivotal customers realized in areas such as:

• Operational efficiency
• Increased developer productivity
• Decreased downtime / higher quality software
• Shortened release cycles

You opened with the audience’s pain. Then you shared some details and your point of view. Now you come back to the audience and their goals. The last section should make it clear what they will learn.

Keep your promise

As much as I told you not to overthink and belabor the abstract, it is a commitment. Freedom from trying to perfect what your write is not freedom from responsibility to what you write. The abstract is a promise to the audience about what they will learn. Refer back to it as you develop your presentation to make sure you are keeping with your promises.

If something has changed from the time you published or submitted the abstract, address that directly. You are learning and keeping your content fresh, which is great! Acknowledging that shows respect for your audience and builds your credibility.

Was this helpful? Do you think I left something out? Let me know here or on Twitter.