Editor’s Note: David Raab has thirty years’ experience as a marketer, consultant, speaker, and analyst. He’s the author of The Marketing Performance Measurement Toolkit, and the Raab Association’s reports and guides, including the B2B marketing automation vendor selection tool, the VEST report. You can keep up with David at his blog, Customer Experience Matrix. Atri Chatterjee is Chief Marketing Officer of ZScaler.* They held a three-part conversation which covered the obstacles to buying technology; common mistakes in buying technology; and best practices in buying technology. This blog post is an edited transcript of the third portion. You can listen to the Conversation on the audio player below.
[powerpress]
ATRI: David, in our last two meetings we talked about why it was hard for people trained as marketers to make the right technology purchasing decisions, and the most common mistakes people make. This time we’re going to focus on the positives and talk about ways that people can get it right. So David, tell us: How best can we make this purchasing decision?
DAVID: Atri, there are quite a few things that people can and should do, to end up with a system that actually is going to be the right system for them, or at least an adequate system for them.
Determine your business goals
DAVID: We talked in the earlier sessions about defining goals, but we didn’t really talk much about what it meant to define goals. A goal is not general; you won’t say, “Oh, my goal is to make money.” Your goals need to be very specific things like the “specific kinds of marketing programs that I hope to execute with this system.” And furthermore, as that marketer, I want my goals be quantifiable. I want to find something that will drive a 10 percent increase in retention, not just in revenue, even “revenue’” is too broad a goal. But a 10 percent improvement in my conversion rate, or 10 percent increase in leads that are qualified and sent on to marketing, those are examples of specific and quantifiable goals.
Define your processes
DAVID: Then once you have the goals, you begin to define the processes that you need to achieve those goals. And then once you’ve defined the processes, now you can begin to think about requirements. Because the process is what actually drives your requirements. You lay out the process and you say, “Okay, to do this process, now the system has to do this to do step one, and the system has to do that to do step two, and so on.”
You have to be very, very granular to translate those general goals into specific processes, and then the processes into the requirements. Again, your requirements are absolutely the key things that drive your vendor selection. So that’s the first thing.
ATRI: I’m hearing this: business goals need to be quite specific and they can be intermediate goals, because something as generic or broad based as increased revenue is too broad. You should be able to say “I want to improve campaign performance,” or “I want to improve the responses to my emails,” or “I want to get more social interaction,” or whatever it is. These intermediate goals translate into the specific system requirements.
Use scenarios to test processes step by step
DAVID: Exactly right. Once you know your requirements, you can begin to think in terms of use cases and scenarios. The biggest mistake in this area, and one of the most common, is that marketers don’t develop specific scenarios based on those processes, and then lead a system through it as part of their evaluation process.
You can create as many checklists as you like; you’re still not necessarily going to capture everything. And honestly, vendors will say yes to a lot of things that are on the checklists and truthfully say yes. But it may not really work quite the way you expect it to.
So we really strongly urge all of our clients to insist on having actual scenarios so that we can see how a system walks through them. Then you can see how the steps all fit together, and you see how things are connected, and you see if there’s a bit of awkwardness. It comes right up there. So that’s probably the second major thing that I would urge people to do. Really work up those use cases and scenarios, and then just put the systems through their paces when you’re making a selection.
ATRI: That’s very wise. I think one common question that’ll come up with marketers, say in a situation like marketing automation where not a lot of people have necessarily used it in the recent past or they have not used it at all. They may not have all the well-defined processes that they want to take a system through their paces. What advice would you give them in the cases where they’re largely doing things manually, or using a potpourri of different systems to try to achieve that? How best can they define their process so they can actually judge a system better?
DAVID: To a certain extent – I hesitate to even say this – but you can usually rely on the vendor to show you how it’s done in their system or how other people do it among their clients. Again, what you’re really solving for is the step by step process. Say you want to create a personalized email campaign for cross-sell. You have a certain amount of data analysis to do. You have a certain amount of segmentation. You have a certain type of email to create, and a certain kind of personalization within that email. There are going to be many different ways to do that in different systems. So you can let the vendor walk you through the best way to do it in their system, and that may not be the same best way in some other system. But you at least see the outcome and can say, “Okay, yeah, that process would lead me to what I want.”
Of course the other thing you can do is hire consultants like Raab Associates, who do have that more detailed experience. And (we’re) more than happy to help.
ATRI: I think the value of the consultants is that they’ve seen a much broader picture and they’ve seen a variety of different environments. They’re in a unique position to really compare and contrast and also I think give marketers the business advice based on best practices that they’ve seen in other places.
DAVID: That’s absolutely true. Also, often there are people on your team who have experience in some previous job or previous life, to do this sort of thing. Among the people around the table, everybody usually has some experience. It’s relevant even if the company itself hasn’t done something before.
Other considerations
DAVID: Another thing that’s really important is to not just look at the scenarios, not just look at the process, but also to look at underlying technologies and scalability. And we talked a little in the earlier session about integration.
Some other things that are really important that don’t necessarily show up include support and training. These wouldn’t show up in a scenario but are really important. You have to address those somehow in your selection process – because they certainly will impact whether or not you succeed in the long run.
ATRI: We often get caught up in speeds-and-feeds feature sets, and ask whether a system meets every single requirement that we’ve got. But we don’t really spend enough time on thinking, how will I be judged at the end of the day? How do I define success? What kind of support and training am I going to get? How can I be assured that I’m going to be made successful and the vendor that I’m going to work with is going to ensure my success? Oftentimes that is more important than having every last feature and whiz-bang capability that may be in the product. Because let’s face it, most of us don’t use a system to its fullest degree. And to be successful, we don’t necessarily have to use all the features of a product.
DAVID: That’s right. And often we’re going to end up using the product in some other way that we hadn’t anticipated. That’s just how it works. So you do want to make sure that you have a strong foundation – I won’t use the word “platform” because that has a more technical meaning – but you want to make sure that the system is going to be able to accommodate those unanticipated requirements that are going to turn out to be really important.
If I were listening to this, I’d be wondering, “Well that’s nice, how do I find out if support is good? I can ask the vendor and they’ll tell me, yeah our support’s great.” That’s probably not a real helpful data point. But this is where references matter, and references are very underutilized. People often forget to ask for references. Of course the vendor’s going to give me a happy client. But you can still ask useful questions – get details like how quickly does the phone get answered, are the people knowledgeable, even a happy reference often will give you some pretty good insight into that.
Of course today we also have our friends in social media who are not vendor-supplied references, who are more than happy to give us feedback. You have to be a little careful, because the people who reply may have their own little motives. It may not be a totally unbiased source of information, but it’s definitely a source of information; people should not be reluctant to use it. It’s extremely valuable, and too often ignored. References and social comments are very, very important, as a way to identify issues, particularly those soft things like service and support.
ATRI: It’s very interesting that you bring that up. Just like in an interview, when a candidate gives you references. I find I get a reasonably balanced view from the reference, because I specifically ask the question “How can the candidate get better?” which is analogous to “What could be improved in this system?” A good reference will typically be pretty impartial and say areas where there’s potential or improvement, or things that could be made better. That at least gives you a balanced view of knowing about something before you get into it.
DAVID: Yes, it gives you a perspective that otherwise you wouldn’t get until weeks or months even after you’ve signed a contract and are deep into it.
Plan for deployment and growth
DAVID: Which brings us to yet another – possibly the final – point about long-range planning and the whole deployment process. We talked earlier about requirements being the critical thing. The nice thing about defining requirements in use cases in advance, is it also gives you a roadmap for what you’re going to do after you buy the system. So you get a twofold benefit. You’re going to do the work anyway. You’re going to have to design those marketing programs in order to use the system. So why not design them sooner, so you can use them as reference points for your requirements?
Then when you do buy the system, you have everything all laid out, you have your planning in place, so you know what to do. You’re not scratching your head saying, “Wow, I’ve got this cool system here, what am I going to do with it?” We’ve seen in our research that people who took a longer time to prepare their purchase could then deploy quickly, with a relatively large number of features out of the box, and were much happier. Basically, that was because they really knew what they had and they’d thought it all through in advance. Then they just executed, as opposed to making it up as they went along.
ATRI: That’s very insightful. I got two main things out of the paper you did with VentureBeat (Buyer Survey: 5 Worst Mistakes in Selecting a Marketing Automation System). One was that those who spent a little longer doing their evaluation were usually much more satisfied. The other was that those who did their evaluation in a more holistic way were also more satisfied than those who focused on just the technology requirements, and the bits and bytes and the speeds and feeds.
DAVID: Yes. That’s true. It’s a deep relationship. It’s not just this collection of features, you really do need a company –it’s a cliché but it’s true – that you can partner with. And you have to assess all that up front as best you can.
ATRI: Just as a takeaway, I got five things out of this conversation.
- Start with defining your business goals. Figure out what it is you’re trying to achieve and try to find intermediate goals. Don’t try to solve just massive goals of increasing revenue because those are very hard to measure. But figure out what those intermediate goals are, like campaign performance, response rates, whatever it is, depending on the context of what you’re trying to do.
- Fit those goals into the requirements so that now you know what sort of requirements you have from the system.
- Go through a thorough evaluation process. Consider multiple vendors. Get expert help if you need it because people who’ve had experience doing this have got a much broader perspective and can give you help with best practices and so on.
- Go beyond just the system that’s in front of you, beyond the features and benefits, and look at what’s going to happen after the sale. What’s the support going to be like, what’s the training going to be like? The best way to do this is to talk to other people who’ve used it. Talk to the references the vendor supplies, and use social media to get a better sense of what’s going on.
- Finally, of course, the long range planning. It’s not totally about how the system works today and what it’s going to solve for you today, but: is it going to grow with you into the things that you want to do in the future?
So if all of us follow these five things, we’d do pretty well; we’d not make any mistakes finding a new system.
DAVID: We’d make fewer. [LAUGHTER] That’s about all we can hope for.
ATRI: Well thank you very much, David. This has been great. We’ve talked about all the challenges, the common mistakes, and now you’ve given us some words of wisdom on how to get it right – how to get it as right as we possibly can. Thank you.
DAVID: My pleasure.
Want to read parts 1 and 2 of this series?
Part 1: Why Buying Marketing Technology is Hard
Part 2: The Biggest Mistakes Marketers Make in Buying Technology
Want to read the paper this discussion is based on?
Click here to get When Markets Buy Technology:Issues, Obstacles, and Solutions
*At the time of this conversation, Atri was Act-On’s CMO.