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!
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:
- During Discovery
- During demo delivery
- During discussion of implementation and beyond
Let’s examine each…
How to Differentiate
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.