TJ Walker says engineers should start presentations with the conclusion, not build to it. Use no more than five supporting points with concrete examples, then add detail only if it serves that conclusion. Test your structure by asking audiences what they remember.
Chapters
Ultimize. Before your next presentation, do this: write your conclusion first. Not your background, not your data, write the conclusion. Not write out all your PowerPoint slides and bullets, but your conclusion. Because if you don't know exactly what your conclusion is, your audience will never find it. Most engineers structure presentations the same way they structure their thinking. They start with background, then they move to data, then some analysis, and finally If there's time, they get to the conclusion. That structure makes perfect sense for solving problems. It's a terrible structure for explaining them because your audience is forced to wait. They don't know where you're going. They don't know what matters. They don't know how to interpret anything they're hearing. So they start guessing. And once your audience starts guessing, you've lost control of the communication. This is the core issue with most technical presentations. They're logically correct but poorly structured for understanding. So we're going to fix that, and we're going to do it using an engineering mindset. In engineering, you don't build systems randomly. You design them to produce a specific output. Your presentation is no different. The output is not, I walked them through all the details, I dumped all the data, I went through the slides. The output is the audience understood and accepted my main idea and sometimes took the actions I wanted. So your structure has to serve that output. Here's the structure you should use. Start with your conclusion. Tell your audience the main idea immediately, preferably in an interesting, engaging way. Not after 10 slides, not after 5 minutes, immediately. For example, we should move forward with option B because it reduces cost and risk. That's your starting point. Now your audience knows what matters. They have a framework. They know what they're evaluating. Then you move to your key supporting points. Remember, not 15, 20, 30 points, but no more than 5 points. Not everything, just the 2, 3, 4, 5 reasons that make your conclusion valid. For example, cost reduction, risk mitigation, implementation speed. Those are all abstractions, You've got to spell those out in detail, give examples, flesh them out, tell stories about each one. If you can do that, you're in great shape, much better than just randomly listing abstractions and trying to cover as much ground as possible. Each point should directly support your conclusion. If it doesn't, it doesn't belong. Then and only then you add additional detail if it's needed. Remember, It's not detail in terms of more facts and numbers. It's detail in terms of examples, case studies, real-world experiences. It's not because you have to have it. It's not because these stories, examples exist, but you're giving it because it helps your audience make a decision because it makes it easier for them to remember your key points. This is a fundamental shift. You're no longer walking your audience through your thinking. You're guiding them to a clear outcome. Now, let's connect this to testing and evidence. How do you know if your structure works? Again, you don't guess, you test. After your presentation or your rehearsal of your presentation, which I hope you do, ask, "What was the conclusion? What did you really take away?" If your audience can't answer that clearly, Your structure failed. Not partially failed, it failed. Because the conclusion is the most important part. And if that didn't land, nothing else matters. You can also observe behavior during the presentation. Do people look confused early? Do they ask questions that suggest they don't understand where you're going? Do they lose attention before you reach your key point? By the way, if you're not aware of those things, that probably means you're staring at your PowerPoint deck and not even looking at your audience. You need to look at your audience for signals. Those are signals they're giving you. That is data, and that data tells you that your structure is not working sometimes. Now let's address a common objection. Engineers often say, if I give the conclusion first, people won't understand how I got there. That's not really true. People don't need to understand everything before they hear the conclusion. They need the conclusion to understand everything else. It gives context, it gives meaning, it helps them process the information that follows. Without it, they're just trying to keep up. With it, they can evaluate. That's a much better experience for your audience. Now let's talk about something else that happens when you change your structure. Your presentations get shorter. But keep in mind, being short's not the goal. The goal is to communicate and have them remember your messages. But But yes, it is better to really communicate well in 20 minutes than to go on and on and on for an hour. Once you focus on the conclusion and the key supporting points, a lot of material simply becomes unnecessary. And that's a good thing. Shorter presentations are easier to follow, easier to remember, more likely to lead to action, as long as you fill those presentations with examples and stories and case studies. Again, this is something you can test. Try presenting the same idea two ways: one with your old structure, one with the conclusion first, structure then measure. Which one did people understand faster? Which one do they remember? Which one led to a decision? That's how you improve. Not by assuming, by comparing results, by using evidence. Now let's take this one step further. Think of your presentation as a system with 3 parts: the input, your message; the process, your structure; output, audience understanding and action. If the output is not what you want, you don't blame the input, you improve the process. And structure is one of the most powerful parts of that process. When you get it right, everything becomes easier. Your audience follows you. Your points land, your messages stick, your stories are remembered. When you get it wrong, everything becomes harder, even if your content is excellent. So from now on, start with the conclusion, support it with a few key points, add detail only if it serves the objective. But just because I say don't put in lots of detail doesn't mean you have to rush. You have time. To tell relevant stories. You have time to give examples. You have time to give case studies if it supports your key points. Then test the result. That is how you design a presentation that works. In the next episode, we're going to focus on one of the biggest sources of confusion in engineering presentations, slides, and how most engineers use them in a way that actually makes their presentations worse. You know, there's one thing I always find interesting. People will listen to a podcast like this, get ideas, maybe even feel a little motivated, and then just move on with their day. Nothing actually changes. And I get it. Information alone doesn't do it. Repetition does. That's actually why we built Ultimize. So if you're getting any value from this, just go to ultimize.com. That's spelled U-L-T-A-M-I-Z-E.com. There's a free course waiting for you there. You can start with communication skills, but the whole idea is simple. Don't just hear something once, actually build it into your life. Again, it's free. Go to ultimize.com.
