Lessons Learned Implementing Great Demo! Methodology – Panel Discussion Webinar

Interested in how other organizations have successfully implemented Great the Demo! with their teams?  Our panelists will discuss the challenges they faced and how they overcame them to achieve improved results with their teams’ demos. 

This is a live webinar – we’ll be happy to take questions from the listening audience – and the session will be recorded as well.  The webinar is hosted by Sean Murphy (www.SKMurphy.com) as a part of their Book Club for Business Impact series.

The event took place Tuesday September 4 - we'll be posting a link to the recording shortly.

Great Demo! Public Workshop – More Details

Our next Great Demo! Public Workshop is scheduled to take place October 10-11 in San Jose, California – and the format for the Workshop has a new component. 

Day 1 will focus largely on “core” Great Demo! concepts and will be similar to past Public Great Demo! Workshops.  The second portion of the Workshop, the optional additional ½ day on October 11, will provide time to address more advanced topics, such as:

-      Improving Discovery and Qualification:  Many demos fail due to a lack of customer information – we’ll introduce methods to uncover and organize the key information needed to prepare effective demonstrations.

-      Remote Demos (e.g., via WebEx, GoToMeeting and similar tools):  a topic of high interest – we share how to increase interactivity and improve success. 

-      Introducing New Categories and “Crossing the Chasm”:  “Wow – I had no idea this was possible…!”  How to engage audiences with products and solutions that have never been seen before. 

-      Making Demos Remarkable:  We explore, develop and document practices that help your demos stand out, positively.

-      Storytelling:  Strong stories improve demos and help customers better remember key messages.  We explore how to capture, create and deliver compelling stories for your customer demos.

-      White-boarding:  PowerPoint can be pedantic – we explore white-boarding and other “non-linear” presentation techniques to engage and refresh audiences and improve their retention of key points.

-      Out-flanking Competition:  Methods to anticipate, manage and overcome competitors in demo and related interactions.  How to bias qualification towards your capabilities and block competition.

-      POC’s, POV’s and Sandboxes Tools and Strategies:  The essence is Quid pro quo – how to manage the process overall to get the business; when to do and when not to do POC’s and Sandboxes; strategies to increase your success rates.

-      RFP’s and Scripted Demos:  Successful strategies and tactics to increase your success rates with scripted demos and RFP responses, including when to pursue, when to pull back, and how to gently subvert the process in your favor.

-      Managing Questions:  How to avoid getting dragged off-topic and how to deal with hostiles elegantly and effectively.  

-      Team Tactics:  Team-oriented methods and practices for presales, sales and marketing staff in preparing and delivering demos.  Roles and guidelines are developed and practiced for the selling teams to improve results – when demos are delivered face-to-face as well as via a remote connection.

-      Trade-show demonstration techniques and interactions:  Trade-shows are phenomenally expensive – we’ll work through clever methods, tips, and best practices to help you get the best return on your investment.

-      New Product Roll-outs:  Vision Generation at its most challenging – we’ll help you create your go-to-market messaging and demos for new products, and shortening the time to getting your first real reference customer!

-      Reference Selling and Informal Success Stories:  These are the lifeblood of a software sales and marketing organization!  We’ll develop the structure and methods to capture this key information and create a set of your own.  The team will be ready to leverage these immediately.

-      Transition Vision:  Differentiating by helping prospects visualize how they can move from their current problem situation to the future state represented by your solution. 

We’ll address many of these (as well as other topics raised by the participants) in accord with participant interest and the time available.  These segments are often some of the most interesting portions of Great Demo! Workshops, enabling participants to apply the methodology to range of real-life situations and challenges.

Registration information and can be found here.

Brain Rules for Meetings

If you aren’t already following John Medina’s Brain Rules Blog, this one entry is particularly useful for those of us who demo:  http://brainrules.blogspot.com/2012_01_01_archive.html

The Fallacy of "So What"

A number of sales methodologies have done a good job at helping sales and presales people move from talking about features to discussing the advantages that specific capabilities offer the customer.  Using the phrase, “So What?” is an example tactic that helps push vendor representatives to talk about advantages as opposed to features.  This is good, but we can do better…

During demos, there is inherent risk anytime you introduce capabilities that the customer has not yet requested – and, in particular, the level of risk depends greatly on how the capabilities are introduced.  The “So What” tactic presumes that the customer will want or need the capability being introduced – and there’s the risk. 

An Example:

Feature Statement:  “We provide support for the software in 22 languages…”

So What Statement:  “We provide support for the software in 22 languages, so that your team can access the software anywhere in the world using their native languages…”

The Risk:  The customer says, “Everyone in our company speaks English and we want to make sure that all information is captured consistently in the system, so that everyone can access all information equally – without having to learn 21 other languages…” 

The Additional Risk:  The customer adds, “…and we don’t want to pay for the additional 21 languages, since we won’t be using them – so either take out the support for those languages for our implementation or reduce your price accordingly…”

Another Example:

Feature Statement:  “Alerts can be automatically generated and sent to you via email…”

So What Statement:  “Alerts can be automatically generated and sent to you via email, so that can be notified of any problems right away…”

The Risk:  The customer says, “I hate email.  I get way too much already and I’m always spending too much time deleting messages – I’d be concerned that I’d delete the alerts, thinking they might be spam.  I’d rather simply login to your system periodically…” 

The Additional Risk:  The customer adds, “…and I don’t want to pay for the email alert functionality, since I won’t be using it – so either take it out or give me a discount…”

Same Example, Even Worse:

Feature Statement and Demo:  “Alerts can be automatically generated and sent to you via email – here, let me show you how this can be done in the software…”

So What Statement and Demo:  “Alerts can be automatically generated and sent to you via email, so that you can be notified of any problems right away – here, let me show you how this can be set up and done with the software…”

The Risk:  The customer says, “I hate email.  I get way too much already and I’m always spending too much time deleting messages – I’d be concerned that I’d delete the alerts, thinking they might be spam.  I’d rather simply login to your system periodically…” 

The Additional Risk:  The customer adds, “In addition, that looks really complicated and confusing – too many features and functions to remember.  I think we’ll go with your competition, whose software was much more aligned with exactly what we need…!”

Solutions

The best solution?  Introduce your capabilities via questions in Discovery, well before a demo.  Once you’ve either uncovered a need (and the customer confirms their desire to have the capability), then presenting that specific capability in your demo can be done as a benefit statement.

Michael Bosworth, in his sales methodologies Solution Selling and CustomerCentric Selling, outlined the idea of Feature, Advantage, Benefit statements – simplified here:

Features:  are the description of the what the feature does

Advantages:  are why it might be good for the customer

Benefits:  are why it will be good for the customer, based on the customer’s previous statements (e.g., from Discovery sessions)

This difference between an Advantage (presumed benefit) and a real Benefit (confirmed benefit) can be huge!

Revisiting Example 1

With this in mind, we might have a different conversation and result:

Feature Statement:  “We provide support for the software in 22 languages…”

Advantage (So What) Statement:  “We provide support for the software in 22 languages, so that your team can access the software anywhere in the world using their native languages…”

Benefit Statement:  “You had mentioned that you need support for 5 languages so that your team can access the software anywhere in the world using their local native languages – we do support all five of those languages as part of our standard offering.”

The win:  The customer says, “That’s terrific – that’s exactly what we need.  Interestingly, one of your competitors said they support a pile of languages, but we didn’t want to pay for all of those extra capabilities since we’ll never use them…” 

An alternative approach, based on what were benefits for other similar customers, is called a Biased Question – see my article, “Competitive Demo Situations – Biasing Towards Your Strengths” for further information on this idea (send me an email at PCohan@SecondDerivative.com and I’d be happy to send you the article).

[Warning – Shameless Self-Promotion] Great Demo! Public Workshop October 10-11

Our next Public Great Demo! Workshop is scheduled for October 10-11 in San Jose, California – registration and additional information can be found here. 

This can be taken either as a 1-Day or 1.5-Day Workshop.  The first day will focus on core Great Demo! material, with the optional morning of the second day addressing more advanced topics and techniques.

Public Workshops take place in San Jose, California, in conjunction with the folks at SKMurphy.  This is an excellent opportunity for individuals, small groups or for teams that have new hires.

We’ve found that these events are most productive when there are two or more participants from each organization (singletons are also fine). This helps to mimic real-life interactions as much as possible, both when preparing demos and delivering them in the role-play sessions.

Wonderful “Doctor” Situation Slide Labels

At a recent Great Demo! Workshop, one of the participant teams did a wonderful (and clever!) job of re-labeling Situation Slides:

CBI became Symptoms

Problems/Reasons become Diagnosis

Specific Capabilities became Proposed Cure

Nice!

Stunningly Awful Web Overview Demos - Comment

A number of people reading the (previous) post have commented along the following lines:

“I do start the web meeting at least 10 minutes early and send the customer a test link and ask them to join early, but in spite of that many customers are still late and so we lose 15 -20 minutes of the slated time.  This also happens when meetings are face-to-face.  Got any tips for encouraging customers to start on time?”

I often see the same problem – that it is the customer who is late.  Unfortunately, this is an endemic issue, due (typically) either to company culture (“we always start meetings late”) and/or disrespect for vendors). 

Three suggestions for solutions:

1.       There is nothing sacred about “1 hour”.  I often schedule meetings (phone, web, face-to-face) that are what others might consider of “non-standard” duration:  45 minutes long; 75 minutes long; etc.  If people arrive on time and you finish early, then you give everyone a few minutes back in their day.  If people are 10-15 minutes late (and you planned on 60 minutes for the “actual” meeting), then it all works.

One small risk with this (and it does happen), is that some people may still not respect the non-standard time-frame and schedule another meeting that cuts into yours.  Not much you can do about this, however, other than to…

2.       Organize your content using the inverted pyramid approach (like a news article) so that you cover the most important topics up-front.  If you do run out of time, at least you’ve gone through the most important material.  Which leads to number 3:

3.       If you know you are going to run out of time, and there is still important material to cover, a few minutes before the planned end of the meeting you can ask:

a.       “Looks like we may run out of time, based on our original plan for 1 hour, shall we go ahead and continue for another 20 minutes now, if we are all available?”  or

b.      “Looks like we may run out of time, based on our original plan for 1 hour, shall we schedule a follow-up meeting later this week when we are all available?” 

Hope these suggestions help…!