Let's Talk About Why, Not Just How

Have you ever sat through a presentation where it felt like the presenter put the documentation of a tool on the slides? Not really the most thrilling way to spend an hour.

Have you ever given a presentation where you had the feeling people didn’t really listen that well and started to drift away from the presentation? I have been in those presentations and I’ve definitely given them.

We are surrounded all day by interesting technology. We love building, reading and talking about the latest and greatest we just started using. When we present this though we often think more about what we want to say, but not necessarily what our audience wants to listen to.

Talking about how a specific technology works and all it’s intricacies can be very interesting, but if it isn’t anchored in a broader problem that people can feel and understand it can get boring quickly.

The same applies to blogposts as well of course, it’s just easier to stop reading them.

Listening to hundreds of startup pitches and pitching Codeship myself at every chance made it clear that without that emotional connection people lose interest quickly.

Emotional Connection

When presenting your product, startup or technology getting your audience to care needs to be the first and most important step. They need to feel the pain before you show them the solution.

For example when we were talking to Investors about Codeship we always talked to them about the teams they invested in. We asked them if they felt that those teams could be more productive in their development and how a faster development and deployment cycle would benefit these teams. This put the whole product into their personal perspective before we could go on to explain the market and other business metrics.

The best tech presentations I’ve seen always showed the problem and the reason behind their choices and technology before going into details. This way I was already intrigued because I could relate and see the pain point. It’s not a generic “Technology x solves theoretical problem y by doing z”, but a proper story.

Details aren’t everything

An empty slide makes it way too easy to overload it. You have so much space and of course you want to use it. A little more text here, another few api methods there and you end up with something that few people can remember.

After the third presentation on a given night only the most important facts will stick. By overloading your presentation with details you dilute your main message and people won’t remember at all.

A good story with a real life problem and the necessary information will stick. Short, concise and done in a way that supports the presentation, not later rereads of the slides.

A presentation that takes 30-60 minutes with dozens of people that listen is a lot of lost time if the presentation doesn’t provide a lot of value.

Over the last years I’ve found a process that works really well for creating my presentations and blog posts.

Our Process

At Codeship we put a lot of time and effort into writing interesting articles at our blog. In the beginning I didn’t really have a proper process, but just started writing until there was a bunch of text. The posts didn’t have the focus they should have had.

A more structured process feels a little slow in the beginning, but as with proper code reviews and other processes it saves time in the long run.

Of course everybody has their own process, so let me know in the comments what yours is.

Paper never dies

I typically start with collecting everything I want to say in a paper moleskine. There is no order or level of importance, just a bunch of thoughts that need to be covered. Later on you can check with every step if all the necessary thoughts are covered.

Headlines, headlines, headlines

After those thoughts are collected and I have a better picture of what I want to say in this post, I’ll start with the outline and select a few headlines that fit for different sections. It’s easy to check those headlines against the previous collected thoughts.

Write a bad version

The next step is always to either write a grammatically nonsensical version of the blogpost or draw dummy slides on paper which roughly show the full content. If the sentences are written with deliberately bad grammar you really can’t use this text at all, but it supports you once you write the full text. Again it’s important to get all of the thoughts you want to express covered, not necessarily to finish them right away.

Ask your peers

Every single one of these steps can be feedbacked by other team members or you can even go over it yourself to see structural problems. When you are sure that this is the content you want to present you start writing the proper text.

This workflow has helped me tremendously over the last months when writing my blogposts. Although it looks like it needs quite a bit of work in reality it’s faster and yields better content. Give it a try and let me know how you are doing with it.

Conclusions

Our interest in technology, which can be more than a job but a great passion, often leads us to assume that everybody can follow all of our presentations and blog posts. But to properly present a technology, product or basically anything, people need to understand why they are listening. They need to have that emotional connection.

By showing them the pain they currently have or which you had in the past and solved, you can engage them and make them listen.

We all strive for more efficiency, so why not start by efficiently using our audience’s time and giving them something to remember. I’m sure all of us would appreciate that.

Ship long and prosper!