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 Amazon.com, audible.com. 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 (http://www.skmurphy.com/blog/2012/10/23/great-demo-workshop-on-oct-9-10-2013/).

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 (PCohan@SecondDerivative.com).

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

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 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 www.secondderivative.com/Articles.html) for further information on these ideas (or send me an email at PCohan@SecondDerivative.com and I’d be happy to send you the articles).

Monday, August 26, 2013

Stunningly Awful vs. Truly Terrific Competitive Differentiation – What, When, and How

Competitive Differentiation:  vendors want to differentiate, vendors try to differentiate, but most vendors fail to meaningfully and successfully differentiate, in the opinion of their customers.  When done poorly, differentiation can be stunningly awful; when done well it can be truly terrific!  Let’s explore…

What Is Competitive Differentiation? 

Most vendors define this as “capabilities that we have or do better than our competition”.   Pretty straightforward, right?  But do customers share this definition?  Likely not. 

Customers are looking for solutions that fit their perception of their current and expected future needs.  A vendor with capabilities the meets these current and future needs exactly is clearly the best choice, everything else being equal (such as price). 

With that in mind, a vendor who seeks to “differentiate” by simply presenting capabilities that another vendor lacks is at risk.  What if the customer doesn’t see the need for these additional capabilities?  What if they don’t care or, worse, can’t use them?  Then these additional capabilities become a liability. 

For example, let’s say you are shopping for a new set of kitchen knives.  At the store, you are looking at several knife sets and the sales person steers you to one particular set of 10 knives, saying, “This set is better because it has 10 knives – one more than most – plus a sharpener, so you can keep all of your knives razor-sharp.”  The other sets on display only have nine knives. 

Sounds like a win, right?  However, it turns out that your knife block only has room for 9 knives and no place for a sharpener.  You are concerned that the extra knife and sharpener will end up rattling around in a drawer – and possibly be a hazard.  Differentiation has occurred, but not positive differentiation!  The larger knife set is perceived as “too much” and possibly “too expensive” (if it costs more than the set of 9) or “cheap” if the price is the same as the set of 9, since the perception will likely be that each knife individually is worth less. 

The world of software is similar.  Let’s say you are looking for a tool that helps you to address availability problems with your website.  You’ve decided you want something that sends you an email message with an appropriate link when a problem is imminent, so that you can click the link that logs you into the system, find the root cause, and address the problem.

-          Vendor 1 does an excellent job doing Discovery with you – and then presents a demo that specifically shows email alerts and the ability to drill down and find root causes. 

-          Vendor 2 does a good job doing Discovery with you – and then presents a demo that shows email alerts and ability to drill down and find root causes, and also shows you a system dashboard while describing why dashboards are so wonderful.

Who will get the order?  Shouldn’t Vendor 2 get your business?  After all, they have what you need plus a fabulous dashboard.

You give the order to Vendor 1, however.  Why?  In doing Discovery with you, Vendor 1 learned that you hate to have to open a pile of applications and review dashboards.  You explained that you’d much rather only have to pay attention when a problem is pending – and email alerts are your preferred mode of receiving this information.  Vendor 1’s demo was right on target.

[Interestingly, Vendor 1 also had dashboard capabilities, but elected not to show them, since you had communicated your strong dislike of dashboards.  Turns out that both vendor offerings were essentially equal in capabilities, but Vendor 2 showed a capability you didn’t want or couldn’t use:  Negative differentiation. 

Note also that Vendor 1 asked a few additional questions in Discovery – with respect to how you want to consume the alert information – and uncovered your dislike of dashboards:  Vendor 1 achieved some additional positive differentiation through the more complete Discovery work.

In spite of the above rather sad scenarios (for the knife sales person and Vendor 2), most vendors view differentiation in terms of the features and functions of their offerings.  “Ours has this, and theirs doesn’t” or “Ours does this better than theirs does”.

Positive feature- or capability-based differentiation only takes place when the customer agrees that the capability is beneficial in their specific situation – when the customer visualizes using the capability sufficiently often and/or the problem the capability addresses is sufficiently important to solve.  Otherwise, the extra features and capabilities are perceived as making the offering too complicated or too expensive:  “We don’t need the Cadillac; we just want the economy car version…”

When to Differentiate?  All the Time…!

From the customers’ perspective vendors are “differentiating”, positively or negatively, with every contact, every meeting, and every deliverable.  Let’s explore possible negative differentiation first.  How do you feel about:

-          Vendors that cold call you – repeatedly? 
-          Vendors that take forever to answer your email inquiries – or ignore what you asked? 
-          Vendors that leap right to showing you a “solution”, without sufficient Discovery?
-          Vendors whose demos look complicated or confusing, in spite of having a pile of “competitive differentiators”?
-          Sales people that speak ill of their competition?
-          Sales people that are “cagey” about providing pricing information?
-          Vendors that over-promise and under-deliver? 

Interestingly – and sadly – the list above is what often occurs with typical, traditional vendors and sales people.  Most of us as customers perceive these items as unpleasant and they contribute to an overall negative impression.  Unwittingly, perhaps, these vendors and sales people have differentiated negatively.

Let’s look at the same list again, but with a different approach to each item:

-          Nurture or “trickle” marketing activities (as opposed to cold calling).  [For extra credit, contemplate the intent of this article…!]
-          Rapid, specific responses to email inquiries.
-          Thorough and intelligent Discovery – before presenting solutions. 
-          Crisp, focused, engaging demos of the Specific Capabilities needed by customers.
-          Sales teams that are clear and honest about their own offerings’ strengths and limitations.
-          Clear and transparent pricing information.
-          Building a vision of how the customer will move from their current (painful) state to their desired (glorious) future state with the solution in place and operating. 

Generally speaking, these activities are viewed favorably by customers.  Vendors that follow these processes are already differentiating positively in comparison with “traditional” vendors.

In addition to the observations above, there are (at least) three major opportunities to differentiate, positively, in sales interactions with customers:

1.      During Discovery

2.      During demo delivery

3.      During discussion of implementation and beyond

Let’s examine each…

How to Differentiate

During Discovery:

This is one of the most effective ways to out-flank your competition.  Do Discovery with a bias towards potentially differentiating capabilities you offer (and your competition lacks or doesn’t do as well), such that those capabilities become part of the customer’s vision of a solution. 

The use of “Biased Questions” is a terrific and highly successful technique of introducing capabilities that you believe should be important to your customer, but the customer has not yet requested those capabilities.  They may (often) be unaware that such capabilities exist. 

Here’s a quick example:  Let’s say that your offering provides alerts in the form of email messages when certain thresholds are reached (as many offerings do) – but in your case, you can also set alerts based on approaching a certain threshold. 

During Discovery, you might say, “Some of the other organizations we’ve worked with that had situations very similar to what you’ve outlined so far, found that the ability to set alerts based on approaching certain thresholds enabled them to take action before problems grew large – and they were able to save hundreds of thousands of dollars as a result.  Is this something you might also find useful in your practice?”

Your customer responds, “Why yes, that sounds really great – and I can see how we could use that.  Wish we’d had it before!”

This capability has now become a Specific Capability desired by your customer – and you can prepare and plan to demonstrate it accordingly.  Since your competition can’t offer the capability, but only the simple alerts, you have successfully positively differentiated.

Let’s explore this a bit further.  The “Biased Question” method has three elements that make it a successful and compelling approach:

-         The Similarity:  Your first step is to establish a relationship between your current prospect and other organizations – particularly those that are perceived by the prospect as being similar to them.

-         The Capability:  You describe the capability itself and its advantages and potential benefits.

-         The Reward:  You describe what rewards other, similar organizations have realized through the use of the capability.

Finally, you test to see if this capability also sounds interesting or particularly useful to the customer.  If it does, you have successfully and positively differentiated.  Look for as many opportunities to differentiate during Discovery as possible so that you set yourself up as the dominant or preferred vendor – the only vendor that can provide the capabilities now desired by the customer.

During the Demo:

Most vendors try to differentiate during demos – and very often end up “buying it back”.  This is an intriguing problem inherent in software sales.  From the perspective of most vendors, offerings with more capabilities should be better for the customer, right?

Nope!  Have you ever heard customers say, during price discussions, “Well, you showed us a bunch of stuff we’ll never use, so either take those capabilities out or reduce the price.”  The customers’ perspective is that they are buying much more product than they need (“Cadillac vs. economy car”), so they demand a price discount as compensation.  This is known as “buying it back” – a very sad situation for the vendor!

A more elegant and wise approach to differentiate during a demo is to use Biased Questions when you believe you may have uncovered an unmet need or other opportunity.  The process is the same as using Biased Questions during Discovery, but in this case you can also offer to demonstrate the capability (if the customer would like to see it).

During Discussion of Implementation – and Beyond:

Traditional sales people (and sales teams) are done with their sales cycles when the purchase order arrives, leaving implementation to their professional services team, partner organization, or the customer.  Stronger sales people and sales teams develop a vision with the customer of the steps and process of moving the customer from their current problem state to completed implementation – the “go live” date.  (Some sales methodologies call this process developing the “Transition Vision”).

The truly terrific sales people and sales teams carry this further out into the future – to the point where the customer has his/her first small win, small victory, or initial ROI.  This is also the point in time when the customer can become a real reference.  What a wonderful way to positively differentiate!

Beyond the Software

But wait, there’s more…  In earlier articles and blog posts I recommend (rather strongly) against inflicting corporate overview presentations on your customers.  Interestingly, some elements from typical corporate overview presentations can be harvested and used to differentiate very nicely – but not in the form of the dreaded traditional corporate overview. 

Once a customer has seen that your offering can provide a solution to their problem, they begin to be interested in learning more about your organization.  After all, they are not just buying your code, but they are also buying a relationship with a vendor. 

Think about how customers perceive your strengths, as an organization.  For example, what is your reputation regarding support?  Implementation?  On-time and as-promised releases (Oh, please…!).  Technology leadership?  Some of these strengths represent opportunities to differentiate, beyond your software.

For example, let’s say you have a particularly strong and active users’ community – and your competition does not.  Here’s an opportunity to use a Biased Question to differentiate:

You say, “Some of the other customers we’ve worked with that had situations very similar to what you’ve outlined so far, found that one of the most important aspects of the relationship with the vendor had nothing to do with the software itself.  They found that interactions with the users’ community enabled them to easily solve problems they had previously struggled with, deploy more broadly than expected, and implement new, unanticipated applications that were shared within the community.  They were able to realize hundreds of thousands of dollars in additional gains and savings as a result.  Is access to this sort of community something you might also find useful in your implementation?”

Your customer responds strongly in the affirmative.

You add, “Well, I’d be happy to connect you with some of the principals of the local users’ group so that you can get introduced right away…”

The result?  Positive differentiation based on organizational strengths.  [The process of identifying these strengths is known as “Whole Product Analysis”, the term coined by Regis McKenna and popularized by Geoffrey Moore in Crossing the Chasm” – really good stuff!]

What About Price?

Really?  If you have to differentiate on price you’ve failed to establish sufficient value – both with respect to the customer’s problem and especially the value of your solution.  (Time to return to doing Discovery…!)

Truly Terrific Competitive Differentiation – What, When, and How

What:  Look for opportunities to differentiate positively – capabilities or strengths that are perceived as beneficial by the customer – and be aware of how easy it is to differentiate negatively in the eyes of the customer.

When:  All the time(!); and especially during Discovery, during demo delivery, and during discussion of implementation and beyond.

How:  Through the use of Biased Questions – and sources for topics can come from either the capabilities in your software or the strengths of your organization.

 

[Of course, many Great Demo! practitioners comment that simply following the Great Demo! methodology is a terrific way to differentiate, positively!]

 

Copyright © 2013 The Second Derivative – All Rights Reserved.

 

Thursday, August 22, 2013

Feel Good (Generally) When Someone Writes Something Down During Your Demo…

In face-to-face demos, you should feel good (generally speaking) when you see someone make a written note – particularly after you’ve shown a key screen or presented an important idea.  The higher the rank of the person making the note, the better…!  It means, hopefully, that the person has understood the import of what you just presented and wants to remember it.

An additional thought:  When you have multiple members of your team and the customer also has multiple players in the demo, I recommend mixing the seating – as opposed to having “them” on one side of the room or table and “us” on the other.  This enables you to glance and see what that high-level person just wrote down…!

Monday, August 19, 2013

Database/Toolkit Software and Vision Generation: Ingredients vs. Finished Product

Database and similar “toolkit” software are wonderful in that they can do so many things.  The corresponding challenge is that database and toolkit software can be difficult to present to customers who don’t already have a vision of how they want to use these tools.  This can be vision generation at its most challenging!

Part of the problem is that the majority of customers don’t know how to translate the enormous potential offered by these packages into problem-solving applications.  They may know they have a problem –and may be interested in solving the problem, but they don’t see how the database/toolkit will help solve the problem.

Most traditional database/toolkit demos show piles of capabilities, but leave it to the customer to figure out how these features and functions will manifest as a solution to customer problems.  One beautiful solution to this challenge is to show example applications – example finished products – so that customers get a vision of what solutions might look like and relate these examples to their specific situations.

Here’s a simple analogy of two strategies for vision generation that illustrate the idea above:  showing a collection of various food ingredients vs. presenting a selection of the finished dishes. 

You go out to eat breakfast at a restaurant and are seated at your table.  A waiter brings out a cart full of breakfast ingredients, including flour, butter, eggs, potatoes, onions and other vegetables, salt, pepper, sugar, milk, cheese, baking powder, baking soda, etc.,  and says, “Look at all of this cool stuff – just imagine what wonderful dishes we could prepare for you…!”  What are you going to order? 

Has the waiter succeeded in generating a vision of a meal for you?  Likely not…!  He presented the ingredients – the tools – not the finished product, and left it to you to figure out what to do.

On the other hand, what if the waiter brought that same cart out to you – but this time it had plates of waffles, pancakes, omelets, biscuits, muffins and egg dishes, all freshly prepared.  The waiter says, “These are delicious examples of what we can prepare in our kitchen.  Any of these look particularly interesting to you?  Our kitchen can make a range of versions of all of these to your specific tastes.”

Showing the finished product makes all the difference!
 

But wait, there’s more…  Have you ever been in a hotel that offered an “Omelet Station” at breakfast?  This offers a great analogy for a family of related applications.  The Omelet Station operates on the reasonable assumption that you (the customer) already know what an omelet is.  Based on that assumption, you typically see an array of ingredients in bowls or bins and simply choose the combination you want.  The Omelet Station chef then prepares your specific omelet to order. 

The same principal applies to families of related database and toolkit applications.  Once a customer has seen one example application in a family, he can generally used this to develop a vision of a solution, mapping that application to his specific situation and needs.

Monday, August 12, 2013

[Warning: Shameless Self-Promotion Alert] Upcoming 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 (http://www.skmurphy.com/blog/2012/10/23/great-demo-workshop-on-oct-9-10-2013/).

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 (PCohan@SecondDerivative.com).

Wednesday, August 7, 2013

Shadow Pointing in Demos – Don’t

In face-to-face demos, I urge presenters to go directly to the screen (when using a projector and screen) and point specifically at the elements of interest, using fingers or a stick or telescoping pointer. 

Occasionally I see presenters stand a short distance from the screen and point, but using their fingers or pointer to generate a shadow in the beam of the projector.  Don’t do this!  It is unclear to the audience whether to follow the presenter’s fingers (or pointer) vs. the resulting shadow – very confusing!

Monday, August 5, 2013

Demo Question Handling: "How do I...?" vs. "Can I...?"

Listen carefully to how questions are asked:

-           “How do I…?” typically suggests that the customer does want to see how a capability works (but confirm before showing).

-          “Can I…?”, on the other hand, may only require a “yes” or “no” answer, without any explicit need to show how something works.

You can save yourself a great deal of grief and reduce risk by listening and responding carefully!

Monday, July 29, 2013

End-to-End Integrated Overview Full Suite Demo – Analogies and a Few Solutions

The Situation: 

Management wants the presales team to show an “end-to-end overview integrated demo of our full suite…” as a part of a typical “introductory” meeting.  Management is convinced that “customers need to see the power of the integrated suite and all of the key modules”.  This has “Harbor Tour” written all over it (and a very lengthy one at that)!

Analogous Situations:

You are shopping for a new car – and the sales person insists on showing you all of the company’s models and having you test drive each (roadster, economy cars, sedans, SUVs, crossovers, etc.).  How would you feel?

You go to the hospital to see a doctor about a flu that has been dragging on too long – and the doctor points you to the pharmacy and says, “Give everything there a try and let me know what seems to work…”  How would you feel?

You go to a bookstore to find a travel guide to a foreign country for an upcoming vacation – and the store is organized such that you have to walk through (and sample) all of the various book genres (sports, history, cooking, romance, mystery, how-to, self-help, humor, magazines, technology…).  How would you feel?

[Online version of the above]  Imagine searching Amazon for the same travel guide and, instead of Amazon simply presenting the top 20 matches for your search, it insists on having you tour samples of all 36 online departments.  How would you feel?

Imagine sitting down n a nice restaurant – and the waiter brings and serves all of the drinks, appetizers, salads, sounds, main dishes, sides and desserts on the menu – everything the kitchen can prepare – and says, “Try each of these and then let me know what you’d like…”  How would you feel?

Ever been through an Ikea, looking only for one specific item?  How did you feel?

[Feel free to suggest your own analogies…]

Solutions:

The Menu Approach:  This strategy is almost tailor-made for these kinds of situations and has been proven to work delightfully well!  See my article “The Menu Approach - A Truly Terrific Demo Self-Rescue Technique” on our website at www.SecondDerivative.com/Articles.html for further information on the strategy and associated tactics.

Multiple Illustrations Approach:  Invest some time to select Illustrations that are representative of the “pay-off” screens for each module of major chunk of functionality.  Capture these in PowerPoint or KeyNote, preferably.  You can use these in conjunction with the Menu (or similar Roadmap) to literally Illustrate the key advantages/deliverables of each module/chunk.  Where your customer shows interest, you can offer to execute a crisp “Do It” pathway, if the customer wishes.  I’ve seen this approach work extraordinarily well!

Discovery:  What a delightful alternative!  Instead of inflicting a Harbor Tour or one of the less painful (and more considerate approaches) above, why not use the time to do Discovery?  The Menu Approach is a excellent tool to help kick-off Discovery, providing a list of topics to drive the Discovery conversation.