The Right Way to Structure a Technical Presentation | Episode 2

Ultimize. Before your next presentation, take your main idea and force yourself to explain it in 15 words or less. Can't do that? Your audience doesn't stand a chance. Because if your ideas require 5 minutes to explain before it makes sense, most people will stop listening before you get there. Engineers are trained to explain. You explain how things work. You explain why decisions were made. You explain the data, the assumptions, the edge cases, and the dependencies. That's your job. But when you present, that instinct becomes your biggest liability because the more you explain, the harder it becomes for your audience to understand. This feels backwards. It feels like if I explain more clearly, give more data, people will understand better. But in practice, the opposite is usually true. More explanation, more detail creates more cognitive load. More cognitive load creates confusion, and confusion shuts people down. Your audience is not processing your presentation like a machine. They're not reading it and rereading it like it's a document they're going to be tested on. They're filtering, simplifying, and trying to keep up in real time. And if you overwhelm that process, they don't get smarter, they disengage. This is why so many engineering presentations fail. Not because they're wrong, but because they're overloaded. Too many points, too many layers, too much context before anything meaningful happens. So here's the shift. Your job is not to explain everything in every little detail. Your job is to make one idea clear at a time. One. Not 10 or 20. One. If your audience remembers one clear idea, you've succeeded. If they remember nothing because you tried to say everything, you failed. This is the simplicity rule. And like any engineering principle, it needs to be applied and tested. Let's break it down. Start with your core messages. What is the one thing you want your audience to truly understand or do? If you can't answer that immediately, you don't have a presentation. You have information. And information is not the same as communication. Once you have that one idea, everything else becomes a decision. Does this point support the main idea? If yes, keep it. If no, remove it. That includes background information, extra data, interesting side points, technical depth that isn't required. This is where most engineers struggle because everything feels important, everything feels relevant, everything feels like it should be included. But your audience doesn't experience your presentation the way you do. You've lived with the material, they're seeing it for the first time. And the more you include, the harder it is for them to identify what actually matters. So you have to design for their experience, not your knowledge. Remember, the presentation is for your audience. It's not for you. Now let's connect this to testing and evidence. How do you know if your presentation is simple enough? You don't guess, you test. After your presentation, ask someone, "What was the main idea?" Not, "What did you think?" Not, "Did you like it?" "Do you like me?" Ask, "What was the main idea you remember from this presentation?" If they can't answer clearly and quickly, your presentation wasn't simple enough, it wasn't clear enough, it didn't work. That's your data. And it's incredibly valuable because it tells you exactly what your system produced, not what you intended, not what you hoped, but what actually happened. And when you collect that data over time, patterns emerge. You'll notice that when you reduce the number of points, Clarity increases. The rule of thumb I have is focus on a handful, 5 points at most, and make sure they're remembered rather than doing what most engineers do, which is 75, 85 points. One main idea and 5 points in any presentation. If you can do that, you're going to give the best engineering presentation anyone has seen in a long time. You'll notice that when you lead with the main idea instead of building up to it, people understand faster. You'll notice that when you cut information, your impact goes up, not down. That's the counterintuitive part. Less information often creates more understanding because it allows your audience to focus. Now let's address a common concern. Engineers often worry that simplifying means being inaccurate. No, It doesn't, it means being selective. You're not removing truth, you are prioritizing relevance. You can always provide more detail if needed. But here's the real choice every engineer faces in any speech. Do you focus on one point and then give examples and stories to bring that idea come alive? Or do you just go on and on and on with another fact, another fact, another fact? Successful engineers who present well spend time giving example after example after case study after case study. But if you start with too much information, you lose the audience before they even understand the basics. Think of it this way. In engineering, you don't start with the most complex version of a system. You start with a model, a simplified version that captures what matters. Then you add complexity as needed. Your presentation should work the same way. Start simple. Add detail only if it serves the objective, not because it exists. Now let's talk about structure. Most engineers structure presentations like this: here's the background, here's all the data, here's all the analysis, here's the conclusion. That's logical from an engineering standpoint, but it's inefficient for communication, especially spoken communication because your audience has to wait to understand why any of it matters. A better structure is conclusion, key support, stories to make that support come alive, details. Start with the answer, then explain just enough to support it. Flush it out. Let people visualize what you're talking about, then stop. That alone will dramatically improve clarity. Again, you don't have to take this on faith, you can test it. Try two versions of the same presentation. Only when you lead with background, only when you lead with the main idea. Try both, then measure. Which one did people understand faster? Which one did they remember? Which one led to action? I'll give you a clue. It's going to be the one where you focus on just a few ideas and you illustrate each one with an example, a case study, a story of how you turned this issue into a real-life solution for a real client, a real colleague, a real prospect. That's how you improve your presentations. Not by guessing, by testing, by observing, by refining. This is what separates average communicators from effective ones. Average communicators assume, Effective communicators measure. And once you adapt that mindset, everything changes. You stop trying to say more and more and more. You stop data dumping. You start trying to make one thing at a time clear. You stop adding more slides. You start removing them. You stop thinking about what you want to say. You start thinking about what your audience needs to understand. That's the simplicity rule. And it will transform your presentations faster than almost anything. In the next episode, we're going to build on this and show you how to structure your presentation so your audience can follow you easily from beginning to end without getting lost. 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 dot 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.