Monthly Archives: December 2013

Creating Effective Presentations

I’ve done a few presentations over the years, ranging in time from three minutes (a Demo Day pitch) to an hour (a programmer training session). I’ve found some techniques that seem to work well for me when creating presentations that capture and keep people’s attention:

1. Be clear about what the end goal of the presentation is. At the end of the presentation, what should the average listener take away? You could be trying to teach the audience a useful practical technique, or you could want them to invest in your company, or you could simply be trying to impress your listeners with how smart you are. Each of these are valid goals, but keeping the overall goal in mind helps in creating a more focused presentation.

2. Write down the key points you want to cover in a text editor before you open your presentation software. Jotting down the skeleton of a presentation is much harder when you have Powerpoint already open. This partly because the mechanics of writing notes are much more cumbersome — click “New Slide”, click the Text tool, click somewhere on the slide to start typing, etc — but also because the abundance of presentation options available distract from your end goal.

3. For each slide, represent the information as visually as possible. For most presentations, the less words on each slide, the better. Many textual descriptions can be replaced with visual flowcharts or diagrams. Some opinions go so far as to recommend never having more than three words per slide, although I consider that a bit extreme.

Note that this is true for presentations that are primarily delivered verbally, not for presentations that are meant to be emailed around. An example of a presentation that’s primarily emailed is a detailed slide deck that for follow-on meetings with investors. For such presentations, the number of readers may be far higher than the number of people present at your presentation, so it makes sense to optimize for the common case with more wordy slides.

4. When practicing, think about the key points you want to cover on each slide. You don’t need to memorize the specific words you’ll be using, but make sure you have (three or fewer) points you want to touch on for each slide. Then you can practice the segue from one point to the next, and have a clear indicator for when you can move on to the next slide.

5. Incorporate humor every few slides. Putting a joke on every slide is overkill in most business situations, but periodically including subject-appropriate cartoons or art can lighten the presentation and re-focus people’s attention by drawing them momentarily out of the topic.

6. End with a summary of key takeaways. This might be obvious, but “tell ’em what you told ’em”. Don’t wait for people to make the connections between the information presented across different slides; explicitly make the connections and tell them what you want them to remember after the talk.

I also find, in general, that the better prepared I am for the talk, the more confident and comfortable I appear right at the start. While most presenters can get into the rhythm of a talk within a few seconds, it takes (for me at least) some effort to appear that way right from the start. I can generally get away with memorizing the first two or three sentences of my presentation — enough to cover the first 15 or so seconds — so that I’m not searching for words at the beginning of the talk. Once that initial ice is broken, it’s a lot easier to think on my feet and use language that comes naturally.


Straddling product and technology in large companies

Many roles at startups are for generalists. Most (good) startups want people who are interested in, and have ideas about, the product as well as the technology. This is partly because the product side of startups is generally immature — a consequence of not having reached product-market fit — and also because smaller teams make it easier for people to voice opinions outside the area for which they were hired.

As companies grow, this fluid movement between product design and implementation slows and becomes more formalized. Larger companies break down product development into product managers, who have responsibility for product spec, and engineers, who control how the product is built. Good product managers don’t try to influence technical decisions, and many engineers are uncomfortable providing opinions on user-facing product features.

For people who move from startups to big companies, it’s hard to find a role that provides the same mix of product design and engineering work that you might do as a founder or early employee at a startup. The roles have simply become too specialized to allow for hiring a single person with impact on both areas.

While some of this specialization is inevitable to allow the company to grow, I think the best teams have a strong product orientation among all team members, whether their job involves programming, QA, or product management. The more the team leadership can do to extract product opinions from everyone on the team, the more invested people will be in the final outcome.

I’ve found the following techniques work well to get even introverted team members to voice opinions about the product:

1. Regular free-form brainstorming sessions about the product. It helps if these are focused on a few product areas, identified in advance, that you are soliciting opinions on.

2. Team-based playthroughs or walkthroughs of the product. Many team members have a hard time seeing the product in its entirety, and are focused on their piece of the whole. It’s useful to get the team together on a regular basis to try out the product. For things like multiplayer games, you can have the team simply play the game together for an hour. For less social applications, one person can demo the product to the rest of the team.

3. Feedback sessions about product roadmap, hopefully before it is committed to outside the team. Providing a coherent vision brings the team together and gives people a shared goal that they can stand behind. It’s even better if the roadmap incorporates suggestions from across the team, for greater shared ownership of the product.