Understanding the sales process (outlined in part one) makes objections seem a lot less daunting. Recall that you are figuring out what the problem is (by asking questions), you’re making your presentation (using lots of vivid stories, and talking about benefits), and you’re explicitly asking for the sale. Read [[Dealing with Objections]] for tips on handling resistance and view objections as a request for more information. * Be eager to want to hear all of the objections. Want them to come up early and forcefully expressed. * Think of an objection as a map. It points you into the right direction. * An objection is simply a request for more information. * Objections shouldn’t make you wilt; objections should make you ask more questions. * If you can’t just kill the objection, then you’re back to asking [[Questions]]. * Get in front of a common objection by just bringing it up first. If you have a really expensive product you might say, “We’re not the cheapest, but…” * Never, ever, ever argue with your prospects. * Always go back to asking questions. ** Probe. Feel around. Try to find out why this is a concern. Try to figure out as much useful information around the issue as you can. Ask them how important that concern is; after all, not all objections are equally serious. Almost always you’ll find some grounds to defeat the objection. Every conversation is different, but this process really works. The basic thing you need to know is that objections fall on you. They are a simple indication that you have not yet given the prospect everything he needs in order to make the decision. You just need to find out what that information is and give it to him. That’s all. Once you have the information you need, deal with the objection. Get a tech person on the call. Explore workarounds. Look for reframing opportunities. Relate how others dealt with this issue. Weigh it next to other benefits. You may even have to simply admit a deficiency in your product, which is always preferable to dissembling about it. !Example. “I don’t think I can use FogBugz because it doesn’t have both severity and priority.” I could launch into my speech about why having both makes no sense, but that’s too combative. A question is the answer. Instead, you might say, “So can you describe for me how you use severity and priority now?” And they’ll tell you. And then you may have some more questions, or you might move gently into your severity/priority speech. For sales technique-combining bonus points, you would tie this speech to some benefits: how using only one of the two saves time, how it reduces case entry overhead, how it increases adoption. Then, if you had a story about another company who stopped using severity and lived to tell about it, well then, you just did a triple axle. Take a bow. The persuasive content of this exchange would be very high. That conversation is an example of [[Reframing]]@nlp, and it’s something you’ll be doing a lot. People frequently have very specific notions of what they “need”, but you will often find that these requirements, when you scratch at them a bit, are not requirements at all, and if you can show them a better way to get where they want to go, not only will they agree to go that way, they’ll be very enthusiastic about it. But what if re-framing fails? In the example above, we could actually just kill the objection because you can have severity and priority in FogBugz; we just think it’s a bad idea.