ZoomInfo: from data graveyards to ROI-driven data projects
April 16, 2024

How ZoomInfo transitioned from data graveyards to ROI-driven data projects

Too often expensive resources and manhours are spent on dashboards no one uses, resulting in zero ROI. Philip Philip Zelitchenko, VP of Data & Analytics at ZoomInfo met the bros to talk about adopting product management principles to ensure data projects have value, and provide an unfiltered peak into ZoomInfo’s data stack and unique tech culture.

Listen on Spotify or Apple Podcasts

Transcript:

Benjamin (00:01.518) All right. Hi, everyone, and welcome back to the Data Engineering Show. We're super fortunate to have Filip Telychenko join us today on the show. He's the Vice President of Data Analytics and Zoom Info. Welcome. So great to have you.

Eldad (00:17.698) So, yeah.

Philip Zelitchenko (00:19.067) Yeah, thanks for having you Benjamin and Nildad. It's nice to meet you both and happy to be here.

Benjamin (00:23.566) Awesome. Cool. Do you want to tell us a bit about yourself, right? Kind of your background, how you got into data, your current role, and just introduce yourself to the audience.

Eldad (00:24.13) Thanks for being.

Philip Zelitchenko (00:35.515) Sure, yeah. So my name is Philip Zelitchenko. I'm the VP of Data and Analytics here at ZoomInfo. My career journey started in the world of stats. Most of my career is in the data science and machine learning world. That's where I built most of my career. And then in the last, I would say, six, seven years, I've started to expand to other areas, so look into the data platform side, which I understood that is a... big dependency for data scientists on the data platform. So it started from MLOps, then expanded to other areas. Then it started looking into data governance and data quality is important. How can we build things on the data science side with understanding the quality of the data? How do we ensure it's at a high quality? From there, it went to the data engineering fronts, because at the end of the day, as a data scientist or an ML engineer, you need to do things in batch or in stream. So it goes into those areas.

And basically, I started exploring. And the last seven years, I'm in the exploration mode. I'm still exploring and learning about platform, product management, data science, and so on. And how do you apply? And I talk about it a lot because I think it's a very good mental model, which I'm a big fan of mental models. How do you apply Marty Cagan's Inspire and Empower frameworks onto data product management and building data products, which I think is crucial because it's

If you look at the world, I think we spent a lot of resources and time on things that go into the graveyard, the Tableau graveyard, the Snowflake graveyard, you define the graveyard you want to look at. And there's a lot of time that was spent on things that in a lot of cases were not needed. And we paid a lot of money on it. So that's the world I live in and what I try to focus on in the last few years.

Benjamin (02:25.966) Nice. We really look forward to hearing more about this today. So at Zoom Info, do you maybe want to give us a high level overview of your data stack? What's the key technology you guys use? What are the data sizes? Just a one minute rundown before we all in the grave.

Eldad (02:42.434) It's all in the graveyard. It's all in the graveyard. It's all in the graveyard. Sorry.

Philip Zelitchenko (02:47.515) Exactly. No, no, yeah, it's a good question. So Zoom Info is a data company. I feel very fortunate to work at a company like this for many reasons. Everyone does data. Our CHRO writes Python. So just to give you an understanding of how technical the teams are, and it's embedded everywhere. So you're not the SME. SMEs are across the board. We have different data teams. And

Philip Zelitchenko (03:16.731) Generally, we split the data teams into two groups. There is my side of the house, which I deal with everything related to corporate. So if you think about how do we make our business more efficient, gathering information from different data sources, both on the go -to -market side, on the product side, and how do we make sure that we're building the right thing moving forward. And then we have all the data teams that support our products that are built on top of data.

And there's a set of leaders in the org that basically support those initiatives. Within my org, we have the enterprise data platform. That data platform is built out of multiple components. We have things that we build. We have things that we buy. And we have all kinds of hybrid solutions that we encounter. And that platform goes from warehouse. We're a warehouse -first company. We utilize Snowflake to.

Philip Zelitchenko (04:13.243) serverless ML ops solutions, so Databricks and some other solutions that we use in parallel, and many things in between. So MWA on AWS, how do we do orchestration using Airflow. We have something similar on GCP. The stack is pretty wide and has a lot of components to it. From the data observability side, we look at Monte Carlo. We use Atlan for data cataloging.

It's a pretty mature, I would say, serverless stack that is more modern than, I would say, most of the companies that I worked at or consulted for, where they're still in different areas, are still trying to figure out what they're doing. So we can go deeply into the different areas here, if you'd like, but I try to give you a quick overview of what we do.

Benjamin (05:01.838) Yeah, it was a great overview. So one thing I'm kind of particularly curious about is you said in the beginning, you're like your data company, you offer at the end kind of data analytics to your customers at a super wide scale, but you also have internal BI and all of these things, right? Are these like two largely separate data stacks or is it all served on the same underlying data infrastructure?

Philip Zelitchenko (05:13.627) Mm -hmm.

Philip Zelitchenko (05:24.443) So I think it's a perspective question. The way I see it is it's a unified stack. At the end of the day, the fact we are, I think we're sort of being a data company and being leaders as a data company, we have the privilege of dealing with a lot of data challenges across the board. And we are working on big initiatives. ZDP is one of them, basically the Zoom in for Data platform that's being led by a few very talented folks that come with a lot of experience of doing these things. And then the question becomes, OK, so we have ZDP. We have our EDP, which is the Enterprise Data Platform. How do we marry those together? And I think the vision is that we take this EDP as being our main platform that we're going to be utilizing and expanding it with EDP capabilities. So for example, if you need this type of tool for this type of use case, for this type of latency, this type of freshness, there's no reason why.

Philip Zelitchenko (06:23.419) EDP shouldn't be just embedded into ZDP. So in the long term, what EDP will become as part of ZDP and all the great work that the team has done to build the different components will be embedded into that great offering that will be utilized for many purposes, both external and internal.

Eldad (06:39.426) The lines are blurred and it's a good thing. It's a good thing.

Philip Zelitchenko (06:47.931) Yeah, I'm a big fan of adversity in general and being Israeli and Russian probably bad marketing, but that's who I am. And I think adversity grows interesting things and we don't have adversity here. And I think we partner very well with all these teams and we work very closely and we help each other out. But I think these different views on how to build things correctly give us the ability to bring to birth outcomes that are much better than most organizations that I worked for in the past. In the past, I've been in other organizations where there wasn't a lot of communication or a lot of adversity, if you'd like, about how to build things correctly. And the outcomes were usually suboptimal versus here. I feel like the fact that we have so many data experts, back to my point about the CHRO writing Python scripts or other people across the org doing data.

It allows us to make sure that the path we're going is the right path and it's a democratic state so people can contribute and make sure that we're not missing anything.

Benjamin (07:51.79) Nice. So let's talk a bit about data as a product, right? And you mentioned it earlier, like this kind of graveyard of components. Tell us a bit more about your thoughts on that, right? Kind of things being built or never being used and so on.

Philip Zelitchenko (08:05.435) Yeah, the way I see the world, at work at least, is that there's people, process, product, and tech stack. People, and there's a reason why I say those in that order, is because I think that's the way I think about the priority around the company and how I think about how we do things. So the people have, if you invest 10 % in the people, you're going to have a return of 50%, 80 % on that investment. You put 10 % in process. you'll probably have 30 % to 40 % return. You put invest in the product, you'll probably have 10 % to 20 % return. You put it in the tech stack, depends on the tech stack. Usually it has almost no return unless you fix the things up top with the people in the process. Because all products have a great prop or value prop, but it almost always fails on the people in the process side. That said, if you think about.

Data products in general. And we can define data products in a sec. Let's call that for now. Data products are basically a presentation of time and effort that was being put by humans in an organization. So if you sit for, and I'll give you the simplest example. Let's talk about a dashboard that you've built. And I see the dashboard as a data product. If it took three data analysts and two data engineers to build something

Philip Zelitchenko (09:33.755) for someone to consume and the Dow or the Mao or the Wow of these data products is zero, that means that you take the salaries of the people that we talked about, multiply it by the amount of hours and you get the amount of dollars that were invested and ROI of zero.

Eldad (09:54.754) There's a lot of effort put into PowerPoint presentations coordination meetings project management Decision -making leadership everything to get that dashboard up and running and be successful Just to get to what you say. So

Philip Zelitchenko (09:54.811) So if you take that.

Philip Zelitchenko (10:10.139) Exactly. So take that phenomena, multiply it by the amount of dashboards in the Tableau graveyard into the tables in the warehouse graveyard, into the ML models that are running or bad jobs that are running. Take that and multiply it and you get a dollar value. That dollar value is going to be very high. And that's something that we ignore because usually we have the fortune to work.

Philip Zelitchenko (10:39.323) at tech companies, which I'm so happy that I was born at this time in history and not 300 years ago where I'm sure I'd be unemployed or not sure what I would be doing. We have that benefit and because we move fast and we try to move forward, things, we don't have a back -view view. We don't do a lot of postmortems. So we continue throwing things behind the back and continue moving forward. But I think what's interesting about it is if you step for a second and look at the back, you understand that something isn't working well in general. And what's not working well is how do you invest the time in the right things and make sure that what you're building is right and is going to work. The same way you don't build products moving away from the data product world to the real product world, you go through a set of validations, you evaluate. There's more rigor about how you invest your time. But for some reason, when we talk about data products, it's sort of treated as free.

And I think that paradigm shift will happen in the next few years, where this will become something of the past. This would be an absurd, the fact that we invest so much time in things that are not being used.

Eldad (11:48.514) I've heard that about PowerPoint presentations and PDF files and I'm still getting those. I saved dashboards as PDFs by the way. So you can actually read it. But I completely, I'm with you on a lot of stuff you're saying. But sometimes, you know, people get religious over dashboards. But in reality, it's just people translating decisions into a nice presentation. Sometimes the purpose of the dashboard is really to be viewed once because of the effort that was put to behind the scenes to get the dashboard up and running, the cleansing, the modeling, the picking of the right stack. So the dashboard is really the least important thing. As you say, it says you move on, you just evolve and dashboards are just, right? Like those points in time where you did a snapshot of your data, you know, your data capabilities.

So, you know, it's okay, create wrong dashboards. As long as your model evolves, as long as your team gets smarter with the data, make faster decisions. And it's hard, it's really hard. So you're right, in many cases, the dashboard becomes the project. And I think that's when you know something is really wrong.

As you said, it's not the dashboard fault, it's the people behind it and the intentions that drive that dashboard. And I've seen some nasty things in my career, but always good intentions. So yes, I contradict myself and our theme here to be really nasty on dashboard and to go to the graveyard, pick them out, kill them again. But we don't want that. We are good with them.

Philip Zelitchenko (13:24.699) Yeah, yeah.

Eldad (13:39.842) Benji, what's your thought?

Benjamin (13:42.35) So one thing I'm curious about Philip is like, when you're talking about data product management, and you're saying, right, like for internal dashboards, for the CEO or whoever kind of, we consistently create things that have no ROI. Now you're at a kind of data product company. So in a sense, for all of the, many of the data projects you're doing, the ROI is easy to measure, right? Like kind of Zoom info is a public company, kind of you earn money, kind of off. at the dashboards and data experiences you create. Like, why is that going better? Cause in a sense, I guess you're advocating for all of the processes you have around taking data experiences to your own customers, also mattering then internally for any organization that kind of have large amounts of data.

Philip Zelitchenko (14:31.643) Yeah, and I think it's a good question. But again, I think our company is unique in many ways. Most companies in the world are not data companies. And most companies, the data function that they have is a corporate data function that serves the internal product. In some cases, you'll have some sprouts of data that is ingested in different areas of a product. But most companies in the world are in the world where the data function mainly serves internal stakeholders. And the reason like any other company, that function is something that I think needs to be stabilized and built in the right way to make sure that you invest the time of these resources in the right place. And so back to your question of why is it, I think your question was why is it so important to me? Because at the end of the day, the fact that our product team works and thinks about things as products is very dependent on the fact that

Philip Zelitchenko (15:29.435) It is a product and engineering team versus data analytics teams today are not managed as product teams. Most data analytics teams in companies that I've seen that are internal data analytics teams, they don't have a product manager that thinks about it. Mostly it's business stakeholder to engineer. That's the first relationship that you get. And that's, I think, one of the main reasons that that graveyard that we've talked about is so big is because we don't think about what we build as products in those use cases.

Philip Zelitchenko (15:59.003) We think about them as stopgap solutions. And if you look at the most of these stopgap solutions, what happens a lot of time is that we recycle things that are in the graveyard, but we are not even aware of it. And the reason why is because the requirements, thinking about how it's going to be utilized, how it's going to drive value, all these questions are usually being run by the business. And unfortunately, business people, they are amazing at a lot of things, but they're not product managers. They're not thinking about, OK, how do I build an experience? For my internal team to ensure that they can utilize data in a smart way that will help to drive outcomes, that will help drive ROI, that will help us upsell or cross -sell our customers or reduce turn on our customers or save costs around the org. These things are not part of their day -to -day thinking. It's mostly a transactional thing that they do as a side job. And usually it looks like a side job. That's why the graveyard is so big.

Benjamin (16:56.27) But calculating like your data ROI does seem much easier in a company like data product company, right? Cause like you sell the product for X amounts of dollars. Like it's easy to calculate this. If I give a dashboard to some executive and kind of she makes a better decision because of that becomes much, much harder to measure this. So how do you think that kind of transfers, right? Kind of from the world you have at zoom info to maybe some company where it's mainly internal.

Philip Zelitchenko (17:26.427) And I think that's a great question. That's part of what you do when you write a DPRD, when you write data product requirements document, you think about how do you measure the impact of what you do. And in a lot of cases, you don't. What happens in most cases, in most companies that I've worked for, have you heard of the HIPPO?

Eldad (17:38.498) Thank you.

Benjamin (17:42.958) I haven't heard of the hippo, no.

Philip Zelitchenko (17:44.603) Okay, so the HIPPO stands for the Highest Pending Person Opinion. That's HIPPO. And usually the HIPPO rules. In those companies, the HIPPO is the way things are decided on. Don't measure the HIPPO because the HIPPO is the HIPPO. And what happens is, if you don't put any measurements around the HIPPO, and you don't, and forget about the HIPPO itself, the HIPPO is just a representation of it's, yeah.

Benjamin (18:07.47) Measured a hippo, measured a hippo.

Eldad (18:09.73) Hippo!

Philip Zelitchenko (18:12.283) So the symptom, this is just a symptom of what I'm trying to say is when you work on a product, we're trying to release a product, you're going to think about the metrics, how you're going to measure the impact. You're going to think about maybe I'll run an A -B test, right? Maybe I'll see if I'm building a way to improve my sellers, I'm going to run an A -B test between sellers that can use my insights or not and evaluate that. These practices have never been something that the go -to -market teams or the business teams in companies thought about. Because they try to move fast. And moving fast meaning creating a larger graveyard with less thoughts around, what is the framework to do this? Instead of doing 50 projects that are trying to micro -optimize each step here, is there a framework we can build that will help run these more efficiently, but also will be able to measure them, measure the impact of them, and will help us make sure that we're going the right direction?

Benjamin (19:03.918) So this role, you would basically embrace the kind of flows and processes you have at these data product companies kind of much more widely internally as well in organizations that aren't first and foremost data product companies. Like to me, that makes sense.

Eldad (19:14.082) By the way, there are many organizations that will never be data first because they're just selling something else and they will always have a different exposure to data. And most importantly, from a cultural perspective, those companies learn to make decisions.

Eldad (19:42.658) almost completely with humans. So when they go and sell a car, it's the agent that decides the discount and how based on the, I don't know how much the customer blinks. And that's hard. And that's kind of goes way back. But when you're building a data company, you have, you remove so many limitations and you can rethink a lot of the go -to market.

Philip Zelitchenko (19:58.235) Okay.

Eldad (20:11.362) that you would apply, right? Like so many things, little things that you've mentioned when you talked, like, yes, you just change the product you're selling. And of course, anyone, you know, anyone in the services business would say, you can't just have everyone being in the service business. Someone needs to drive those people to work. And, but I think, yes, looking forward and how information workers transition.

Benjamin (20:33.39) Okay.

Eldad (20:41.314) from being consumers to making decisions which they're not with dashboard and this is what you're saying having a dashboard is it's not a trophy okay it's like a spreadsheet it's nothing more it's like whatever um but transitioning information worker it's basically your same information worker got it wrong and this all the stack we've did to serve decision makers right like what is bi what is self -serve?

Eldad (21:09.826) It's like a thousand different ways of doing the same thing, making less mistakes. And we're getting to square one. So data companies and data is a product, is the future across many industries and we're seeing it. So you better work or plan or be somewhere in that ecosystem. What else do you think will happen?

Eldad (21:36.002) As we move forward as we'll have less interfaces to do with right? I mean what you're saying is there is no looker interface in a few years from now Nobody's doing that. So what do you think will happen? How will you sell your data products? Dashboards last for 20 years. Believe me. I know

Benjamin (21:36.686) Remind, remind me, three years is look at that.

Philip Zelitchenko (21:56.827) I think, so I agree with a lot of what you said. I think the big thing that I think will happen is dashboards currently are transactional products that are not meant to stay in the form that we think about them. So that takes me back to the Dow, the Mao, the Wow. You look at these things on these metrics, on these assets, and you see that they're not meant to stay.

Eldad (22:06.178) But what if your AI call pilot generates that dashboard which

Philip Zelitchenko (22:25.115) because it always declines with time. Well, it...

Eldad (22:32.29) between us, right? Like this is kind of first feature for a co -pilot. Isn't that just yet an animated PowerPoint with the right data? So the dashboard itself, as we said, is not the point. It's the journey, the model, the cleansing, everything that happened to get there, but then generating the dashboard is free. It's like a PowerPoint. You get it for free, but it's everything else that matters. So.

Philip Zelitchenko (22:52.571) That's a good question. And I think that what is the time horizon we're looking at? Are we looking at 50 years from today or five years from today?

Eldad (22:59.426) Will you change your perspective on dashboards? And that's my question. Will you change your perspective on dashboards when they become yet another file format? So on Wired, unfortunately, it's 12 months in reality, I guess 15 years.

Philip Zelitchenko (23:22.331)Yeah. Yeah. And if you think Elon Musk would say it's going to be ready by end of year, right? So I think at the end of the day, I think the timeline is much longer than that. And I think in the meantime, what will happen is instead of creating tens or hundreds of dashboards that are going to be consumed by people at the organization.

Philip Zelitchenko (23:51.707) Yeah, no worries. So I think what will happen is that in the short, medium term, we'll move from dashboards to data apps, which I think is going to be the new world. Because when you think of building a data app, you're going to start thinking about the experience of the people who are going to access the data app. And now it's getting closer to a product rather than a transactional object that is there to serve you for 30 minutes for a meeting. And when you start thinking about it, you will start thinking of frameworks.

Eldad (24:18.562) and I'm going to be talking about that in a minute. Thank you.

Philip Zelitchenko (24:38.524) So that will be a centralized place, one central place that people can consume. But that's not the only one, because from an activation perspective, some of the data will flow into a data app. But some of the information will flow into your systems of engagement, where you are trying to drive a certain behavior, where there it's going to be not just another field in Salesforce or another field in whatever system you'd like, but it's going to be driving a workflow in that experience that will drive that workflow for the

Philip Zelitchenko (25:06.748) for online practitioners using those systems of engagement. And I think the activity.

Benjamin (25:08.174) What's the, I never heard the term system of engagement. Like what's the actual like textbook definition on that for someone who doesn't know.

Eldad (25:10.882) Absolutely. This is.

Philip Zelitchenko (25:18.588) So there's two systems that usually people talk to about, system of record and system of engagement. System of record is basically a place where you maintain information. So if you think about Salesforce today, removal of the Salesforce marketplace and all the things that connect to it, it is a system of record. People go there and put in notes or put in details and so forth. A system of engagement is a system where you log in and you engage with it.

Philip Zelitchenko (25:47.324) to make actions. So it's not just a place where you drop data in, it's a place where you activate different initiatives or you send outreach as an email approach that SDRs use to send out emails in bulk, define workflow. It basically helps automate a lot of the work. Slack is a system of engagement exactly in some sense. Some things can be both, right? So it depends on what basically the product is.

Eldad (26:05.282) Slack.

Philip Zelitchenko (26:16.06) but usually refers to some product, not data product, product, that has qualities of either writing, or writing and reading, or writing, reading, and acting upon whatever is happening in that system.

Eldad (26:29.666) And it's smart, you know, Salesforce, being Salesforce, being smart and being a great company. Like you just described like outladed for everyone, right? Like build a system of record and then we translated it into a system of engagement. So they acquired Slack, they acquired Tableau. They give any way to engage data through the dashboard. Um, that didn't go as well as planned and they got Slack.

Eldad (26:58.594) to have the other kind of engagement, which could they got really well, way beyond what they expected up to the point where this is kind of becoming their operating system of engagement. Thanks for playing us like those two things are crispy for us.

Philip Zelitchenko (27:16.892) Yeah, and I would also add that basically if you think about products in general, some of them are a pool, some of them are a pool and like reactive, proactive, pull and push, whatever you want to call it. I think the data apps will become a pool method where you go and you consume. And the activation layer or the system engagement layer would be the push where you set up automations that are going to be assisting you to help productivity across the different functions in your org.

Philip Zelitchenko (27:45.596) to make sure that you're doing your job in a good way. Because at the end of the day, with all of the things that we can do as a single front -line practitioner at a company, from a seller to a marketing person to a CSM, you can't really do your job in an amazing way without the assistance of some automated processing in the background. Because currently what happens is the method is you call someone, you write notes, you call someone, you write notes, you call someone, you write notes. That is not an effective operating model.

Philip Zelitchenko (28:15.228) And it's probably the productivity, if we had a measure on productivity of human beings and companies, that productivity metric would be pretty low because of of. Yeah, because low interest money is free, so you can throw bodies at any problem and then that's how you solve it in a world where interest is high. You need to find ways to be more creative in some sense.

Eldad (28:26.114) But it worked well with low interest. It worked well with low interest.

Eldad (28:42.594) Exactly. Good to be living in high interest rate times.

Philip Zelitchenko (28:48.572) Yeah, rise efficiency.

Philip Zelitchenko (28:56.316) The Industrial Revolution would probably come much faster in a world where we had a lot of high interest times.

Eldad (29:11.458) Benjamin, I can see you're circulating some thoughts with yourself. So feel free to share it with us.

Benjamin (29:15.822) And I'm still like...

Benjamin (29:20.494) No, so I'm still kind of trying to, to wrap my head around kind of your overall perspective on, on kind of the, these like data pipelines and so on, Philip, right. So first of all, I need to understand what system of engagements are and figure out how this fits in my mental model. I think my question kind of in the bigger scheme is right. Like when you're talking about, okay, people writing notes into Salesforce, kind of keeping track of all of their interactions with customers and so on, and then needing more efficient data products and data pipelines in order to become more effective.

Does this to you also then fall under projects actually owned by the data team within the company where you want to embrace all of this kind of then product workflow around figuring out ROI, kind of figuring out kind of requirements and so on, or is this more like, okay, there's going to be specific products emerging around this that actually make this easier? Like, do you feel like this kind of business function will be built more in -house in the future by data teams? Because it's very specific to the business or people will just buy it from like Salesforce 2 .0.

Philip Zelitchenko (30:31.388) It's a good question. I think it'll be probably a hybrid. There's going to be more tools. And we'll have a new infographic coming out every month showing how populated the whole industry is. And these tools will solve some use cases. But the biggest problem, or one of the big problems, is that as these set of tools continue to grow, the more discrepancy you have in your operating model, for personas that are working on a certain problem. At the end of the day, the number of tools per FLP, per frontline practitioner, has grown, I don't know, 300x over the past 10 years. So when I use, not me, but on an average seller used to sell 20 years ago, they had one system. Today they have 40. And that's true not just for a seller. It's true for an SDR, an MDR, an AE, marketing manager, a data engineer, a software engineer. You choose. Yeah. Yeah.

Eldad (31:35.746) phones, your phone suddenly, you can download as many apps as you want to them. So yeah, I mean, it's interesting to see how that will end and how far that will actually go because it was driving us really nicely, right? All of us kind of having that tool productivity mindset going from using one SAP with 50 apps in it with negative productivity to having that interconnected, well -behaved ecosystem with humans to connect the dots, which I think is much better than a glued single tag stack. But I don't know, right? Times change, things look at snowflake now, right? Like I remember people used to laugh at Oracle for trying to do more than just building a database.

So now it's okay to have a CRM. It's back okay to sell CRM with your database. So it's fashion, you know, it goes in cycles. You never know. You just need to focus, as you said, on great products, finesse and have teams that love the products they build and iterate fast, especially if you're in data. No egos. It's not needed because mistakes are almost practically for free.

Philip Zelitchenko (32:53.276) Yeah, I agree. Yeah.

Eldad (33:01.794) And so you don't need that ego in the room to protect the project, to have defense balance, nothing. No, it's like a query. It's like a model. It's a right. I think listening to you at the beginning, that is what I took. It's like, it gives me flexibility and freedom. So I can approach my team. I can lead my team differently. Maybe we can all build better stuff. Boom!

Benjamin (33:31.822) So maybe pivoting a bit and then kind of also generative AI, right? Like obviously kind of that's on everyone's mind. And I did want to kind of bring it up today because I think you have a really interesting perspective on that because one, you're using data infrastructure so heavily, right? And like systems like Snowflake have Cortex now and all of these generative AI features to deal better with semi -structured data and so on. At the same time, you're also thinking a lot about...

How do paying customers interact with data? Because this is what your business does in the end. Where do you see generative AI fit in? Both in terms of the internal data stack as a company, but then also in terms of how customers and users interact with data as a data product.

Philip Zelitchenko (34:19.868) It's a good question. So I'll split it into two. I think let's talk about ZoomInfo as a company, because I think there is some exciting work that is being done. We're working on releasing something we call Co -Pilot. ZoomInfo Co -Pilot is going to be basically a way to interact with your data and act on it in a more of a natural language processing way. And I think there's some exciting work that is being done currently in the R &D and product org that will be exciting for a lot of our customers in a few months. And in that world, basically, the approach of write versus writing or reading, all that will be a bit easier, or I think much more easier from a productivity standpoint. If you think about Microsoft Copilot, I think there is research showing 15 % to 20 % to 25 % improvement in productivity of writing code.

I think a similar thing is coming from ZoomInfo for our ICP, our ideal customer profile. So our AEs, our SDRs, MDRs, they're going to have a very high benefit from interacting with a co -pilot that is going to basically help automate a lot of the things that currently they spend a lot of time doing. And there's some interesting research coming both from Forster and Gardner about how much time on average people spend on maintaining tasks that can be basically automated using GenNI. So I think there's great work that's coming from there. On the other side, I think for the.

Eldad (35:55.586) Oh man, what's gonna happen when everyone stops moving stuff around and start thinking? Because you don't need to move stuff around anymore.

Benjamin (36:02.67) So now that Eldad interrupted you already, I might as well follow up with another question. Having experience now taking these products, at least on their way to production, what's actually the hardest part? What's the biggest engineering challenges you have there? Because I think a year ago, everyone was just talking about these LLM companies and, oh, which LLM will win. That debate is kind of...

Philip Zelitchenko (36:04.316) Yeah, I think it's exciting. I agree with you.

Eldad (36:08.418) Mmm!

Benjamin (36:32.174) Over like as someone taking such a data product to production now, like what's the hard engineering about it?

Philip Zelitchenko (36:39.708) I think there's a few challenges there. I'm not sure I'm the right person to answer that question here, just because that's not my realm of responsibility. But I think, in general, that if I had to classify it into categories, I would say A, which is something that we're all probably aware of, the hallucination problems that are happening, how do you solve them, and B, I think, scale. So I'd say these are the two things. And the third one, which is hidden under scale, is cost. So combination of those three factors, but again, I wouldn't call myself the expert here on those areas.

Benjamin (37:11.022) Sounds good. So then kind of backtracking to my original question around kind of these, like you wanted to split your answer in two and talk about the second dimension now as well.

Philip Zelitchenko (37:21.98) Yeah, I think the other piece is how do we not make Gen .AI the new graveyard pool for similar to Snowflake and Tableau and other areas, right? Because at the end of the day,

Benjamin (37:31.854) The data engineering show season 55.

Eldad (37:31.874) You know what's more important? How do we make sure dashboards don't become the best thing that everyone does because everything else is just too expensive and just people go and say, let's just create a dashboard and run it for a few dollars and that's it.

Benjamin (37:47.982) Yeah. 20 years from now, we'll be sitting here again and Philip, you'll tell us about the graveyard of generative AI kind of products you've seen.

Eldad (37:55.938) I'm sorry.

Philip Zelitchenko (37:58.556) It's already being populated by bodies of things that are trying to be built. Every time I see an announcement of Microsoft or OpenAI, I basically see a whole industry just getting wiped. It's like a Marvel movie where basically someone...

Eldad (38:00.546) Who's?

Benjamin (38:03.598) It's filling up.

Eldad (38:05.634) of lost souls.

Eldad (38:18.306) It's crazy.

Philip Zelitchenko (38:25.5) snaps the fingers, and a third of the population disappears. But joking aside, I think in a similar sense, what will happen is that now there's this hype around what can generative AI do. And I think the Kruger effect, which I don't know if you guys heard of it, but you probably have, basically a very famous curve where there's the first hype, and then it goes down, and then it continues growing in a more, I would say, in a less steep way. And what happens in those areas, I think we're still on the first hype cycle where people are saying, what is your AI strategy? How are you going to solve world peace with AI? And all of the buzzwords around that. And I think soon enough, the tide will go down and we'll see who's swimming without any underwear.

These people walk out of the room and we'll stay with things that are really beneficial and help us do things better. So I think that would be the... Exactly. So and we're also...

Eldad (39:29.698) I don't want to compete. I don't want to compete with you guys on the data product on your domain. But I love, I love the, I love the attitude. Like really I love everyone who, every engineer who love what they did and love their peers and wake up every morning and love doing it. So thank you for.

Being an inspiration on that for sure. And there's the graveyard. Yes, there is that slide. And, and in our domain, it's changing actually much faster because there are no constraints. So yes, we might wake up in a few days, weeks or months. And that will be really a restart for, for, for data stack. And when that happened, it's good. That's what we do. But you're still in the data warehouse always, always we need a data warehouse.

Philip Zelitchenko (40:24.156) Yeah, no, I agree.

Eldad (40:29.346) Other than that, I don't know. Other than that, I don't know.

Philip Zelitchenko (40:32.54) I agree 100%. And again, what I'm trying to say is that I'm not trying to aim for a world where there's no graveyard. The graveyard is important. I'm just saying that I think we currently don't measure how big the graveyard is or what is the ratio between people who are alive versus people who are dead. Like humanity is trying to improve life expectancy, lifespan, health span, and how we're doing things better. I think in the same way, we need to be more thoughtful about what we build.

And how do we ensure that the ratio of things that go to the graveyard versus stay in live are being thought through? And the way to do it is to start understanding what exactly, what is in that graveyard and why is it there? How do we ensure to reduce the amount of things that go into the graveyard?

Benjamin (41:15.534) I think that was the most inspirational outro we ever had on this show, Philip. That was great. It was so good having you on today. Really, like I learned a lot. It was so good hearing your perspectives. Thanks a bunch. Any closing words from you other than your perfect words just now.

Philip Zelitchenko (41:38.268) No, just thank you again for hosting me. And again, I think as Eldad mentioned, which I want to echo, no one really knows what's right or wrong. We can be, we're almost around us. There's a lot of smart people. And I think remembering that and just coming open to conversation to hear other thoughts and argue and make sure the right decision are being made, I think that's the key for success of all of us. So yeah.

Benjamin (42:06.862) Thank you so much, Philip. Awesome. Cool.

Read all the posts

Intrigued? Want to read some more?