My last column dealt with the all-too-familiar marketing/IT tug-of-war, where I explained that the role the CTO/CIO plays is one of risk management; given things like scope creep, etc., the CTO has to promise the least she thinks you will accept in the most amount of time that you can stand. CTOs as a group have a fairly standard way of handling new projects/ideas/processes, particularly those that are introduced by the business side of the company. I've worked together with John Quarto-vonTivadar to share these with you. I hope you work with your vendor to overcome these challenges.
There are four common objection phases the CTO has developed to deal with marketing's request:
Ignore the first request. Knowing that the marketer's job is to fall in love with shiny new objects, waiting until a request gets brought up a second time is the most efficient way to know which things take time to look into.
Surface completely logical and "obvious" objections. The CTO needs and wants to know the answers to these objections, but this is a cognitive variation of ignoring the first request, for if we answer these objections incorrectly it will mean she can bypass the project without having to dive deeply. Note that most companies assume that what they hear at this point are the real objections. They are rarely so. These are simply the casual roadblocks - which if we don't pass, there's no need to get into deep discussions about anything else.
In-depth objections. These are the real concerns a CTO wishes to express. These take a substantial investment of time and thus get presented later in the process, often when we think we've cleared the technical objections but have only gotten over the initial two phases of objections.
Give the project a cold shoulder. At this point, it's very possible for us to assume that the information we provided is sufficient, that "the facts speak for themselves," etc. Such a response can easily put the CTO off if it's presented wrong. We want to be the people who are helping the CTO get her job done and learn something about herself in the process. If we instead go down the path of meeting the objection with the blunt end of the smart stick, the CTO may feel threatened, or begin to ask questions that she knows we don't have the answer to, or will take a sufficiently long time to answer so that she can push everything back to the initial phases. "Why don't we just build this ourselves internally?" is a question the CTO may not even bring up with us directly, but simply whisper in the ear of the business executives. There may be no malice here at all - yet it may still take six months or more to realize that it can't be built internally.
Once we understand these phases we can learn to deal with the most common objections, such as:
"We should just build this ourselves internally." This objection can go both ways. The CTO might be very excited about what your marketing technology does and want to build something herself. CTOs also like shiny new projects. Alternately, she might be trying to kill the project, because if she can convince the internal team that internal resources can build the same thing, it will be months before she has to put it on a development schedule. There are several ways to overcome this objection. You can try a very direct way if you have strong internal support. Tell the team to build it and then ask if they can have an initial project plan ready by Monday or in two weeks. The idea here is that if the CTO is trying to kill the project, she now has to do work over the weekend to continue to kill it. A good alternative is to be prepared with an estimate of how much revenue your marketing technology might be expected to generate for the business on a monthly basis. Then ask the CTO to estimate how many months it would take from now until the "build it internally" project is live, multiply this by the estimate of revenue improvement if you integrated today, and present that as the "opportunity cost" of not installing your marketing tech project immediately.
"The last thing we need is something else to integrate!" This is the perennial problem for CTOs: too many demands on their time. The best way to handle this: assume the CTO is always thinking this, and proactively describe how simple it is to integrate your marketing project; also point out that there are step-by-step guides for implementation and how much other time and effort your marketing technology can save her team.
"Will Marketing Tech X slow down system performance?" A great concern, and the right answer should always be "No!" If it isn't then you have a bigger problem. Explain how your technology uses things like asynchronous tags, your average response times, how you scale for large clients, etc.
"What is Marketing Tech X's uptime? Downtime? What happens when Marketing Tech X just goes down?" When the CTO asks about uptime/downtime, she's thinking in terms of both the service-level agreement (implies her other objections have been met) and is gathering some numbers to write down to cover her ass. There is no reason for not having these two stats memorized and at the ready and being able to explain what happens if your technology fails for some reason.
"We think integration will take X hours - but where are the resources for that going to come from?" The CTO is saying she's OK with the project and needs guidance from the business side as to whose budget this work will come under or what other project(s) on her to-do list are about to get de-prioritized. The CTO may also need political cover. This would be a good time to make sure the internal champion is in on the conversation since she will know how to navigate this issue. Try to help the CTO not be the bad guy who is busting someone else's development schedule.
These are five of the most common objections we've come across in almost 15+ years of working through marketing/IT projects. I'm sure you have come across others that you may or may not have been able to overcome. What were they? If you did overcome them, how?
Editor's note: This article was originally published on August 24, 2012.
Bryan Eisenberg is coauthor of the Wall Street Journal, Amazon, BusinessWeek, and New York Times bestselling books "Call to Action," "Waiting For Your Cat to Bark?," and "Always Be Testing." Bryan is a professional marketing speaker and has keynoted conferences globally such as SES, Shop.org, Direct Marketing Association, MarketingSherpa, Econsultancy, Webcom, SEM Konferansen Norway, the Canadian Marketing Association, and others. In 2010, Bryan was named a winner of the Direct Marketing Educational Foundation's Rising Stars Awards, which recognizes the most talented professionals 40 years of age or younger in the field of direct/interactive marketing. He is also cofounder and chairman emeritus of the Web Analytics Association. Bryan serves as an advisory board member of SES Conference & Expo, the eMetrics Marketing Optimization Summit, and several venture capital backed companies. He works with his coauthor and brother Jeffrey Eisenberg. You can find them at BryanEisenberg.com.