Email, the miscommunication optimizer.

There is a good article about the potential for miscommunication in email over at The New York Times (registration required, don't you have BugMeNot yet?).

It puts a bit of a new spin on an old dilemma-- the fact that emotional content is difficult to properly convey in email. This should be obvious to any long term email user-- you've likely had your email grossly misinterpreted. The interesting bit is that they are bringing "social neuroscience" into the equation, and actually analyzing the brain patterns of people interacting.

The rule of thumb I have used for years:

An in-person conversation has 100% communication bandwidth (body language, tone, words).

An on-phone conversation has 50% communication bandwidth (tone, words).

An email conversation has 20% communication bandwidth (words). Read more...

The Proof of Concept

Continuing in the theme of pre-sales presentations, I thought I'd spend some time discussing the Proof of Concept (POC). The Proof of Concept is essentially required to bring enterprise sales to closure, but they can be risky.

Here are some pointers on doing a successful POC.

First and foremost, understand that the success or failure of a proof of concept hinges on two things:

• Technical aptitude and sales ability (skills)
• Control of Scope (management/risk mitigation)

The area that you can influence the most (aside from keeping your chops current) is risk mitigation. The method to do this is to control scope. You want to do the minimum proof necessary to demonstrate capabilities.

"Well, could you make it do..." is the most dangerous question ever during the middle of a POC.

Some of the questions you need to ask before the POC starts:

• What is it that we're trying to prove?
  

  You should have an elevator speech ready, and should repeat it often. This is what we're trying to prove, and this is what we have proven. This should be something definitive or measurable: "We're proving that we can do X transactions per unit time with this test corpus" or "We're proving that we can web-enable this business transaction"

• What are the standards of success?
• What are the next steps upon success?
  

  This is a "give to get" proposition: if we can prove the solution works, what is the next step in the sales process.

Some additional tips:

• Be visual.

  While at WRQ (Attachmate), I did numerous Proofs of Concept with their integration tool, Verastream. In every case, I highlighted the "behind the scenes" workings by showing the actual mainframe transactions-- this never fails to communicate that the demonstration is real, and integrated.

• Teach.

  If you can educate your customer about the product or service you're trying to sell, you just won a leg up. Customers buy solutions they understand and can approach.

Read more...

More on Technical Presenting

This is a follow-on to a previous post.

If you're doing a Technical Presentation, here are the most important things that you can establish or give to your audience.

• Education: the audience is there to be taught about your subject
• Communication: interactivity is the key to moving beyond the brochure into the "I can use this" moment
• Understanding: How can your audience actually make use of your subject matter?

There is a maxim that I use, "You can't tell anyone anything." By way of definition, think about attempting to "tell" your kids what to do, e.g.: don't play in that mud. What will the child do?

Reminds me of the Bill Cosby Children are Brain Damaged skit, but that's a discussion for another day.

So, to communicate, it is necessary to remain factual, and when you want to convey subjective points, you need to be more subtle. Consider the story of Eve and the serpent:

Gen 3:1 (KJV) Now the serpent was more subtil(emphasis mine) than any beast of the field which the LORD God had made. And he said unto the woman, Yea, hath God said, Ye shall not eat of every tree of the garden?

Now of course, we know that the serpent was trying to deceive, but let's separate that from the fact that he was being subtle. Subtle is asking questions.

By asking questions, you can establish the baseline from which you are working-- where is your audience at?

By asking questions, you can lead the audience to understanding.

By asking questions, you can establish value.
Read more...

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.
Read more...