Oh No Mr. Bill! Your Software is Going End-of-Life.

Posted on July 23, 2008 | Filed Under Leverage | View the Print Version

When negotiating, you should be aware of the principle of Negotiation Leverage. Leverage describes the use of facts, rationale or conditions to move the other party closer to your way of thinking. Here are some simple examples:

Your software is already installed and in production, or your services team has completed 2 phases of a 3 phase implementation project. You have leverage when additional licenses are required for the same task, or when phase 3 of the project starts, because your software or services team is proven, and there is a cost of conversion to move to another alternative.

Leverage can be related to time (such as end-of-life). When cars are leased, there is leverage on the buyer (leasing party) to make a decision at the point of the lease expiration (or slightly before). This leverage is created because of the problems related to loss of transportation if the decision is not made before the leased car must be returned. Conversely, there is very little leverage available to convince the buyer to make a decision just a few weeks or months after the lease is first signed. The risk of lost transportation does not exist yet.

Value provides leverage. If I can offer you a guarantee of 4% on your money, versus first-half-2008 stock market performance, I can get you to accept an alternative (a “low” return on your money) that in a bull market is unattractive.

From time to time, K&R consults on sales situations that are forecasted to close predicated on the end-of-life or withdrawal from marketing of a software product, and the corresponding lack of availability of standard support services for that product. In nearly every case, we find that the situation is not as clear as the seller suggests it is (or wants it to be).

Normally, this is what we hear: “Product X is going end-of-life in 180 days. My customer won’t be able to accept the risk of running production systems on it after that date. The time it takes to convert to my (better) Product Y is 60 days. So, I am forecasting that we will close the deal on Y in 120 days or less. This is a sure win.” Think of it as the “Oh No Mr. Bill!”^[1] argument.

In nearly every case, this will be insufficient to win the sale.

Here are the flaws:

The heart of the “Oh No Mr. Bill!” argument is the fear of catastrophe. The argument presumes that end-of-life means a failure will occur, and that the impact to a production system will be severe. In fact, the opposite is often true. In many cases, an end-of-life product has had additional versions released, all of which the buyer has declined to buy. This likely means that the failure history is acceptable, which is likely to continue. After all, the software doesn’t know about the end-of-life date. The failure history may be acceptable because the work performed is not critical, or because the failures don’t happen. The “Oh No Mr. Bill!” argument confuses what is possible with what is likely.

Even if the risk of failure is real, the argument fails to persuasively articulate the risk of that failure. A more effective method to describe it would follow these lines, “If the system fails, you will be unable to register your incoming students on-line for the fall semester. You’ll have to fall back to manual processes. Your expense will rise by $7 million. Your client (student) satisfaction will plummet, and you may lose enrollment.” This argument links failure with the costs and implications of the failure. The implications are described in terms that the client (in this case a university) would find important. Without this sort of description, the seller is assuming the buyer will connect the risks to the consequences by themselves.

However, in many cases the argument above will be hard to make. If such failures were occurring with any regularity, and the risks (business impacts) were real, then the likelihood of the client still using the nearly-end-of-life product would be low.

The answer lies in the approaches we have laid out before (see our articles in the “Value” section). Buyers need to understand the business value of a solution to be motivated to act. Fear-mongering alone (”Oh No Mr. Bill!”) won’t do it.

Not convinced? Let’s take a short look at a relevant real-life example - Windows XP and Vista.

Microsoft’s experience in providing Vista as an upgrade/replacement/whatever for XP has been written about at least 740,000 times according to Google. We’ll assume that you have read some of those. While not an end-of-life scenario, it is a step in that direction. Microsoft made value arguments to XP users - they were only modestly effective in driving the conversion to Vista. Many people weighed stability, conversion cost, breadth of support, mixed platform considerations and more against the added business value of Vista. Many people stuck with, and continued to install, XP. Microsoft delayed the end-of-marketing date at least once. After end-of-marketing, almost every major PC/laptop vendor today offers an “XP downgrade” program for systems that must (by Microsoft’s terms) come preloaded with Vista. Microsoft has itself described situations to get around its own marketing rules, which allow netbooks and others to continue with XP. One interpretation of this is that they mis-assessed the leverage they had to force buyers to move. Another interpretation is that they tried to force movement to Vista with an artificial “expiration date”, not with business value.

Don’t make the same mistake - look beyond “Oh No Mr. Bill!” when you are trying to close a sale. (td)

[1] Mr. Bill is the clay figurine star of a series of short subjects shown from 1976 to 1980 on Saturday Night Live (SNL). The “Mr. Bill Show” was a parody of children’s shows.

Comments

You must be logged in to make a comment. Sign on, or register to obtain a username and password.

Oh No Mr. Bill! Your Software is Going End-of-Life.

Comments

Leave a Comment

Recently

Categories

Archives

Recently Written

Monthly Archives

Find It

Users

Copyright