90 Seconds of Presales Panic – H is for Hazard!

90 Seconds of Presales Panic – H is for Hazard!

You know it’s a hazard.  All of your training and intuition scream “Don’t do it!”  But…

I was working in Guilford, England.  My power adapters were working fine converting the UK 220v to US 110v, but I needed to plug in one more charger in addition to powering my PC.  I had this 4 outlet power strip with surge protector so I put the 220v adapter on it and plug it into the wall.  Instantaneously, it arced and emitted a loud pop with the sound of broken glass.  Circuit breakers tripped and half the office room went dark.  My panic was evident and there were moans everywhere!  I was a hazard!

The thesis of this Presales article is not about being a hazard, but avoiding hazards during the demo.  Such as navigating to a not quite ready feature only to find an inappropriate developer comment like “This is really stupid”!   Your intentions are positive.  You throw caution to the wind and of course – answer the prospect’s question, but do you really need to show the power of the software and display your command of the topic?

Yet, as in so many cases, no good deed goes unpunished.  With a well-intentioned desire to be responsive to the prospect, you begin hunting and pecking around the software for something not practiced.  Mumbling phrases such as “Um, I think it’s in this menu,” and “I guess it’s not there, maybe it’s here”.  You point and click aimlessly around the software.  Then, the screen locks up, or a message pops up: function not available.

While a hazard in the context of a software demo doesn’t hold the danger of an actual mine field, it can nonetheless pose the threat of derailing the demo itself.  Tripping over a hazard will make your solution look more complicated, move the meeting onto the wrong track, or possibly even threaten the entire opportunity.  In the context of a software demo, hazards can include:

A request to demonstrate an unknown, unfamiliar or un-practiced aspect of the software
Trying to demo early release or beta level software that is not fully tested (but this could win the deal!)
Unchanneled questions around unrelated or peripheral topics that can cause confusion or disinterest

So, as the movie line goes: “Do you feel lucky?  Do ya punk?” one needs to evaluate request against one’s skill, experience and situation.  Reasonable prospects don’t expect any single person to retain expert-level knowledge of all areas within an enterprise class solution.  As such, there isn’t a need to try to become a hero.  Don’t let demo hazards derail the meeting and ruin your credibility.  Instead, use them as an opportunity to build a deeper relationship of trust with the prospect and explore additional sales opportunities.

And don’t avoid the obvious hazards!  If your demo relies specific project resolutions, bring your own projector and don’t rely on your prospect.  If you are network dependent, what’s the plan if the network resource goes down?

To mitigate pure technology hazards, two key elements are preparation and having a backup plan.  1) Know and confirm your venue, demo technology and practice setup beforehand.  2) Always, always have backup options such as screenshots or a whiteboard presentation ready to go.

Consider these best practices

  • Expect demo hazards and prepare how to handle them ahead of time.
  • As the stakes of the meeting grow, rely less on chance to succeed.
  • Test yourself for being over-confident about the situation

Have other demo hazard avoidance techniques?  Let’s connect and continue the discussion.  I look forward to the dialog.

Like to read more?  Check out more articles about Presales best practices & techniques at https://www.desylvia.com and our book at https://3dpresales.com.

#Presales, #3DPresales

Published by Bob Skowron

Bob Skowron has practiced the art and science of Presales for 15+ years with over 10 years in Presales management. Before becoming a Presales professional, Bob combined business and technology skills sets by implementing IBM mid-range solutions as a financial controller. His business and marketing background were complemented with software engineering and management information system positions. From being a self-taught coder, he became an educational consultant, a project manager and sold implementation services. It was at this time in the mid1990s when Bob met and began working with co-author Dwayne DeSylvia. Bob crossed over from post-sales projects to Presales roles when working at Baan, a large global ERP solution provider. After rising to a Presales executive at Baan, Bob left to join a number of startup companies and brought Presales techniques and success to companies who had newly developed software solutions. Bob worked in the field and demonstrated with success the techniques he was asking his teams to do. An avid skier and outdoor enthusiast, Bob lives in Colorado.

Leave a Reply