Engineers tend to put lots of data, charts, and bullet points into their presentations. This is OK when they’re talking to their peers, but will cause Death by PowerPoint if they’re presenting to persuade.
A meeting with the CTO
I have a dear friend, let’s call him Sal. Next month, Sal’s giving a presentation to the CTO of his company about a coding platform that’s “a joy to work on” which could make life easier for the software engineers in his company by consolidating activities, automating processes, and reducing production time.
The CTO of Sal’s company is a former software engineer who has an intimate knowledge both of coding and the platform that Sal wants the company to start using. He realizes that this platform could be beneficial, but it’s a sizeable investment so he needs convincing that it’s worth it.
The Engineering approach
Sal’s slides contain lots of text, bullet points, and some SmartArt graphics. They all look very similar, with no photos to break the monotony.
As we were going through his deck, Sal told me more than once that he was “gonna blow by this slide.” He also explained how well the CTO understood the subject he was presenting on and that the deep dive into how it worked was just to establish the need for the new platform.
Overall, the presentation was data-heavy and lacked a compelling story. This is a problem when you’re trying to generate an emotional response (“Oh my gosh, this platform is so great!”) and change behavior (“I am definitely going to authorize this purchase.”), especially when the behavior change involves a major pain point (a large, unproven expenditure).
A better approach
This is really a case of knowing your audience. The CTO already understands the problems with the way coding gets done in the company and he’s familiar with the software platform that could solve them. So Sal’s presentation should be less about deep dives into coding and definitions and more about what someone in the C-suite would be concerned with, things like time to adopt, scalability, and ease of use.
Describing the Ideal Future
The answer is to contrast the way things are now with how great things will be in the Ideal Future when the new software platform is adopted. This is a classic speech approach that works to build momentum for the call to action at the end. Here’s the process:
- Describe the way things are. Begin by speaking in broad terms about the problems the company faces with software development.
- Talk about how things could be. Introduce the idea that there’s a better way of doing things and that the solution is available.
- The “where we are/where we could be” cycle. This is where Sal goes into detail, first addressing a specific challenge then describing how each one gets solved with the proposed solution. Going back and forth between where we are (problem)/where we could be (solution), Sal builds momentum for the next part of the presentation.
- Demonstrate. Now that Sal has the CTO’s attention and has established how great things could be with the new software platform, it’s time to show the software in action. Demonstrations are more persuasive and memorable than descriptions.
- Call to action. After the demonstration, Sal reminds the CTO about the way things are and the Ideal Future that results when the software platform is used. He then asks the CTO to take specific action, such as entering a software trial or purchasing a license. The more specific the call to action, the easier it is for the CTO to know what to do with the information he’s just received.
So, throw the data out, right?
Wrong! Sal will need to have some solid data to back up his claims. And if the CTO wants to see them, they need to be available, both as clear slides and as a handout he can refer to later. For the handouts, Sal can take his deep dive into data, but only those data that support his proposed solution, not everything there is to know about coding. And it’s important that he include his sources so that the CTO can do his due diligence before making any decisions.
Selling the solution
When Sal presents to the CTO next month, he needs to convey earnestness, enthusiasm, and positivity for his solution. The message is “we both want the same thing” and “this new software platform will help all of us.” By shifting the focus off of the software engineers’ day-to-day workload and onto what can benefit the company as a whole—the Ideal Future—Sal stands more of a chance of closing the deal.