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…!

Stunningly Awful Web “Overview” Demos – The Gruesome Anatomy of a 1-Hour Web Overview

[Warning – graphic and potentially painful content…]

1-Hour Web “Overview” Demo Timeline

There’s a rough but strangely consistent timeline for a web-delivered “1 hour overview demo” that seems to go like this [starting time for each element on the left side]:

00:00:  Fumbling with WebEx/GoToMeeting/Live Meeting – “Did you get the link?  Can you see my screen?” (This consumption of time has been delightfully called the “WebEx/GoToMeeting/Live Meeting Tax”).

00:04:  Semi-mutual introductions, but generally one-sided:  introductions (and brief personal history of each of the vendor participants), but limited information requested or offered regarding customer participants – and no request to do discovery on the part of the vendor

00:08:  Corporate overview presentation (gag…)

00:18:  Product overview presentation (yawn), including

1.      Obligatory architecture slide(s), with equally obligatory rectangles and cylinders representing software and database components (how novel…)

2.      Obligatory product-centric slide (showing company’s product in the center of a circle of other things (e.g., users, other applications, process steps, you name it – so novel, once again!)

3.      Key “differentiators”, presented without context to the customer’s needs or specific situation (and largely forgotten by the customer, since they haven’t yet seen a solution that makes remembering anything relevant)

4.      Case studies, if any, generally appear at the end and are typically skipped over “because we are short on time…” (too bad – real case studies would be the most interesting part of the overview)

00:28:  “Actual” demo, including

a.      Opening statement that “we need to compress the planned 45 minute demo into 30 minutes “so we’ll have to go real fast…”

b.      Request that “this be interactive, so please stop me if you have any questions…”, followed by a fire-hose-like delivery with no time for meaningful questions

c.       Re-introduction of the offering (again, even though it was covered in the product overview presentation)

d.      Brief introduction of the for plan for a “story” and 3 fictional characters whose “day in the life” will be followed in the demo

e.      Overview of navigation elements…

f.        Introduction and definitions of key vendor jargon, acronyms and product names

g.      Explanation of how to set up and configure the application, which then consumes most of the remaining time (even though this task is typically done once, when first implemented, and then rarely ever after)

h.      A walk-through of the workflow (a run-through, in fact, since time is really getting short)

i.        A rapid, largely verbal description of the canned and custom reporting capabilities (often including the claim that “we have over 600 canned reports…” of which a typical user might consume only 1 or 2…!)

j.        Comment that “we didn’t have enough time to show you everything…”

00:58   Sales person summary, with platitude marketing “value proposition” statements (that have little or limited bearing on the customer’s specific situation)

00:60:  Wrap-up with no action items

Frightening, gruesome and remarkably common!

If the objective was to “show the customer a demo” then that objective was achieved – but it is very doubtful that other tangible progress was made in the sale.  Very sad; and largely a waste of time for all involved.

But Wait – It’s Even Worse…

The pain often starts earlier – and ends later.  Many presales people find they have scheduled (or have been scheduled by someone else) to deliver two or more demos back-to-back.  For teams in highly “transactional” sales situations this can run all day…!

Far too often, one demo runs beyond the time allocated – causing the presales person to be late joining the next web session (“Sorry I’m late…”) and allowing no time to prepare.

Similarly, there’s no time at the end of the demo to document questions, issues or impressions for the presales person before having to dive into the next demo session.  It only takes a few of these in a row to reduce whatever notes might have been captured to a few, often erroneous items!

A Few Recommendations

(Note – these are not necessarily mutually exclusive!  One or more of these ideas can be combined)

0.       Set the WebEx/GoToMeeting/Live Meeting session to begin 10 minutes before the “real” meeting is scheduled to start (not applicable if multiple customer participants are connecting from several remote locations, but truly terrific if the customer participants are in a single conference room).

1.      If you must do a corporate overview, reduce it to one slide.

2.      Turn the call into a Discovery session, if possible (and appropriate).

3.      Reduce the product overview presentation to just the case study slides.  Case studies can be a wonderful way to move the customer into doing Discovery – “here’s an example of how other, similar customers have used our capabilities to solve specific business challenges – how does what they faced compare with your situation?”

4.      Use the Menu Approach (a terrific self-rescue technique), if the audience is a group and/or if your software addresses a range of problem areas.  [See my article entitled, The Menu Approach – a Truly Terrific Demo Self-Rescue Technique for more details.]

5.      Organize the demo itself in chunks – similar to how newspapers and web news services present news articles.  [See my article entitled, Why Structure a Demo Like a News Article for more details.]

And, for those who often are currently scheduled to do multiple demos back-to-back, consider blocking the 15 minutes before and 15 minutes after each demo as “Prep” and “Clean-Up” time on your calendar – give yourself a fighting chance!

Copyright © 2012 The Second Derivative – All Rights Reserved.

The Menu Approach – A Truly Terrific Demo Self-Rescue Technique

Have you ever been in a situation where:

a.      You find yourself in front of an audience about which you know nothing of their needs or interests – and they’ve been promised a demo…

b.      You are asked to join a web session, right now, and the sales person says, “They asked to see a demo…”  (again, you have zero information about the customer)…

c.       Someone walks up to you at a trade-show booth and says, “What do you guys do?” or “Show me a demo…”

 Are you interested in a delightful self-rescue technique for situations like these?  It’s called The Menu Approach – and it is a logical, simple and surprisingly effective method for dealing with situations where your audience is partly or largely undiscovered.

Hungry?

Imagine walking into a nice restaurant – and you are quite hungry.  You sit down and a few moments later the waiter comes up to you and asks, “What would you like to eat tonight?”

You have no idea what they offer, so you respond, “What do you have?”  The waiter says, “Well, we have lots of items – appetizers, main dishes, side dishes, desserts – what would you like?”

Very frustrating…!  Clearly, you are both making no progress – and it is very much the same situation as requests for demos where neither party has a clear idea of the other’s desires or capabilities.

A solution?  For our restaurant scenario, the waiter says, “Here, let me get you a menu…”

The menu provides a rapid method for the customer to assess what is possible, what sounds good, and what items or combination of dishes to order.  A menu presents a high-level listing of the range of offerings – and we can apply the same principle to the wonderful world of demos.

The Menu Approach

Back to situation “a.” at the top of page 1, above…  You are in front of a group of 12 people, about which you know very little – and you’ve been asked to present a demo.  Instead of taking the customer on a painful and boring “Harbor Tour”, you start by presenting a list of topics that you believe may be of interest.  For a Great Demo! Workshop, a typical list might look like:

-          Remote Demos – Generating Interactivity

-          Making Demos Remarkable

-          RFP’s and Scripted Demos

-          Storytelling and Demos

-          Managing and Out-flanking Competition

-          Managing Questions and Time

-          POC’s, POV’s, and Sandboxes Tools and Strategies

You say, “Here is a list of some topics we could cover.  Let me describe each one briefly and then I’ll ask for a show of hands – and each of you can vote for as many topics as you wish¹.” 

At the end of the exercise, your list now might look like:

-          Remote Demos – Generating Interactivity - 10

-          Making Demos Remarkable  - 11

-          RFP’s and Scripted Demos - 5

-          Storytelling and Demos - 3

-          Managing and Out-flanking Competition - 9

-          Managing Questions and Time - 2

-          POC’s, POV’s, and Sandboxes Tools and Strategies  - 5

You then re-order, to yield a list that is rank-prioritized in accord with customer interest:

-          Making Demos Remarkable  - 11

-          Remote Demos – Generating Interactivity - 10

-          Managing and Out-flanking Competition - 9

-          RFP’s and Scripted Demos - 5

-          POC’s, POV’s, and Sandboxes Tools and Strategies  - 5

-          Storytelling and Demos - 3

-          Managing Questions and Time - 2

Wow!  You now have accomplished several, truly terrific things:

1.      You’ve uncovered the customer’s most important issues (they’re at the top of the list)

2.      You have a road-map for the balance of the demo

3.      You can organize your time to ensure you address the high-importance topics – and it’s OK if you don’t have time to cover everything on the list.

Additionally, you may have also expanded the customer’s vision of what solutions and solution areas your organization provides, as it is possible that the customer was previously unaware that you have offerings across this range of topics.

A Few Subtleties…

When counting votes, remember that businesses are not necessarily democracies – and all votes are not necessarily equal.  For example, if there is one C-level person in the room, and she is the only one who wants “Managing Questions and Time”, that topic moves (magically and mystically) to the top of the list.

Similarly, you can choose to bias the presentation (and subsequent scoring) of topics up or down in accord with your current understanding of the customer’s situation – “Many of the other customers we’ve worked with in very similar situations to what you’ve shared with us so far found that the topic on managing POC’s was most important – they were able to save months of otherwise wasted effort as a result of what they learned…  How many of you are interested in this?”

Finally, when you complete a topic, you can use strike-through text to show that it has been completed, giving you (and the customer) a written record of what was completed and what is still open:

-          Making Demos Remarkable  - 11

-          Remote Demos – Generating Interactivity - 10

-          Managing and Out-flanking Competition - 9

-          RFP’s and Scripted Demos - 5

-          POC’s, POV’s, and Sandboxes Tools and Strategies  - 5

-          Storytelling and Demos - 3

-          Managing Questions and Time - 2

 “Show Me A Demo…”

If you have ever worked a demo station at a trade-show, you are familiar with the prospect who walks up to you and says, “What do you guys do?” or simply, “Show me a demo…” (Clearly, they know not what they ask!).

A solution?  Use The Menu Approach.  You can have your list of topics available on your demo computer or tablet – or consider having a list produced as a poster, laminated, and attached to the wall of your demo station.  You can then simply point to your Menu and begin the same process as above:  

“Here is a list of some of the things we do – let me describe each briefly and then you can let me know which one(s) are most interesting to you.”

Delightful!

Many Great Demo! Workshop participants have reported that The Menu Approach is one of the most effective tools they have used.  The Menu Approach – a truly terrific demo self-rescue tool for situations where your audience is partly or largely undiscovered.

¹Often referred to as a “Chicago-style” vote…

 

Copyright © 2012 The Second Derivative – All Rights Reserved.

“What’s at Risk?”

In a recent Great Demo! Workshop one of the participant teams came up with the expression “What’s at Risk?” for the Delta label on their Situation Slides – very nice!

Why Did They Say, “Oh That’s Cool…!”?

In the delivery of traditional demos, presenters typically note when audience members react positively to particular software screens – and often incorporate those screens in future demos with the expectation that other audiences will be similarly interested.

Seasoned practitioners (and especially seasoned Great Demo! practitioners) not only recognize the importance of those particular screens, but also seek to understand the “why” behind customers’ reactions.

In the course of a demo, when a customer audience member offers an unexpected positive response to a particular software screen (“Oh, that’s really cool…!”), seasoned presales people pursue a dialog that might go something like this:

Customer (reacting to the particular screen of interest):  “Oh, that’s really cool…!”

Demonstrator:  “Great – glad you like it.   Would you share why it caught your eye?”

Customer:  “Sure – this screen solves one of our major issues…”

Demonstrator:  “And what issue is that?”

Customer:  “Well, with our current process, it takes forever to get this done.”

Demonstrator:  “Interesting – how often do you have to run this process, and how many people are involved?”

Customer:  “We’re doing it weekly and it consumes about 10 folks time for an entire day each.”

Demonstrator:  “Wow – so being able to complete process in a few mouse clicks translates to freeing up something like 2 FTE.  You’re right – that’s really cool.”

…And the dialog could continue…

Our objective here is to be able to complete a Situation Slide, essentially, giving us the ability to use the “Oh, cool…!” customer response in a much more focused and leveraged manner for other customers (as well as in our summary at the end of the current demo).