How to do a successful technical presentation

Update: more on this subject here

I have done my fair share of technical presales calls and proofs of concept. I have a few notes on what I've found to help them be successful.

1. Ditch the acronyms and technobabble
   Also known as know thy audience. If you can learn to bridge the gap to the non-technical crowd, you'll be leagues ahead of your cohorts. I use my wife as a sounding board for technical explanations; if I can explain it to her, I know I've sufficiently simplified things.


2. Get rid of Powerpoint, if possible.
   If not, follow my revised version of Guy Kawasaki's 10/20/30 rule. I suggest no more than 5 slides, 10 minutes to discuss the slides, and 30 point font, minimum. Consider it the 5/10/30 rule. Do Not read from the slides.


3. Ask questions.
   Nobody is opposed to answering legitimate questions. I took a Solution Selling course, and was amused to learn that sales people typically have 18 months of increasing effectiveness in a new position, and then productivity falls off. This is, also, coincidentally, the same point at which most people "learn all there is to know" about a product or service, and stop asking questions.


4. Use the whiteboard to your advantage
   This ties in with the previous point-- use the whiteboard to ask questions. Ask about their environment. Draw it on the whiteboard. Ask leading questions about the potential solution you're looking to provide. Draw the solution into their environment.


5. Use your hands to emphasize points.
   This article points out that using gestures makes a math teacher more effective than their less gesticulating counterparts (from the article):
   

   Susan Goldin-Meadow, a professor of psychology at the University of Chicago, found in a recent study that Chicago schoolchildren learned math best when the gestures of teachers enhanced their words rather than simply repeating them.



6. Don't fall into the perception vs. correctness trap.
   I was once giving a presentation, and the customer asked me if turning on encryption would affect performance. The obvious technically correct answer is that yes, it does impact performance.
   
   So I told him yes, that it had a 20% impact on performance. This was also technically correct.
   
   And the wrong answer.
   
   Why? Because I could have told him (and whiteboarded) that an average transaction takes 2 seconds, to which we add 2/10ths of a second, to which encryption adds 20%. In total, encryption adds .04 seconds to a 2.2 second transaction. And then told him, "basically, no, encryption does not affect performance."


7. Make your demonstration interface with their infrastructure.
   I used to work at WRQ (now Attachmate), and consulted on a product called Verastream. We really started to hit our stride when we honed our ability to interface with a mainframe in an afternoon. We would walk in, exchange pleasantries, talk about the potential solution, and have a web or web services interface to the mainframe up in hours.
   
   Customers were always amazed that we could make it work so quickly, and the real power was in the idea that it wasn't just a canned demonstration, it really was their mainframe.
   
   My current employer (MessageGate) is announcing an update to our current IIS adapter which will be much easier to plug into a test Exchange server and demonstrate our email governance capabilities. I'm excited, not because we can't already demonstrate our software, but because it will make demonstrating our software in a live (test) environment that much easier.

In short, it's all about interactivity. One-sided discussions aren't really discussions at all; there's no chance of establishing rapport or coming to a common understanding. Both of these are necessary to move the sales cycle forward.