Monday, December 23, 2013

‘Twas the Night Before The Big Demo

‘Twas the Night Before The Big Demo
(with apologies to Clement Clarke Moore)

‘Twas the night ‘fore the demo and all through the house
Not a creature was stirring, ‘cept my SC and his mouse;
I’d proposed a big licensing deal with great care
In hopes a big order soon would be there;
Management was restless and not in their beds
As visions of bonuses danced in their heads;
And my VP with his forecast and me with my own,
Had just started a long EOQ roam,

When out from my mobile there came a great ring-tone,
I sprang from my chair to answer my phone,
What could it be?  Was it good news or no?
A last-minute order?  A contract?  PO?

Greetings, said my assistant, who spoke on the line,
It was someone to see me, offering help at this time!
Who could it be at this late eleventh-hour,
To make the deal sweet and avoid something sour?

Away to the door I flew in a flash,
And swept it open in my quest for fast cash,
When who to my wondering eyes should appear,
The DemoGuru! And standing so near!

He came in my office and, while dusting off snow,
Said, “I have some news that you’ll want to know.”
He drew up a chair and asked for some tea,
And said to my VP, SC and to me:

“Your deal is in trouble and I’ll tell you now,
Your demo’s confusing, complex and lacks ‘Wow!’
It’s riddled with features and functions and more,
And too many cool things, mouse clicks galore,

Don’t flog them with features and other neat stuff,
Stick with the substance, stay away from the fluff,
The more that you show is not always nice,
Customers may say, ‘Please lower the price!’

The Buzzword-Compliant Vocabulary list,
Are words, I’m afraid, that are better-off missed,
Not Flexible, nor Powerful, nor Easy-to-Use,
Not Robust, nor Seamlessly Integrated abuse,

And no corporate overview, please don’t do that,
After ten minutes they’re grabbing their hats,
Present as a team, so if things get hairy,
Sales folks aren’t lost in the back with Blackberry.

Your customer’s queued and ready to go,
They love the vision you’ve built with them so
They want Technical Proof in the demo you’ve planned,
Just the key capabilities, everything else banned.”

“But how can we do this?” I heard myself cry,
“We’re victims of momentum, we’re nervous to try,
Another approach, a new way to go,
We have to admit we’re just a bit slow!”

“Do the Last Thing First!” he said with a smile,
“Then peel back the layers, and Do It with style,
Peel it back in accord with their interest,
Stay focused and execute, and you’ll find it best,

Your customer’s Situation is a great way to intro,
Their Problems and Reasons, from CBI flow,
Review these and check – is this still the case?
Are we aligned or are we off-base?

Start with the end, that big pay-off piece,
Illustrate and describe, those are the keys!
Capture their interest, compel their attention,
Make sure it aligns with their mode of consumption.

When it clicks and they’re hooked, they’ll then ask for more,
There’s absolutely no way that they’ll head for the door,
They’ll say, “Please show us, prove that it’s so,
Show us the rest, please do demo.”

Then Do It, just Do It, with no extra clicks,
To return to that Illustrative image that sticks,
Make it simple, make it fast, make it easy and clear,
Then they will realize they’ve nothing to fear,

Encourage their questions, most are not new,
Good ones and Great ones (and Stupid ones too),
Treat Hostiles with courtesy, use your Parking Lot so
Those mean, crusty folks can’t damage your flow,

Peel back the layers, Do It Again,
Show only what’s needed, put nothing else in,
Let them drive the demo, let them think they’re in charge,
While their Vision Solution you work to enlarge!

Summarize, summarize, tell them again,
‘Cause adults do learn by repetition,
And when you show a key take-away screen,
Leave it up, let it linger, so they’ll know what they’ve seen!

“I get it – I’ll do it!” exclaimed my SC,
“This is all so obvious, it’s way clear to me!”
And he sprang into action, his mouse flew like lightening,
(Frankly, his speed was a little bit frightening!)

And with that the DemoGuru smiled and he said,
“Your way is now clear, put that baby to bed,
Your deal’s now on track, your order secure,
You’ll make your numbers at the end of the year,

Then he strode from my office in a blink of a pun,
Turned ‘round and he said, “My job here is done,”
Ere he drove out of sight, I did hear him say,
“Great Demo! to all and to all a Great Day!”

Monday, December 9, 2013

[Warning: Shameless Self-Promotion Alert!] Great Demo! Public Workshops – 2014 Schedule

We are offering three Great Demo! Public Workshops in 2014, as follows:

-          March 5-6 – Registration and additional information can be found at

-          May 21-22 – Registration and additional information can be found at

-          October 15-16 – Registration and additional information can be found at

These are 1.5-Day Workshops, with the first day focusing largely on core Great Demo! material, and the 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.  They are excellent opportunities for individuals, small groups or for teams that have new hires.

We’ve found that these sessions 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.

Wednesday, December 4, 2013

Stunningly Awful Sales Kickoff Demos

Stunningly Awful Sales Kickoff Demos
Selling to Your Sales Force – The Toughest Customer of All!
Cries of “Who cares?”, “So what?” and “What’s this good for?” issue from the more vocal members of the audience – and everyone else appears to be apathetic.  Bad news!
The situation?  You are demonstrating your new, earth-shattering, game-changing product at the annual sales kickoff meeting – but it is not going well.  This is your big opportunity to “sell to sales” and put your new product foremost in the minds of the sales team – and they’re not responding as you’d hoped. 
Most demos to the sales force of new products, and new releases of existing products, are uncompelling, unconvincing and fail to generate the desired excitement. 
What’s going wrong and what can you do?
Here’s a rapid answer:  capture and communicate Customer Success Stories or Use Cases to generate a vision of how your customers will benefit from using your new offering.  Start with your customers’ business issues, present these up-front and then map the balance of the demo to the specific capabilities customers need to solve their business problems.
The result?  You gain sales force “Share-of-mind” – and achieve your roll-out objectives!
A Lack of Vision
Most demos of new products are all about certain key features – key features, that is, from the perspective of marketing.  Most demos of new releases are all about the new features. 
Product Marketing and Product Managers live and breathe their new products over a period of months or years.  They know their new offerings intimately – every new feature, every bug, every blemish – and, of course, the missing major feature or two they couldn’t get into the release (sadly, these are often important dashboards or reports, the very deliverables most desired by customers!). 
Marketing generally has a strong vision of how customers should use the new offering in their minds.  The question is: does this vision coincide with reality?
When marketing folks demo their new products, they tend to focus on the key and new features, describe the underlying technology, show how they work and all the cool options available.  However, they often fail to build a vision with their salespeople of what good things these new features will enable for the customers – and that is the critical element missing in their demos.
The key to a successful product launch or new release demo is Vision Generation for the sales team.  You must build a vision in your salespeople’s minds of how your offering will help your customers solve their business problems.  The new offering needs to be perceived by the team as “Easy to sell, easy to buy”.
Vision Clearing…
Why do you build and sell software?  Two answers:
  1. To make a profit.
  2. To help your customers solve their business problems.
When you “sell” to the sales force you need to keep both of these in mind.  Your sales people will preferentially sell the products that are easiest to sell and easiest for their customers to buy.  Most typically, new products are not the easiest to sell, in comparison with existing offerings. 
Salespeople know that new products will often have bugs and may lack important functionality.  New products also often suffer from the challenges of “Crossing the Chasm” – they may have a limited initial audience of interest in the customer base.  Salespeople may choose to keep on selling existing, proven products, in order to make their quotas comfortably and predictably. 
Put yourself in their shoes:  you are in the audience and another product manager is demoing his new product.  Over a period of 50 minutes he shows a pile of “really cool” features and options.  He used a set of fictional characters, “Susan, the Manager”, “John, the user” and “Bob, the IT guy” to tell a story.  By the end of the 50 minutes you’ve seen a lot of screens, options and dialog boxes, but you are more confused (or bored!) than excited. 
The new offering looks complicated and confusing – and you are not sure which customers to approach or how to present the product.  “Let someone else waste time with this,” you think.
Vision Clarified
Now contemplate the following scenario:  move the clock forward one year.  You are listening to a sales success story for your recently released “TurboForecasterPro” product at the next year’s sales kickoff meeting.  The successful sales person is relating why the customer made the purchase and presents a slide with the following information:
Job Title and Industry:       VP of Sales, Acme Software
Critical Business Issue:      Concerned about achieving forecasted revenues
Problems/Reasons:           Forecast data sits in local, regional spreadsheets, requiring hours of manual “roll-up” work from reps, regional heads, and admin staff each time the forecast is updated.  Lots of errors, takes too long, always late.  Unable to see which projects need attention, which are likely end as “no decision”, difficult to assign resources wisely. 
Specific Capabilities:          A way to aggregate the data from the sales offices around the world and generate real-time reports showing forecast and pipeline, on-demand, right from the VP of Sales’ laptop computer; identify key  opportunities to address and coach; deploy appropriate resources effectively.
Delta:                                    $30M in incremental revenue; redeploy 4 sales operations FTE to more productive tasks.
Critical Date:                       In place to roll-out at sales kickoff meeting January 20, 2014.
We Sold:                              200 licenses of TurboForcasterPro, plus services, totaling $575,000.
The other salespeople in the room get excited and start asking for more details.  Why?  Because they have similar customers with similar situations and rapidly realize that your product can provide the capabilities these customers need.  They realize that the slide is a terrific Customer Success Story, a compelling and successful way to introduce the new product to their customers – it is a template that can be applied right away.
“Show us the demo you used to make this sale,” say the other sales folks. 
The presales colleague to the successful sales person does so – and takes only eight minutes to show what is needed.
The other sales reps are now excited and ready to go sell your new product.  They have a clear vision of:
ü  Who are the target customers – by job title and industry
ü  What overarching goals or objectives are at risk (Critical Business Issues)
ü  The underlying problems and reasons that are keeping these goals and objectives from being achieved – what is getting in the way (Problems/Reasons)
ü  The specific capabilities provided by your new product to solve the problems (Specific Capabilities)
ü  The value of the solution, in your customers’ minds (Delta)
ü  Critical dates or events that drove customers’ implementation timelines (Critical Date)
ü  And:  The size of the sale, for the sales people (very important!)
Good stuff!  Now, contemplate how you might have accelerated the sales of your new product if you’d provided this information at the first sales kick-off meeting…
Capturing Customer Success Stories
When presenting and demonstrating to your sales people, you need to make your new product as attractive, as easy to communicate and as easy to sell as possible.
For existing products, Customer Success Stories are often the best way for salespeople to engage and begin a sales process with a customer.  However, new products often don’t have the benefit of Customer Success Stories – so what do you do?
First, if you have any pre-release customers who used your product, interview them to generate reasonable Success Stories.  Ask them:
o    [List their job title and industry]
o    What goals or objectives are now being achieved as a result of using your new software?
o    What were the underlying problems or reasons that made it hard to achieve the desired objectives – what was getting in the way, previously?
o    Which specific capabilities are they now using address these problems, from your product?
o    What is the value of the solution, from their perspective (in terms of people, time or money saved – tangible real numbers, not platitudes!)?
o    Was there a critical date or event that drove a timeline to implement (did they need to have the new solution in place before a specific date – and why)?
o    [Then, list the size of the sale or expected sale, based on the scenario]
“Sanitize” as necessary and you have a terrific Customer Success Story for your new product launch.
NOTE:  Since you will not use the name of the specific customer when presenting to prospects, so you do not need to get legal approval to relate the rest of the information.  These are known as “Informal Customer Success Stories” and are the lifeblood of a software organization!
But We Don’t Have Any Customers, Yet…
If you don’t have any customer experiences that you can harvest, then you need to create fictional or “suppositional” Success Stories.  These should be based on your expected customer situations or Use Cases.  Create these fictional Success Stories from the following questions:
What are the target job titles and industries?  For each specific job title and industry:
o    What goals or objectives are likely at risk?
o    What underlying problems or reasons do you expect make it hard to achieve the desired objectives?
o    Which specific capabilities from your product do you expect will enable the customer to address the problems?
o    What is a reasonable expectation of the value of the solution, from the customer’s perspective (again in terms of concrete numbers:  people, time or money saved)?
o    Is there a critical date or event that you expect will drive a need to implement by a specific date?
o    [List the size of the expected sale]
This is an effective and compelling starting point to help your salespeople sell your new offering.
Vision Clearly Communicated
Now, back to our sales kickoff meeting…  Instead of flogging your sales team with a long, detailed demo of the new product, start with building a crisp vision of likely customer success scenarios. 
Accordingly, begin your presentation with a set of existing or fictional Customer Success Stories.  These will clearly illustrate the opportunities represented and provide the top-level information to target and qualify customers.  You’ll want to provide a series of Success Stories like a menu, so that the sales team can see the depth and breadth of the customers the new offering can help.
You then follow with a demo that shows example outcomes for each Customer Success Story, from the customer’s perspective.  For example, in our VP of Sales case above, you would start your demo by showing the completed forecast and pipeline reports, to prove that they can be done and to generate a vision of the solution right up-front.  You then show the specific capabilities needed to roll-up that forecast and pipeline, using the fewest number of steps or mouse clicks. 
Keep it short, simple, and to the point.  In most cases, you can easily relate a complete Customer Success Story and show its accompanying demo in less than eight minutes! 
Vision Achieved and Amplified
By presenting your new offering in the context of Customer Success Stories, your sales organization can begin to sell your product right away.  You’ve succeeded in communicating how customers can use and get value from your product – via real-life usage situations. 
You’ve amplified your message as well:  you’ve transferred the knowledge of how to communicate your product’s key uses from a single person (you) to the entire sales force in a way that is compelling and resonates with the sales people.  You’ve also built a vision of what good things selling your offering will do for the sales folks, themselves!
The result?  You’ve equipped your sales team with the three most important concepts possible: 
  1. Your new product will be compelling and easy to introduce to their target customers.
  2. It will be easy to prove and demonstrate – to move the sales process forward.
  3. The sales team sees your new offering as a terrific way to achieve quota.
 Easy to sell, easy to buy.
Copyright © 2005-2013 The Second Derivative – All Rights Reserved.

Wednesday, November 20, 2013

Stunningly Awful Demo Outcomes – Why Objections Shouldn't Need To Be Overcome

“Help me understand how to handle customer objections…”
“My team needs to learn how to handle objections…” 

What’s wrong with these requests?

Many sales methodologies discuss ways to “overcome objections”.  Many sales managers ask for skills training for their teams on “overcoming objections”.  Is it possible these folks are working to address the wrong problem – or are these symptoms of a deeper problem?  Perhaps objections shouldn’t come up in the first place, in a well executed sales process or demo… 

Let’s explore some typical “objections”, their causes and some solutions:

- “We don’t need the Cadillac version, we just want the Chevy…” 

This is an indication that too many features and functions were presented in the demo – many more than the Specific Capabilities the customer actually needs.  Solution?  Uncover and understand what Specific Capabilities the customer needs during Discovery and present only these in the demo. 

- “Your product looks too complicated for most of our users – so we only want a couple of licenses for a few experts to use…”

The demo showed too many clicks, options, if/or choices and pathways, and made tasks look much more complicated than they needed to be.  Solution?  Just “Do It”:  Show the shortest path to get any specific task completed – the fewest number of clicks or taps to get that task done.  Let the customer ask for more detail if interested…

- “I’m not comfortable with you as a vendor…”

What’s going here?  In spite of a 20 slide corporate overview presentation, the customer still doesn’t perceive the vendor as viable – why?  It is likely the customer is concerned about one or more areas of risk:  implementation, support, product roadmap, previous experience, or similar.  These concerns should be surfaced and addressed during Discovery. 

Let’s take implementation as an example:  “Let’s discuss how we can help you move from your current situation to Go Live and then all the way through to your first significant ROI event...”  Having this discussion during Discovery will uncover any major issues that either can be addressed – or (at least) let the vendor know that this sales opportunity is not going to be successful, before investing further energy.

- “While your product does cover about 80% of our requirements, it is missing a few critical capabilities…”

Once again, Discovery was likely insufficient in uncovering and understanding customer needs.  During Discovery, if your customer asks for capabilities that you lack, you need to ask about use:  “How often would you use this?  How important is it?  Who would use it?” (And similar, related questions).  The answers will let you know whether your offering is a sufficiently good match – or not – well before you get to the demo stage…! 

In sales, if you are going to fail, fail early and fail cheaply – and move on to another, better opportunity.

Further, many vendors believe that they can overcome this issue by offering and presenting additional capabilities that “competitively differentiate”.  This ends up in a vicious circle with the first two objections!  More is not necessarily better…  (See my article Stunningly Awful vs. Truly Terrific Competitive Differentiation – What, When, and How for more ideas on how to successfully differentiate…)

- “Your product looks good, but we feel we can continue to live with the current situation…”

This is a symptom that there is no Critical Business Issue – the customer agrees that there is a problem, but solving it is not sufficiently compelling for them to invest tangible resources to address it (in terms of time, people or money).  Part of the process of Discovery is to help the customer understand how big, how critical, and how important it is for the customer to address the problem. 

During Discovery, look for and uncover goals or objectives that are at risk. These are best if they are specific quarterly, project-based, or annual goals or objectives that will not be achieved or completed if the problem doesn’t get solved.  They become part of the overall driving force for making a change.

- “We don’t see enough value…”

Insufficient perception of value on the part of the customer is a classic “objection”.  (Once again) this needs to be uncovered and addressed during Discovery.  Workflow analysis is specifically designed to identify the Delta(s) – tangible expressions of value in terms of time, people of money.  These are strongest when they come from the customer’s own lips.  Sufficiently large Deltas become key drivers in seeking a solution.

- “Your product is way too expensive for us (but thanks for the education)…”

Similar situation to the above.  General price ranges should be discussed early in the process e.g., during Discovery).  Vendors are not required to give specific pricing until Discovery is complete, but the customer needs to know whether the solution is within possibility for them.

- “We really like your solution, but we don’t need it yet…”

The lack of a Critical Date or Critical Event is what often causes a sales opportunity to roll over on sales forecasts from quarter to quarter to quarter (ever see this happen)?  And the Critical Date has to be something of significance to the customer, not the vendor’s end of quarter!  When should a Critical Date or Event be identified?  Let’s all say it together, “During Discovery!”

What’s the moral here?  Most “objections” arise late in the sales process as a result of incomplete or insufficient Discovery.  Discovery is clearly the best place to uncover and address these issues – before they become “objections”!

Sunday, November 17, 2013

The “Museum Demo”

Just heard another (delightful) term for “informational/educational” demos:  The “Museum Demo”.  (Let me know if this needs an explanation…!)

We can add this to the ever-growing list:

-          Show Up and Throw Up
-          Spray and Pray
-          Tech Splatter
-          Wet Noodle
-          Harbor Tour [my personal favorite!]

Any to add?

Wednesday, November 13, 2013

Stunningly Awful Demo Strategy: Set-up vs. Daily Use Modes

Most traditional demos follow an illogical pathway to show vendor offerings – they spend far too much showing “Set-up” mode vs. “Daily Use” situations.  This results in confused audiences and customers’ perception that the software is “too complicated”.  (Ever had that happen?)

For example, most traditional demos start by presenting how a user can set up a particular workflow or task framework, from scratch.  “First we turn on this setting, then we build this form, which you can change and customize further; if you want to do this then click that; if you want this other thing then change this parameter here…”, etc.  This process often consumes 20, 30 or 40 minutes of a traditional demo, as the demonstrator walks through the many options and choices involved with setting-up the workflow.

By the time the presenter has completed this process, the audience is already exhausted – waaaay too much stuff to remember, waaaay too confusing, and many audience members will have already “checked-out”.

Even worse, traditional demonstrators often never show how the user would actually use the workflow just created – it is assumed, by the vendor, that the user will somehow figure this out on their own (they won’t, typically). 

“Daily Use” mode, on the other hand, is where most people spend most of their time.  “I just want to see the current report”.  In a demo, show how easy it is to run or access that current report (that’s the “Do It!” pathway in Great Demo! methodology).  If the customer is interested in modifying the report (or learning how to create it from scratch), let them ask..!

Think about your own work day:  How much time do you spend in “Daily Use” mode vs. “Set-up” mode? 

[Along similar lines, how many “Day in the Life” demos focus on “Set-up” mode?  Seems like a bit of an oxymoron…!]

Thursday, November 7, 2013

The Best Demo Is: No Demo!

A demo is, generally speaking, a form of proof or vision generation.  Our objective in sales is to secure the order using the least expensive form of proof. 

With that in mind, here, in order of increasing expense for the vendor, are forms of proof for a customer:

-          Reference call (to another, similar customer or peer) – basically free

-          Vision Generation Demo – very little resource required

-          Technical Proof Demo – moderate resource required

-          POC – (often) enormous resource required

-          Pilot – yet more (although some Pilots are paid-for, they still potentially consume huge amounts of vendor resources)

Our objective in a sales process is to stay as high as possible on this list.  (And shame on the sales team that offers a POC without the customer requesting it…!)

Friday, October 25, 2013

[Warning: Shameless Self-Promotion Alert!] Great Demo! Audiobook Now Available

Yes, due to overwhelming demand, Great Demo! is now available in Audiobook format at, and iTunes.  So now you can sit back and simply listen to some compelling ideas, riveting stories, and amusing anecdotes – without the strain of moving your eyes back and forth.  Audiobooks are terrific for those car drives from account to account and on flights when you don’t want to have to interact with the person sitting next to you!

Please note:  a professional did the voice-over for the Audiobook, as the author would not (or could not) do the reading himself…

Wednesday, October 23, 2013

Competitive Differentiation - Why Did They Buy From You?

The best sales teams go back to their customers well after the sale has been completed and ask, “So, what made you choose us [over XXX competitor]?”  The answers are sometimes what you expect, but often you learn surprising new information on how customers perceive you as a vendor.  This information should feed back into your positioning, Discovery conversations and other elements of your sales, implementation and follow-up processes.  What have you heard from your customers that differentiates your company lately?

Harvest this information and use it!

Sunday, October 13, 2013

Better Than "Thank You For Your Time"

Here’s an interesting challenge and an elegant solution to it:  In my previous company I was VP and then President of a business unit and had sales people calling on me as the customer.  I noted that nearly all of these sales people stated conversations or presentations with phrases like, “I know you are very busy…” or “Thank you very much for your time…”  While these phrases are courteous, they sounded very pleading and anxious, and seemed to result in these sales people (unconsciously) placing themselves as subservient to their customer.  Not a particularly robust starting point!

One of my colleagues offered a terrific alternative that we began to use, with excellent success.  She suggested, “I’m glad we were able to invest this time together today…”, resulting in our sales team positioning themselves as equals to their C-level and VP customers,   Much stronger!

Monday, October 7, 2013

Recording Web Demos Reduces Hostile Questions

A Great Demo! Workshop participant noted recently that announcing that you are recording a Remote Demo (e.g., delivered via WebEx or GoToMeeting) reduces the likelihood of hostile questions from audience members.  Not surprisingly, these “hostile” audience members don’t want their nasty questions or sniping comments captured in the recording!

Monday, September 23, 2013

[Warning: Shameless Self-Promotion Alert] Great Demo! Public Workshop October 9-10

Our next Great Demo! Public Workshop is scheduled for October 9-10 in San Jose, California – Registration information can be found here (

This is a 1.5-Day Workshop, with the first day focusing largely on core Great Demo! concepts and the morning of the second day addressing more advanced topics and techniques. This is an excellent opportunity for individuals, small groups or for teams that have new hires.

Register using the link above or contact me for more information (

Friday, September 20, 2013

The Insufficiency 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.  The phrase, “So What?” represents one tactic that helps push vendor representatives to talk about advantages as opposed to features.  This is a good start, 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 that’s a dangerous assumption! 

Here’s an example of why:

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

In this example, the “So What” fails, because the vendor presumed the 21 additional languages would be desired by the customer.  (Note that a good job doing Discovery would have clarified this – and avoided the faux pas…).  But wait, there’s more…

The customer then 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…”

“So What” has backfired – and the vendor is now at risk of “buying it back”.

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


The best solution?  Introduce your capabilities via questions in Discovery, well before a demo.  Once you’ve either uncovered a need (and the customer has confirmed 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, and Benefit statements – simplified here:

Features:  are the description of 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) or (best of all) when the customer verbalizes the benefit statement!

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

Revisiting Example 1, 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 posts in this blog or as articles on my website: “Stunningly Awful vs. Truly Terrific Competitive Differentiation” or “Competitive Demo Situations – Biasing Towards Your Strengths” (at for further information on these ideas (or send me an email at and I’d be happy to send you the articles).