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

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?

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

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