What I've Learned From Sales, Part I: Don't Feed the Trolls
This is the first part of “What I’ve Learned From Sales.” In this part, “Don’t Feed the Trolls,” I present my explanation for why people act like “trolls,” raising objection after objection to new ideas, and I suggest how to side-step this behaviour and deal directly with their concerns.
(Part II, Wanna Bet?
, describes how to handle one very common form of objection. Part III, How to use a blunt instrument to sharpen your saw
, describes the mind-set that there are opportunities for improvement to be found everywhere.)
“Oh no,” you must be thinking, “another Guy Kawasaki
wanna-be trying to tell me how to sell things.” Well, yes
to the wanna-be accusation, but no
to the proposition that this is a general-purpose article about sales. I am not going to pretend to tell you how to promote your business, turn your product idea into a money-maker, or even how to sell yourself to an employer.
What I am going to share with you is some experience I have had with sales that strongly parallels my experience discussing new ideas with people. (I know, reasoning by analogy is often faulty. But it’s what we humans do, we’re pattern-matching machines.) If you find that people seem unreasonably resistant to good ideas like more powerful programming languages
, putting people before process
, or valuing working code above documents
, you may find this helpful.
Guy Kawasaki’s The Macintosh Way
explains how to create and evangelize great ideas, whether they are products for sale or world-changing movements.
Our model here is that the mental process of considering a new idea is the same as the mental process behind buying something. If you are discussing a new idea with someone—even if you aren’t actively trying to “sell” it to them—they are still going through the buying process. And if they have trouble accepting the idea, they will resist, or in sales jargon, they will “raise objections.”
Do you think this is specific to sales? No, when we see new ideas like the Ruby programming language, we encounter objection after objection. Some are ironic: Some Java enthusiast objects to Ruby on performance grounds: perhaps they are too young to remember when the C/C++ folks objected to Java on performance grounds? Or perhaps it will be the IDE support objection, or the Not Invented By Microsoft (a/k/a Not a Corporate Standard) objection, or any of a million others that are not completely unreasonable, but are also usually irrelevant.What is an objection?
On the face of it, an objection is an expression of a discrepancy between your idea and what someone wants. So if they say “Lisp has too many parentheses,” you might think that they are saying “I would use Lisp if it didn’t have so many parentheses.”
The great secret we can learn from sales is that this is not true
. As we will see below, people say what they think other people want them to say. So someone might be thinking “Lisp is too hard for me, all this talk of
and tail recursion
is confusing.” But they are embarrassed to admit this, so they seize on something that sounds more reasonable, like “the syntax is weird.”
We need to understand this, because the absolute worst thing you can do with an objection is answer it directly
. If someone is really thinking “Lisp is too hard,” what good does it do to try to persuade them that parentheses are their friends? They don’t really care. Worse, if you trot out the benefits of homiconicity and its applications to macros and introspection and meta-circularity
, you’re actually making Lisp sound harder
, not easier.
At one time I was a Macintosh salesperson. I used to sell Mac SEs and Mac IIs in “The Dark Times” after Steve Jobs was expelled from Apple by the vile and treacherous Prince John…
Let me give you an example from my own experience in sales. At one time I was a Macintosh salesperson. I used to sell Mac SEs
and Mac IIs
in “The Dark Times” after Steve Jobs was expelled from Apple by the vile and treacherous Prince John
… but I digress
. I was a Macintosh salesperson at a time much like this time: nineteen out of twenty computer sales were PCs.
Revolution in the Valley
tells the incredible story of the creation of the Macintosh—from the perspectives of the people who were actually there. It’s packed with behind-the-scenes anecdotes and little-known secrets. Much of the material is available on line for free
You would think that selling Macintoshes would be a lonely existence. But no, the phone would ring regularly and customers would visit the office on a daily basis, always with the same question, Why should I buy a Macintosh instead of a PC?
And at first, I would answer this question. Macintoshes were superior to PCs in every way. (Actually, this was technically very true at that time. Why, you could run as many as six monitors on a Macintosh II! But I am digressing from my digression.)
I learned a funny thing about answering people’s questions. I would answer their questions, and they would argue
with me. I would say that you could run multiple monitors on a Macintosh II, making yourself more productive. And they would say “but I don’t need to be that
productive, so that doesn’t count.” Or I would say that the mouse and windowing interface is easier to use, you can learn to use more programs. And they would say “but all I need is a word processor and a spreadsheet, so I don’t need to learn new programs.”
(Why would they do that? It was so that if someone asked them, “did you shop around and make an intelligent decision?,” they could reply, “why yes, I shopped around, I checked out Macs and PCs, I did a lot of research, and surprise surprise, I ended up with the exact same thing that my neighbour Bob has
, except mine is running at 12Mhz and poor Bob is stuck with 10Mhz.” It may sound to you like they are doing an awful lot of work just to be able to say that one thing with a straight face, but I can tell you that there is this multi-billion dollar automobile industry that works on this principle: people want to be a little better than their neighbour, but not so much better that they are different
than their neighbour.)
I can give you many more examples, but the interesting thing is not whether people wanted this stuff or not, but no matter how convincingly I answered their question, they would just ask another one. Their questions had nothing to do with how they were making up their mind.
What people think often bears no relationship to how they behave
I learned very quickly that what people think often bears no relationship to how they behave. People usually say the things that they think other people expect them to say, but they go ahead and do whatever it is they always wanted to do. In the case of buying computers, my observation is that most people want to buy whatever it is that most people are buying. They want to belong
, to fit in
. So they are going to buy a PC. Or an iPod.
So what was really
on their mind was fitting in, even though they argued about the Macintosh’s technical merits.
The lesson I learned is that before we can introduce a new idea to someone, we first need to understand what is really on their mind.
Salespeople call this “uncovering the hidden objection”. They have all these elaborate techniques for figuring out what’s really on a prospect’s mind when they encounter resistance to the sales pitch. I’m not going to suggest we do that. Instead, I’m going to suggest we avoid the objections in the first place by “qualifying.”
What is “qualifying” and why is it the most important step in the sales process?
The most important principle of effective selling is that qualifying the customer is more important than overcoming objections.
Many people say the most important step is “closing,” the art of getting the prospect to hand over the money, the end of the sale. If you judge by the behaviour of people selling time shares, fitness club memberships, and automobiles, this is the only thing salespeople work on: haranguing prospects and ‘overcoming objections’ by arguing.
Experienced and successful salespeople follow a different path. Experienced salespeople believe that the most important step is qualifying
, the art of discovering whether a prospect has an actual need for the product, the beginning
of the sale. Salespeople who are strong qualifiers spend almost no effort on closing because they are always working with prospects who want to buy.
On the other hand, if you do not discover their real problem, you extol virtues that have no attraction for them and neglect to address any perceived issues in their mind. The principle at work is that if you know what someone really needs, you address their needs from the very beginning. When you arrive at the conclusion, you have already addressed any questions they may have.
This is true for sales. It is also true for new ideas. If someone fears that an idea like learning Lisp (or meta-programming, or designing a program in the technical interview) would be too difficult for them, you will only be successful if you first explain how easily they will learn the new idea
, and only then explain how wonderful the idea is.
If someone doesn’t have a headache, you cannot establish the value of an aspirin for them… Don’t focus on how you think your new idea can help them be better. Instead, focus on whether they have an urgent problem that your new idea can fix.
Although there are various models for understanding people’s motivations—such as Maslow’s Hierarchy of Needs
, or the Greed-Belonging-Exclusivity-Fear Quartet—for development tools and methodologies my experience is that the simplest model fits best: people are motivated to solve their problems
: if you can identify a problem they think they have, you can show them how to solve it.
In On Intelligence
, Jeff Hawkins explains how the human neocortex matches visual, audible, and kinaesthetic patterns—and replays them to form the basis of prediction. He makes a convincing case that the neocortex is the single most important distinction between humans and other species… and therein explains what makes humans human.
People without problems are not good prospects for lightweight development methodologies, new development tools, programming languages, or any other “change for the better.” Just the other day I was lunching with Dmitri from Opalis
. We were talking about a development tool I am trying to build, and Dmitri was suggesting that it was a “vitamin” and not an “aspirin”
I was taken aback. Isn’t improving software development important for everyone? Then I remembered my sales training and asked him about how things were going at Opalis. Dmitri admitted that his team was performing well and that he had built a lot of trust with his organization. So he didn’t have a problem. Quite simply, if someone doesn’t have a headache, you cannot establish the value of an aspirin for them.
Now, even Dmitri’s team has room for improvement, so it is not correct to say that there is no value in improved methodologies, tools, languages, or anything else for him. However, such things may not be a priority
right now. This is exactly the same case as trying to sell a Macintosh to Bob’s neighbour: I believed that absolutely everyone could have benefited from owning a Macintosh. However, Bob’s neighbour didn’t think he had a usability problem, he thought he had an urgent “keeping up with Bob” problem.
And there’s the key: Don’t focus on how you
think your new idea can help them be better. Instead, focus on whether they have an urgent problem that your new idea can fix.
Discovering their priorities shouldn’t difficult. Why don’t we simply ask them? Well, there’s a trick to asking someone about their priorities. Remember, they will tell you what they think other people want to hear, not what they are thinking. Here’s an example concerning agile development:Agilist
: “What’re your priorities for the development team in the next 60-90 days?” Manager Says
: “I have a total commitment to process improvement and faster response to business initiatives,” …but thinks
… CMM Level Four—or, God willing, Level Five—will get me a higher profile and a shot at the CIO position. I need some consultants in here to start imposing some bondage and discipline over our development processes.
The trick is to get specific and objective
. Never take objections as evidence of their real needs, and never accept vague feel-good values at face value. Top salespeople don’t. Try calling a busy estate agent and saying you’d like to buy a house. I guarantee that the agent will ask you, “when do you need to buy a new house?” And so it is with new ideas:
You cannot position lightweight development, tools, languages, or any other type of change without being able to fit them into the specific and objective problems someone is trying to solve. You need to relentlessly pursue the immediate, urgent priority:Startup Founder
: “I’ve heard that Agile stuff is crap—it only works for star programmers who would be good no matter how you manage them.” Agilist
: “Well, there’re a lot of opinions out there. Tell me, what would you say is the most pressing issue facing your development team right now?” Startup Founder
: “Well, we have hacked together some great stuff, but we need to scale, and to scale without imploding we’ll need some discipline, some real management of the development team. That’s why we need a real
: “I can understand the importance of scaling up. So, have you set some specific objectives for scaling up over the next month or two?”Startup Founder
: “For the next couple of months? Oh, it’s all about recruiting, definitely recruiting. I need another two or three top people to work on a new project that could be worth millions. We’ve identified some good candidates, but it’s very difficult to get them to accept an offer from a start up.” Agilist
: “You know, we really ought to consider whether using Agile might help you recruit—have you considered the possibility that some star candidates might be looking for an environment that is more Agile than the one they are leaving?” Startup Founder
As you can tell, once you have a specific problem with specific dates attached to when the problem needs to be resolved, you can discuss a specific solution. You’ve side-stepped the useless “objections.” One more time: do not accept vague objectives, get specific objectives with near-term dates attached to them.
If someone really doesn’t have any applicable near-term objective, you will not be able to introduce a new idea to them. So don’t be surprised if they express very little interest. But when you have an immediate, specific objective in hand, you can position the idea as a solution to their problem.
And that works for almost any idea. Say you had a new programming language designed for set-top boxes. But it turns out nobody has a “programming set top boxes” problem. So they raise objections about the speed of your virtual machine, or the fact that programmers cannot manage memory in your language, so they cannot squeeze programs into very small spaces.
Should you keep pounding away at that? Or go looking for an immediate problem people have, like building web applications?
If you side-step their objections—like memory management—and get to the root of their immediate needs, you might be able to introduce a new popular programming language. Good luck!Part II, Wanna Bet?, describes how to handle one very common form of objection. If you liked this post, you might also like a related post, The false dichotomy of choosing between your values and expediency.
Labels: agile, popular