I’ve recently been talking to senior IT executives and consultants outside the Customer Data Platform filter bubble to understand their views on CDPs. Every conversation adds something new to the picture and I’m not done yet, so I’m sure my conclusions will evolve. But there’s already enough interesting insight to report on what I’ve heard. So here’s an interim report:

1. CDP sounds too good to be true. This came from an executive with decades of experience working with customer data who was unfamiliar with the CDP story. His take was it’s just plain hard to build customer databases and he didn’t see how CDPs could suddenly make it simple. I mentioned new technology but he said his organization has plenty of big data experts so he didn’t think that alone would change the equation.

On reflection, the right answer would have been that CDPs save time because they contain packaged features that must otherwise be built from scratch. Those features include user interfaces that partly automate tasks which otherwise require much skilled manual work (for example, filling out templates that generate scripts, rather than writing scripts directly); prebuilt connectors to source and execution systems; and internal processes such as data transformations and identity management. This is the same advantage that any packaged software has over custom development, and should let IT people see the issue as the same build vs buy decision they’ve made in many other circumstances. Perhaps if it’s presented in that familiar way, they would find it easier to assess CDPs as a plausible option rather than the latest brand of snake oil.

2. CDP is just a data lake. This came from another deeply experienced technician, who said he hasn’t seen a new data warehouse project in years, so there’s no point in comparing CDPs to those. Noted. It’s all data lakes and access tools, he said, and proceeded to label Tamr and similar access tools as CDPs. Again, the right answer probably would have been that true CDPs have many more built-in functions and time-saving features than generic data unification and analysis products. But this was a side issue because his main point was…

3. CDP can’t speed things up because organizational issues, not technology, is what slows them down in the first place. He cited delays waiting for permission from data owners and compliance officers. That seemed a much more important argument. The best I can come up with as a rejoinder is that CDP features let you move quickly once permission is granted. In some cases, the CDP also gives granular control over data use, which in theory makes it less risky for owners to grant access. Delays caused by CDP owners who can’t decide what they want is a slightly different story.  The CDP should reduce those because it can ingest and access data with minimal configuration.  That means fewer decisions are needed in advance because there’s little penalty for changing your mind later.  Of course, data lakes are justified with exactly the same argument.

4. What’s really tough is identity management. This came from a veteran of the traditional customer data management world. I grew up in the same neighborhood and certainly agree that identity management (or customer data integration, as we called it back in the day) is a special skill. The actual context of this discussion was that few in-house IT groups understand identity management, which is why they shouldn’t try to build their own CDP from scratch. I’d say that’s true. I do recognize that IT teams can purchase specialized identity management software but would argue that if they lack the right background, learning those tools will be a long and painful process. CDP vendors have the advantage because they deal with identity management all the time. Indeed since a surprisingly large number of CDPs don’t have built-in identity management features, many CDP vendors themselves rely on those same external identity management products. The difference is they’re frequent, experienced users.

5. CDP isn’t enough because users will always need supporting services. This came from a system integrator whose firm regularly uses a real CDP and recognizes the productivity gains it gives them. When I casually suggested CDP could empower marketers in the same way that marketing automation has empowered them, he drew on his experience as a vendor of those systems and informed me that few users actually do much without calling the vendor for support. I’ll concede the point with some exceptions. His more important observation was that even when companies do have skilled people on staff, they’ll only have one or two – so if the company expert quits or even just goes on vacation, things grind to a halt unless the vendor picks up the load. That’s not really an argument against CDPs but it does mean that CDP vendors shouldn’t over-promise how much marketers will be able to do for themselves. It also reinforces what CDP vendors know but sometimes don’t like to admit even to themselves: professional services and on-going customer support are a very important part of their package.

None of these insights is especially startling. I’m sure CDP vendors who are out selling run into them all the time. But they’re still useful reminders that getting more companies to benefit from CDPs takes more than simply letting them know that CDPs exist. I certainly can see ways to make my own presentations on the topic more effective. And I have some new questions to ask the CDP vendors themselves about how to illustrate the benefits their systems provide.