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!