Stomp The Heck Out Of Your Customer's Main Objection
Hiya guys! Merry Christmas! Patrick (patio11) here. You signed up for periodic emails from me about making and selling software.
[Edit: Alright, strictly speaking, you might not have ever gotten an email from me. Somebody might have just given you the link to this page, which is an online archive of an email that I sent to folks who had asked for it. If you'd like to get articles like this in your inbox, totally free, about once a week or two, give me your email address.]
Normally I tend to write fairly beefy essays, but I'm back home for Christmas and I don't think either of us are really in the mood for that right now, so today will be one quick copywriting/sales tip.
Objections Are The Reasons People Aren't Buying
People don't need a reason to not buy your thing -- that's the default. Everyone has happily gone their entire lives without buying your software. The balance changes, though, after they're in a sales conversation with you -- whether reading your home page or talking directly to you.
Hopefully, you're giving people persuasive reasons to try your software, buy your product, or get into a business relationship with you. But people still have voiced and unvoiced doubts. The sales literature calls them objections.
I'm an engineer, not a copywriter, but some of the best results I've ever had for writing sales copy (and person-to-person sales) come from repeating a simple tactic:
- Find your typical customer's main objection.
- Nuke it.
How do you find an objection? You can do this quantitatively via surveys, but when starting out, qualitative feedback is easier to get and often more useful. Just ask. Ask people directly, when they're actually reading your copy (or speaking to you), what their reservations are.
The first few times you do this, you can mentally chalk it up as research. You might or might not be able to answer that reservation off the top of your head. If you can, great. If not, still great. It doesn't even really matter if you win the sale. There are many more sales in the future. You just want to get a good mental model of your typical customer.
After you've been in a market for a while, you'll be able to guess objections prior to folks voicing them, based on your experiences with similar customers in the past.
Answering Objections... Decisively
Here's a very common objection: "It costs too much."
The first thing to note is that objections are statements about people's subjective impressions of your product, rather than objective measurements. "It costs too much" is a common objection applied to free products. No, really, read that again. If your customer is not aware of the price, then they might perceive it to be more than they are willing to pay, and as a result they could have a pricing objection.
A concrete example of this: I do some pro-bono work every year with Khan Academy, an educational charity. You've probably heard of them. Their product is free, quality education. That's the core of the value proposition and so fundamental to the reason why anyone would work at KA that it wasn't even mentioned on the home page.
So question for you: What does Khan Academy cost?
"Inside the building", as Steve Blank would say, KA is clearly free. As perceived by potential customers, KA is high-quality education, and in the absence of explicit statements to the contrary many customers will assume they can't afford it. Many people will assume that there must be a trick somewhere -- that's too good of a deal to be true. Maybe you'll sign up for KA and then get billed $100 if you don't cancel. That won't happen, but it comports with the experience and worldview of many potential customers.
We fixed KA's home page with three words: "Completely free, forever." In an A/B test that increased their signups by 3.7%, which translates into tens or hundreds of thousands of extra students reached. One objection, decisively squashed.
For priced products, pricing objections are often a sign that you haven't anchored your value high enough. People are really terrible at doing blue-sky comparisons (see Predictably Irrational), so give them a framework to evaluate your price within. For example, sketch out an ROI calculation for your users. Just try your best effort for the typical case: it's illustrative, not a submission to an academic journal. Alternatively, you can just put them in the mind of things which are more expensive than your software, like the cost of employee time or the value of lost sales.
Pricing is such a deep topic that I'm devoting a full chapter for my conversion optimization course to the design of pricing pages. You can use your own plans/product line as anchors without needing to rely solely on external ones. This is helpful, as you have full control of the positioning of your internal anchors.
You Are Not Your Customer
As software people, we often take for granted that everyone understands how software "works." Not just how code executes, but how software typically changes systems that it is introduced to. For example, repeating the same action is generally really really cheap, but doing "trivial" customizations is often really really expensive. Customers often don't have an intuitive sense of these things, and accordingly they'll sometimes have objections which we would never think of raising.
Back when I was working at BigCo, we sold software systems to Japanese universities. One prominent objection was "We can't give you our data! It won't be safe!" (You'll hear this even today in some customer segments with regards to SaaS.)
In actual fact, the universities typically held all their data on a server sitting in an unlocked room in a building accessible by tens of thousands of people on an open campus. They felt secure in that, though: they knew who was in charge of it and had some model of the risks associated with it. Our systems were in a data center which was guarded like Fort Knox and maintained by experts, which is utterly standard in the industry, but prior to hearing what the standard was people would assume the worst.
A gentleman in charge of an organization rather larger than mine once had the same reservation about Appointment Reminder. I started answering decisively: "We keep all of your data in a guarded data center, with access strictly limited to authorized people. I wouldn't even be allowed in myself. Once it is on the machines, we..." He stopped me right there, and said he had been worried about me hosting it out of my apartment, and if I was already taking Fortune 500 precautions that was good enough for him.
It doesn't matter that that guess would be (one hopes) outlandishly out of character for serious businesses in our industry. It only matters that it's a sincerely felt objection. Since it is, crush it.
People are better at remembering images than they are remembering claims or facts. "256-bit SSL encryption" is a true fact about your software product, but for most customers it goes in one ear and out the other. "Bank-grade encryption" is an image -- people can envision the vault -- and is vastly more likely to be recalled favorably when someone is worried about security.
Repetition works. Clients are more likely to trust, and more trusting of, claims which you hammer in, because repetition works. Studies show that repetition works even for false claims which participants a-priori know to be false. (Oh, humanity.) Use this for good rather than for evil.
Engineers and writers often tend to value concision. This is unfortunate, because repetition works. Instead, if something is very important to you, taking a few runs at the topic will tend to make you sound more credible even if you're saying substantially the same thing.
An example: I recently had a client for Appointment Reminder who believed, based on a complaint, that we were spamming her customers. This was incorrect. Just saying "We didn't do that" would not necessarily be persuasive, though.
Instead, after empathizing with her (I'm genuinely sorry that she got yelled at by a client due to the actions of some no-account bastard doing naughty things), I said that not only did we not do it, but we'd never do it, we have policies and procedures to prevent doing it accidentally, it's physically impossible for us to do it, and if I caught somebody doing it, I would rain down hellfire, because it is a contemptuous practice that we'd never, ever approve of.
That made her quite happy. (I also went the extra mile and found out what had likely happened, but I think that would have been persuasive even without that.)
What can we say about repetition? Yep, it works.
Interested In Getting Better At Answering Objections?
Answering objections is one of the topics covered in my course on conversion optimization, which will be launching in January. Today, December 20th, is the last day for the 20% early adopter discount, because in another 12 hours or so I'm clocking out of the business and enjoying Christmas with my family.
If selling more software is relevant to your interests, I'd suggest checking the course out. If you're working at a software business at scale, conversion optimization would be a great thing to get started on in the new year, before you get swamped with the usual day-to-day grind. The first attempts at implementing A/B testing systematically often increase sales by 5 to 10% in my experience.
If conversion optimization is not your cup of eggnog, no worries, enjoy the holidays with your families and loved ones, and I'll see you next year.
Since It Is A Season For Reflections...
My family has a tradition of going around the table and mentioning what we're thankful for this year. I've got two relevant to you all: one, that I'm recovering to mostly-healthy. I'd encourage everyone in the industry to devote more time and effort to staying healthy, because generally we skimp on it (in exercise, diet, work-life balance, sleep hygiene, and other ways besides). Trust the voice of recent experience: getting sick has majorly outsized impacts on QOL and productivity.
Two, I'm extraordinarily blessed that, as a portion of my career, I get to help folks like you out. Writing is much more satisfying for me than configuring servers or doing XML mappings, and nothing makes me happier businesswise than hearing when my advice actually matters for folks. Drop me an email if there is ever anything I can do.
Merry Christmas, and may you and yours have peace, health, and prosperity, now and always.
Regards,
Patrick McKenzie