In this episode of Experiencing Data, I chat with Irina Malkova who is the VP of AI Engineering and VP of Data and Analytics for Tech and Product at Salesforce. Irina shares how her teams are reinventing internal analytics, combining classic product data work with cutting-edge AI engineering, and her recent post on LinkedIn titled “AI adoption moves at the speed of user trust,” having a strong design-centered perspective, inspires today’s episode. (I even quoted her on this in a couple recent product design conference talks I gave!) In today’s drop, Irina shares how they’re enabling analytical insights at Salesforce via a Slack-based AI agent, how they have changed their AI and engineering org structures (and why), the bad advice they got on organizing their data product teams, and more. This is a great episode for senior data product and AI executives managing complex orgs and technology environments who want to see how Salesforce is scaling AI for smarter, faster decisions.
Highlights/ Skip to:
- Role and Responsibilities at Salesforce (00:54)
- Shifting from siloed to centralized tech while maintaining strong business ties (7:07)
- Challenges in AI and Data Product Management (9:04)
- Building Trust and Adoption in AI Solutions (17:11)
- How AI demands thoughtful implementation (24:31)
- Understanding ROI in AI Projects (26:00)
- Building Trust in AI Applications (28:12)
- The Role of UX in AI Adoption (31:50)
- The Importance of Engineering in Data Teams (38:53)
- Irina’s Excitement for the Future of Data (45:56)
Quotes from Today’s Episode
- "I think this change in nature of analytics products from being outside of the flow of work to being in the flow of work. So fundamentally, in my example, with going from five dashboards to a Slack app, I had no idea what people did with my five dashboards. I saw them. I maybe even would see some kind of filters interacting if I really double down my instrumentation, but that is it, right? I don't know what they're doing with the dashboards. Whereas now I'm in the flow of their actual button clicks and operating systems where they're creating those [pricing] quotes. So, first of all, I can see whether the actual quotes were created as a result of my conversation. I can actually trace the outcome to the quotes being created." Irina (21:23)
- “[AI] should be very helpful, very open, show their work, exactly the lineage to where the numbers came from, give the name of a human data scientist that can help if this is, for some reason, looking fishy, and that will continue until the user is comfortable. And at that point, the user will probably just require them first to be less verbose, but still require them to check in with the user. And then it will be months until the user doesn't even want to check in because they trust this thing so much. And that would be the moment when you're ready for an autonomous AI, but not until then." Irina (31:06)
- “I sometimes look at our adoption dashboards for the AI applications that we're building, and now folks typically celebrate the things that have high return rate, but also the things that just have high usage and low return rate. And I am very terrified of those things because if I see a lot of folks coming in and never coming back to an AI app, I see hurt people who have a need, right? So, they stopped whatever they were doing, and they tried this AI app that you were offering to them, and then they didn't like it to the point where they decided to never come back. And that, to me, is dramatically worse than never losing that app at all because it's poisoning the well for any future AI innovation." Irina (34:50)
- “I think every data team out there has a potential to be the Scale AI for their organization, and even more valuable, possibly. Because we truly own the most important asset that AI can ever have, which is data.” Irina (46:25)
Links
Transcript
Irina Malkova: Hi, this is Irina Malkova VP of AI engineering and data analytics for tech and product at Salesforce, and you are listening to experiencing data with Brian O'Neill.
You are now experiencing data with Brian O'Neill. Experiencing data explores how product managers, analytics leaders, data scientists, and executives are looking at design and user experience as a way to make their custom enterprise data products and analytics applications more useful, usable, and valuable.
And now here's your host, the founder and principle of designing for analytics. Brian O'Neill.
Welcome back to Experiencing Data. This is Brian O'Neill. Today I have my friend Irina Malkova on the line from Salesforce. How are you? I'm glad we're, we're doing this finally. This is exciting.
I am glad we're doing this.
Brian O'Neill: So you are VP of ai, engineering and data and analytics for the tech and product group at Salesforce, correct?
Irina Malkova: Yes, that's correct. What the
Brian O'Neill: heck does that mean?
Let's start there. So
Irina Malkova: glad you asked, so glad you asked. So I think I have one of the fun, most fun roles in data analytics out there. I actually run two separate teams. And I love that around both of them because I think there's a lot of cohesion in a IH. But, uh, one of them is a classic data analytics team supporting our tech and product organization here at Salesforce.
So Salesforce has a lot of software that we're building. Um, we have thousands of features, hundreds of SKUs. Uh, all of that needs product analytics. So that's essentially what my team does. So we own product data. Within Salesforce, we help produce it, we help curate it, and then we also do standard product analytics on it.
Like how do you, you make it useful for Go to Market, how do you drive, uh, drive less attrition with it? And then how, of course you use it to build better products. That's half of my team. The other half is a more recent in development. It's our internal AI engineering team. For data analytics organization.
So their job of that team is to take us to the next level of what data analytics can be for the company with ai. So we already have done a lot of work in that space before the recent explosion with foundational models by focusing on the classic amount, so the, uh, quantitative predictive models, attrition, prediction, forecasting, things like that.
So I was running an a amount. Applications team, uh, between 2020 and 2023, and we were building a lot of forecasting apps, attrition, et cetera, for Salesforce. So that team recently evolved into a bigger charter that now uses AI to completely reimagine the way we do analytical experiences at Salesforce.
So now instead of just using classic ml, we are now experimenting with building conversational access, uh, to analytics and insights using AI right in the flow of work. So you can imagine a Slack application. Salesforce on Slack. My favorite collaboration tool. Where, uh, instead of taking, talking to a human analyst, you can talk to an AI that sits right there in a Slack channel.
And this AI can answer some of your analytics questions like, Hey, I don't understand. Why is my account adoption going down? Can you help me? What are the drivers of that? So that's what my AI engineering team is doing. And, um, uh, having both. Is an amazing adventure because I can see both the business needs, the questions that business still is asking and the dashboards that they still want, and then the future of how those business needs can be addressed as we build our AI muscle.
Brian O'Neill: Got it. Got it. So most of the work is in your, your users are other Salesforce employees, so this is primarily internal work across both.
Irina Malkova: Yes. Yeah, thank you. Should have said that. So I'm part of the chief uh, data officer organization. Okay. And our customers are internal. We work closer and closer with the producers of the data for the external customers, just because those threads are emerging.
But our main focus is internal needs of our employees. Yes.
Brian O'Neill: So I'm curious how, like you, you guys were dabbling with or fully invested or somewhere in between with applying, you know, the product operating model or data product management as, as a, a competency in the org and, we'll, we'll get into that in a second, or maybe we'll get into it right now when I ask this, but who's deciding what types of AI work your team is doing?
'cause you know, if you're leading ai, it's a solution method. We're leading with the solution method. So I'm just curious like who decides that this should get love right now, that this problem should get love versus that one? Is there a product counterpart to you or is that all the AI engineering people or the ones that decide and prioritize requests for help, whatever that looks like.
Talk to me about that.
Irina Malkova: That is a fantastic question. So we are still a product organization and our product managers and I, I am in my head, I'm putting that in parenthesis right now because I think there's a lot to double click on, on the role of product management and data. But our product managers set in the.
Business facing functions. So the decisions on what to build are ultimately, uh, done by my data analytics team, supporting tech and product for tech and product. And similarly, I have peers, VPs, who similarly have data analytics for, for example, for customer success and data analytics for sales. And those are the folks that decide what to build.
AI engineering function is essentially an engineering technical implementation partner. So under the hood, folks in AI engineering are engineering managers. Working directly with the business function. So I have somebody who supports me in my own role, in my other head, um, supporting data analytics, product managers for tech and product.
And then I also have folks doing AI engineering for, for example, for customer success and sales folks, sales data, product managers. The differences that that function for us is centralized, and the reason we did that is to elevate the role of engineering versus the role of product to make sure that.
Engineering managers for AI engineering have enough support there, enough visibility and organization, enough seniority for that we bring, we brought them together, uh, and centralize them so they can enjoy that, that power and visibility and that, that has been key because that this function needs to transform quickly, which requires senior leaders with senior access to be able to make that happen.
Brian O'Neill: Was there a before time or this, this organization is new and it, it has always been where it is now because it sounded like it changed.
Irina Malkova: Let me share the full timeline of our adventures in our design of data Salesforce. So we used to be semi centralized where tech product had a data analytics and AI function.
And then sales had data analytics and AI function success, head data analytics and AI function, marketing head, et cetera. So you get my drift. And uh, we, uh, were brought together about two and a half years ago, but the first time under the very first chief data analytics officer. So at that point, all teams came together and we decided to keep the business orientation intact.
Outside of the ML AI engineering function, because it felt like MLI engineering folks, they were so, there were so few of them. They were so scattered across all the different functions that it was hard for them to keep up with everything that was, they built, built everything that was asked of them. Keep up with all of the AI developments, understand where the puck is going with, uh, analytics, becoming part of software, et cetera.
So we centralized them and centralizing them, allowed us to have enough. Uh, scale to essentially bring in some senior leaders to drive that team. Yeah. So that's essentially the only team that centralized the rest is still within business facing pillars.
Brian O'Neill: Got it. So like in the sales department, did you say there's like, there's a data product manager in the sales department that would be your business sponsor for an AI project that needs engineering support?
Irina Malkova: Exactly.
Brian O'Neill: Yeah.
Irina Malkova: Yeah. And we, we run agile where the team is defined across the physical organizational team. So the, uh, folks on my engineering team, they would be part of, part of Scrum team. In our scrum management tool reporting to the pm who drives that on the, uh, business side? Business facing side? Yeah.
Brian O'Neill: How is that working? The scrum? You know, I, I've heard a lot of data science people talk to me that you really can't, especially with AI stuff and model development, like this whole idea of doing iterative two week. Two week development cycles is not like, you're not really gonna have a small version of a finished thing in two weeks.
Like you could still be an experimentation just to see can we even build a model that will do anything, give any lift or any predictive power, whatever it may be. Do you disagree with that or you, are you finding that you guys can actually develop potentially shippable software on a, whatever your cadence looks like
Irina Malkova: it is.
Uh, very complex question I have a lot of opinion on. I completely agree with the sentiment that the linear reality of, oh, hey, I put in some effort. I got out some output. Is gone. And I think the entire, in software development industry, including US data folks is struggling with it because in the classical paradigm we are used to doing a little bit of work, getting a little bit of value back, and then repeating that until the end of time that predictability being disrupted is not new.
ML has already showed us that that was the case. Even when I was running the ML team working with classic models like forecasting for example. We had that problem. You don't really know how the experiment will turn out and if actually with existing data, you actually can achieve that accuracy of the forecast that you need to achieve for this to be useful to your users.
So I think what we're experiencing right now in the industry is the hundred x that. 'cause AI is even less predictable than ML has ever has ever been. I compare that to a silk horses line. I don't know if you ever heard that metaphor, but Yeah. That's essentially like when, yeah, when you, uh, I used to make all my clothes because I grew up in the nineties and Soviet Union, so we made everything so with line and you can just like as much effort as you put in, you get it back.
You get the result back with silk, you can put a lot of effort and it's still gonna look bad. So I think that's what we're experiencing and, uh, data people are not alone. I think all software engineers right now who are trying to build with AI are struggling with the same thing. So it's, it's, you can put a lot of effort, a lot of sprints, a lot of IG stories still get nothing back, so it's real, however.
I think that keeping predictability in this shifting landscape is even more important. It's just harder. And it's really on data, on the PMs and on the engineering managers to try to figure out how do you break down the complexity of developing a model, an AI solution that works into something that can be measurable on the way, right.
So it's, it's just much harder to form the sprint, but we must. It really comes down to being very intentional and very affluent about your experimentation strategy, about why are you trying, the things you're trying, what are you expecting to see? What kind of hypothesis are you testing? What have worked for other teams, doing a lot of research, et cetera.
So I think it's, it's very real. We, we shouldn't be surprised because look at what pre-training. Go through. My brother is a, a pre-training engineer at, uh, DeepMind working on long context. So somebody, he has to write a strategy for every single run of the model. It has to be very intentional because otherwise they will lose millions of dollars.
So it's kind of like that with anything we build with AI these days, it just takes much more intention and much more strategy. And um, that brings me back to the importance of product management. Because that, that's exactly what product management has always been for and it has never been more important than right now.
Brian O'Neill: And so tell me about your product management colleagues then that are requesting, you know, AI solutions here. Are they mostly coming out of data roles and have upskilled into product managers, or are they software PMs that are upskilling into data? Like what do they look like? How, how are they working with your teams?
Are they knowledgeable enough to understand what they're asking for? You know, particularly if you guys are really a delivery team under underneath them, well, sort of underneath them, but
Irina Malkova: yeah, we really have a chain of product managers and uh, it's how it works today. And I think data teams can probably relate.
I don't love it, but I don't completely see the way around it. But essentially there's usually a product manager in the business business. So, for example, for, we recently released an analytical app for our consumption sellers to quote faster. So selling a consumption product. That that has a lot of difficult features is very, very difficult.
As a seller, you need to understand not only which of those features you're charging for customers will use, but you also have to forecast how much of those features customers would need in the quarter to correctly assess how much to sell. And, uh, if you assess correctly, you either gonna under generate revenue and not get your bonus.
Or you're gonna oversell to the customer. And then customer is sitting there with all this unutilized capacity and they're very sad. So quoting correctly on the consumption product is very difficult. And um, uh, we used to have consumption sellers go to five different dashboards. That were the most beautiful dashboards you have ever seen, but they had a lot of numbers on them and it was very difficult.
If you're a consumption seller, you're, you're here to sell, you're here not to stare at five dashboards. So we just deployed an app in, in essentially slack that where you can just ask. What this, what kind of quote this customer needs. And this app at, in the background looks at those exact same five dashboards.
There's no new data, same exact five dashboards. There's just a semantic layer and a knowledge graph on top that helps us translate that to what the human analyst would say. Um, so, so that, that's an app, the example of an network we're building. So to build this app, we had to both work with the product manager in the business.
Who understood that consumption seller process. And I had a product manager on my side who understood the data science of it. She understood AI enough and she, she understood the data really, really, really well because her team built those five dashboards before, so they worked as a team. So, uh, we actually had a third, third product manager in there.
There was a product manager of the actual. Internal technology where that was all deployed. 'cause we have a separate business technology team that runs our Slack instance. You have to work with them as well. So now we have a third in our party. See, but that's usually how it works. Yeah.
Brian O'Neill: So that second PM is part of AI engineering.
Irina Malkova: She's part of my business aligned pillar. So it's part of my, the first team I was describing data and analytics for tech and product.
Brian O'Neill: Oh, I see. Okay. So you have a, a. Several of those, or a handful of those that often pair with the AI engineering team.
Irina Malkova: Exactly, yeah. This is the PM leader to the AI engineering engineering manager.
Yes.
Brian O'Neill: I see. So I'm, I'm curious then the, the, is the value piece and the outcomes and benefits part, is that really on the shoulders of the PM to get Right. And it's kind of your, your, that's not your team's responsibility. Like if you're building the wrong thing, for example, or. You know, let's say the consumption product, like yeah, I can ask a question, but now I want to do, now I wanna reverse engineer the answer that I got.
'cause I don't know how you came up with it. 'cause I don't have access to the data. So now they're like kind of questioning like how much to sell. And then maybe they stop using, I'm just making this up. But now you can have like a trust and, and you literally said this by the way, you quote, I am quoting you this LinkedIn post AI adoption moves at the speed of user trust.
I actually put this in a talk I gave a couple weeks ago in, in Atlanta.
Irina Malkova: Wow. I love it.
Brian O'Neill: I thought this was was a great quote. Talk. Let's talk about that actually. 'cause that's really the heart of the question here is like, how do you. Get through the trust barrier and the adoption barrier. Is that on the AI engineering team or is it on the product management team?
Like how do you think about that? Like, are people gonna use this? Are they gonna trust it? Are they ready for this? You know?
Irina Malkova: Yeah. That is 1000% on the product management team and so I definitely would not ask my engineering manager to, to think about that because. If there is one clarity that product product model gave me is that there needs to be this dialogue and creative tension between technology and what we can build and then the value of it, which is what we must build.
It is very important to separate the two because all the bad things always happen if only one is present. So that I, I'm completely clear. That should be on the product side. We, however, uh, have a lot of PMs, just like I mentioned, and I think a lot of folks are experiencing that. So my only. It's a, so there is a fragmented ownership, right?
Like which PM in the system that I described owns the final outcome that users actually are loving this app and they're actually getting value out of it. Is it the PM on the business side? Who understands the consumption seller process? Is it PM on my side? Who, uh, in a data analytics organization who understands ai?
Is it the PM on the, uh, that owns our entire Slack instance? Who, which one is it? It's a difficult question. I think the only solution I see right now is uh, culture really. So it's very important that all three of those folks have enough of a relationship and enough of a focus on the shared vision of making users successful to just go an extra mile color outside of their box and do it with Karen for their peers and their responsibility as well.
I really have not found any other way to solve this and uh, it's difficult. Because as a each, each of those PMs have their own boss, right? And that boss decides what their incentives are, et cetera. So it's really hard to coordinate, but culture really is where it all either works or breaks apart.
Brian O'Neill: Do you have this challenge of like. Especially like internal data, team data, product teams, particularly, it's like the struggle to quantify the value of the work that we do. 'cause it's not direct revenue generating, usually. It's like, well, we're improving the forecast so that they know how much to sell to the whatever.
It's like, well, how much of that is, you know, can you thank the slack bot that you, that we made? Like, how much do we credit that? You know? And you then you need a counterfactual. Like, well, we didn't run the counterfactual to know what it would've been. So does that create little value fiefdoms where the three PMs all kind of wanna like take some credit?
Or like does this, I'm sure there's some politics here, but are you shielded from that because you're more on the engineering side?
Irina Malkova: Definitely not, not shielded. Yeah. Think being a call center, being a call center is a in, in this day and age is a difficult life. Yeah. I wanna say that ROI of analytics has always been a problem.
Brian O'Neill: Yeah.
Irina Malkova: I don't even know like how our function is. Alive even because, uh uh, I've been on analytics for what, like 12 years and every time it's so hard to justify what we do that every time there is a boss in the business cycle, analytics people are the first ones that the business turns around and we're like, do we need this many analysts, which you guys are even doing?
So it is definitely a tough place to be. A completely relate. I do think though, that it's about to change. One of the first tactical reasons on why is, is this change in nature of analytics products from being outside of the flow of work to being in the flow of work. So fundamentally, in my example with, of the going from five dashboards to a Slack app.
I had no idea what people did with my five dashboards. I saw the visits to them. I maybe even would see some kind of filters interacted with if I really doubled down my instrumentation. But that is it, right? I don't know what they're doing with this dashboards, whereas now I'm in the flow of their actual button clicks on the operating systems where they're creating those quotes.
So first of all, I can see whether the actual quotes were created As a result of my conversation, I can actually trace the outcome to the quotes being created. I can see if they create faster, right? We can find some kind of counterfactual from before of how long it took to create the quote, 'cause they were looking at a dashboard.
But now I actually can see how fast they create them and then the best overall when they talk to an AI tool, you can finally see their intent. I feel like we have always dreamt as data product managers to just know what, what on earth do users even want out of our dashboards? Right? Like, what is the question that you're coming to the dashboard to?
If I only knew, I would give you the perfect chart right there, but I don't know. Right. I'm trying to talk about data, all of the questions in you and now you know. You actually, uh, can't understand what is that they're usually looking for. So I think that is, that is a gold mine for data product managers that we're just, just scratching the surface on.
So, yeah, I'm, I think we'll be able to prove the value of. This of data analytics and insights in a dramatically more quantified and, and, uh, powerful way than we have ever been. And I think some of the metrics that, uh, customer success teams are using where they're essentially switching from the human support center to the bot support center.
Like, for example, deflection rate. How many of your queries went to a bot instead of a human being and how many of them were successfully answered? We can use those metrics now, and that's something that we have never been able to do before. But now you can see how many of those queries actually got closed without the human.
So yes, it's been tough. It's still tough, but I really think that it's, there's the light at the end of the tunnel.
Brian O'Neill: Yeah. Do you find that your team is being asked to do. AI appropriate AI work as opposed to like, this sounds like someone just trying to use this new screwdriver they got. 'cause they want to use the screwdriver, but it's not the right solution for that.
Like, or, or do you tend to have a, an educated business spot or educated DPM on the, that's sending the, uh, I wouldn't call it an order down, but, uh, the, the requirement so to speak. Do you tend to get fairly mature asks that are AI appropriate and, and this type of thing? Or are you guys having to like, have that conversation about is this really the right way to do this?
And maybe we start with a different method here. 'cause there's, I, you know, I'm just hearing so much, it's just like, everyone's like trying to use this stuff and I think it's great to ex run experiments and, and to see what is possible, the art of the possible. And some of that stuff has really changed now about what's, what can we do now?
But it's also, you don't wanna just like try to use it everywhere, wherever you can. It's not always appropriate. If you have a really like predictable workflow, then code it as such and get rid of all the probability chances that it's gonna do something stupid, like you could literally do damage with it.
Why would you open yourself up to that unnecessarily? So I'm just kinda curious if they tend to be mature asks, uh, so to speak, that come down? Or how do you navigate that? Uh,
Irina Malkova: I think just like everyone we went through, uh. AI agent CRA built me an agent for everything.
We definitely had crazy November, December, January, I wanna say this past year when it was a perfect. Uh, a perfect storm of enough folks in the company finally getting the fact that AI is cool and they wanna try it, and then the tools to build AI internally finally becoming available. So we rolled out our own version, uh, deployment of agent force and that, and that did not end well.
'cause everyone was like, I'm gonna build an agent now. Awesome. And it was just like they, they have a compute. So majority of those didn't work and uh, lots of time was wasted into the, on this experimentation. So. Completely agree. Yeah, I think it was a necessary.
Brian O'Neill: What did it work?
Irina Malkova: ROI is the biggest one. I think understanding, just like you said, for what kind of use cases, agent is appropriate.
And whether there's a party positive Horizon, the biggest one, because the cost of building it should be not prohibitive because it's actually expensive to build. Um, an AI app that works, I I you, it's very cheap to create a prototype that sort of works. Very expensive to build it right with the right accuracy, right?
Reliability and security, et cetera. So I, I think that part we didn't get, and then the return on investment side, either, I think there was a lot of agents that were launched that would serve, I dunno, like a hundred users maybe. Is it really worth it? The time saved for those a hundred users, is it worth the investment into actually building this thing really well?
ROI was the biggest one. The maturity of building practices as well. I think AI application, just like we said earlier, is harder to build than software. It's, uh, deceptively feels like it's easy because there's all of this noise about the one man un unicorn startups and like all of this, like white coding and all of that, just build your AI up.
But it's actually, if you really look at the process of building it is harder because the architectural choices are much harder. Like, can you get away without using rack? Can you get away without some kind of post-training and complex processing and retrials and reasoning? Or do you need all these things?
Can you, what's, what shape do your data have to be? And there's a lot of conversations about metadata right now and emerging conversations about metadata needing to be a graph or ontology. It sounds awesome, but it's very expensive. So do you need all those things? So you really gotta understand. Whether like how to, the engineering choice of how to build something and I think there's a lot of educational vault, so we just, uh, it's just so, so it's like a siren call, right.
We all heard it. We ran, we uh, ended up on the rocks and now we're figuring out what to do and I think the answer to the next step is really snap back to trust. Exactly. What we touched on a little bit earlier is that trust was not top of mind. In the first gold rush of building this apps. But now it should be, and, uh, I think this apps can be trusted.
It's just we need to both lead users to trusting them through incrementally, incrementally more and more autonomy. And we also have to invest into trust actually being there from the product and engineering side.
Brian O'Neill: Yeah. I was curious, what made you say that quote, AI adoption moves at the speed of user trust?
Like what were you reacting to there?
Irina Malkova: Yeah. Uh, I have a discussion with that about that with a lot of my friends. Um, we sometimes think of AI upsell there as categories. Some of them are conversational bots. Some of them are autonomous agents that do not require user to get involved. And, uh, we think, we think of this category sometimes as completely different things that are.
Less mature. More mature. So conversational bot is something that we started with, but it's actually not great ultimately, and, uh, we all should, we should go to the autonomous agents. So my strong feeling is that they're not separate. They're just stages and evolution of trust in for the technology because just like, it's, it's like with any automation.
Before a user will rely on automation, they will first double check that it works even with dashboards, right? So any ML model I have ever deployed before ai. I always had some analysts sit down and do back of the envelope forecast of the revenue, and then compare that number to my ML model. And if they're in the ballpark that maybe that may be, after 10 times of doing that, they will stop doing their little back of the envelope calculation.
Just start trusting the model.
Brian O'Neill: Right?
Irina Malkova: You careers on the line. You're not just gonna trust the random number. That AI app just randomly is giving you out of nowhere.
Brian O'Neill: Yeah,
Irina Malkova: because that's your livelihood. So. I think that just like with the, with classic ml, just like with dashboards, there is this very intricate job of building that trust with the user, and it means that every AI deployment, in my opinion, have to start with the conversational interface.
You have to make AI a helper to the user. And you have to make it silver both. And so open, that user can build trust in that helper. Just like for example, um, like when you hire an intern. You always check what the center does and this shows the work and they come in with all of the details, and then maybe eventually you will start delegating more and more text, et cetera, et cetera.
So that's how I think of what the conversational ai. Assistant should be, they should be very helpful, very open. Show their work exactly the lineage to where the numbers came from. Give the name of a human data scientist that can help if this is for some reason looking fishy, and that will continue until the user is comfortable and at that point.
User will probably just require 'em first to be less verbose, but still require them to check in with the user and then it'll be month until the user doesn't even wanna check in because they, they trust this thing so much. And that would be the moment when you are ready for an autonomous ai. But not until then.
Until then, you really have to show the work and let this assistant grow as the user see fit.
Brian O'Neill: Do your product counterparts then. Do they leverage any user experience, talent or human factors, people or anything? And, and because this is very much in the domain of design about understanding trust and what types of questions are they asking and what level of veracity should we get back to them, and what kind of evidence is the, you know, consumption seller need?
How much evidence do they need? What kind of evidence do they wanna get back? These are all like design questions to me. And I'm, I'm just curious, are they, do you have. Talent that's part of that? Or is the product manager expected to, to define all that themselves and then pass that to you as requirements or,
Irina Malkova: that's where I have always been so inspired and impressed by you and how you have been spearheading the UX for data.
So 1000% that that should be ux and we have not, we have not hired that talent. So today. Uh, I do expect my product managers to do it, and they do it somewhat because they're just brilliant people, but that doesn't scale like really, so I'm completely with you. I think there is a big role for UX in product, even bigger role for UX and product management as we move to, uh, uh, delivering in the flow of work.
Because our own stakes are higher, right? It's not the dashboard that potentially nobody was gonna go look at. It's truly in the flow of work,
Brian O'Neill: right?
Irina Malkova: Between seller and the deal close and revenue hitting, uh, co company book. So yeah. Yeah. 1000%.
Brian O'Neill: Yeah. 'cause if you don't, I mean, you often see with the, you know, large product management organizations and big enterprises is they're really doing like requirements gathering.
But like what's not happening is not, uh, and this I'm stereotyping or generalizing, but. There's not a lot of time spent doing direct customer research, so it's like. You know what it's like to be a consumption seller. You know what their pains are, their incentives, like the, you talked about the bonus, which I love.
'cause it suggests that you understand their personal motivations, but that stuff really matters and it's really hard to design something Well if you don't know what it's like to be that person, which you really can't get through. Requirements. Requirements are a manifestation of a solution to a problem.
But if the problem's not well defined, then it doesn't matter what the solution side looks like. And I'm always curious. You know, how, how teams are getting problem space clarity, such that these AI initiatives, because they can be so what, they're probabilistic in nature. It's like how, how do you design something effectively in that scenario?
Unless it's like, roll it out, see what happens. But I, to me there's that trust cost. It's like how many trust points do you get to wear down before someone's like. Yeah, not gonna do it. Like I got burned on that deal. Like I just, you know, like the reputation has been just eroded too many times. You know, maybe, maybe I'm making stuff up that's not true at Salesforce.
I don't know, but that, I don't know.
Irina Malkova: Oh no, you are hitting it right into the heart. Um, I sometimes look at our. Adoption dashboards for the, the AI applications that we're building. And, uh, folks typically celebrate both, uh, the things that are, uh, have high return rate, but also the things that just have high usage and, and low return rate.
And I am very terrified of those things because if I see a lot of, a lot of folks coming in and never coming back to an AI app. I see hurt people who have a need, right? So they stopped whatever they were doing and they, they tried the say that you're offering to them, and then they didn't like it to the point where they decided to never come back.
And that to me is dramatically worse than never releasing that app at all, because it's poisoning the world for any future AI innovation. Potentially just lost your company, uh, just cost your company some money, and this folks trying this thing out and getting disappointed. So, yeah. Yeah. No, I'm, I'm completely with you.
I think the most, most important, most good looking curve of a launched. AI application for me is this little step function where you add users in in small increments, starting with the ones who are most interested and have highest pain and most willing to roll with potential challenges in there. And then you see them all come back and then you add more.
You see them all come back, you add more, and then maybe eventually you open up to everyone. But seven day retention on an AI app is one of my. The highest metrics that I look at across my portfolio.
Brian O'Neill: Oh, interesting. Do you think the, the lack of having user experience or design as part of this is because it's perceived as, oh, well it's just going to be deployed in Slack.
It's, there's really no ui, so what would we need that for? Or is it really the pain of a low adoption is just not that high? Like if they don't use it, it's not a big deal. It's not a big deal. Is it, do, do you have a sense of why that, why that is? If, if, if the adoption thing matters so much, then why? Why is a group whose skill is around that not utilized as much, I guess is my question?
Is it just not seen as a design domain?
Irina Malkova: We don't really have UX and not data organization at all. Yeah. So I think it's the existing immaturity that we have never dealt with. 'cause when we created the product organization, we, uh, created product roles and then after a little bit we understood that engineering is also very important.
We created engineering roles and uh, we did a lot of work around that. But there's all these other roles. That make a real product in a real life successful that are needed, and UX is number one of them. So I think that's still that we're dealing with, I'm sure a lot of other data teams with, and then that compounds with the changing nature of ux.
So exactly what you mentioned. So the, the interface is different now. It's on the flow of work. So I think that. That, uh, gives people pause. 'cause we don't know how to think of UX in terms of these apps that already have ux. And I think the other thing that, uh, our head of UX at Salesforce talks a lot about is this merging role of between UX and then the anthological core of the experience, which I a hundred percent believe in because I think as you understand what people are asking.
You can also start building understanding of the universe of the things they wanna know and start structuring that universe and that structured understanding has real value, like real tangible value for ai because you can turn it into a knowledge graph and you can make a search better. So I really do think that UX will have a big, even bigger role in this new world, just like with product management will and engineering will, and it's very underappreciated.
So you are calling attention to something that's a real problem, and I don't think enough people are talking about it.
Brian O'Neill: Yeah. Yeah. Did you say at some point when we talked, I know a month or two ago when we were catching up about the podcast, I thought you had said it, you had some stumbles or changes like when you were trying to bring in like product management as a discipline or applying kind of a product model there.
Maybe I misheard heard that, but is there something there that you wanted to share? I'm, I'm sure our audience would be curious if there was some learnings or something that you changed, oh, we tried this and it didn't work and here's what we did instead. You know, any, anything you wanna share there?
Irina Malkova: A nutshell, that's what I just summarized in spirit.
So I think the biggest learning is that. We data folk were sold. The dream that transitioning to a product model means having some product managers and having them write PRDs and doing Scrum.
I like it that you love. Uh, that is about literally what a consulting team told us to do. To become a data product management team, uh, two years ago, and lot of the goodness came out of that transformation because having product management is necessary. You do have to have product managers, you do have to have them write p use, which is not write anything, right?
You do have to have scrum. I do believe in scrum scale. It's just, it's not sufficient. What you also need to do is to have the rest of the things that I needed to build a great product. And uh, it's such a common sense thing because if you look at the product, great product organizations out there, like startups, they don't just have product managers, right?
They have all the other folks that make it amazing. The first role that we realized was missing was engineering manager. And it was, uh, quite impressive that I did not think about that myself going through that process. Because even if you read any product management book like Marty Ka Kagan's books, uh, it's always about this, this pairing of great product management manager and great engineering manager and how they need to work together, how they have this creative tension, how all of the great things come out of it.
But in the standard data organization, engineering managers are actually. Rare because there's many reasons for that. I think there's historical reasons in that engineering just has not been as important when you're delivering services and many DataWorks grew up as services. There is also the structural problem of having too many engineer disciplines.
'cause there is data engineers, there is utilization engineers, there is ML engineers. There is sometimes software engineers and sometimes analytical engineers and big data engineers are different engineers. So yeah. How many engineering managers do you really need? Mm-hmm. If you have five of them, because you have head of data engineering, head of ML here, and then head the visualization and the list continuous then.
PM's job becomes a TPM job because all you do is you just coordinate your user stories with those five different folks. So I think that spms think about their ability to build great products. They should ask themselves if they feel supported by having one engineering partner that could truly be a thought partner, having their engineering team operate at the highest standards of excellence.
Like for example, having a data developer platform. Many data teams do not have that. They, they, they cobble together a stack of, uh, development environments of their choice and deployment patterns that they feel like are right. Not having any support really from the organization on the, what is the standard development processes and development lifecycle, there is typically no architects in data teams, and if there are some architects, they're usually modelers.
Right. They're not software architects that can think the whole stack through right. Where, and, and then help us avoid problems with latency, uh, problems with tech debt moving on, et cetera. So it really, I grew up in a business ops type of track. So I was a McKinsey consultant straight off school. Then I was in customer success, and then that's how I came to data science eventually.
So I actually did not know these things. I did not know what good engineering looks like. And it took us a while to understand how huge was the piece that we were missing. And I, I have a feeling that many data organizations are in a similar boat because if you didn't come from the engineering background, you don't see what you're missing.
But it's just so transformative to have a mature engineering org. With the leadership at the right level, with the folks who are not just executing, but also acting as great engineers and constantly bringing the technical bar up. So it's really that, that has been the transformation that we have been going through after the original PM transformation.
Brian O'Neill: Interesting. Yeah, I tend to think of that for data products. I, I hesitate to call it like an engineering manager. To me it's like the, the product manager needs a technical lead. Whatever's appropriate for the project. If it's heavy, you know, gen ai, then you, maybe it's a data scientist. If it's more software with a little bit of forecasting, maybe it's an engineer.
But the point is to have someone that understands the art of the possible and all the downside risk, especially with the AI stuff, whatever that person looks like. And I, you know, that can change, but that's what I think of as the sparring partner more. But, you know, you guys are in a native software company too, so I'm sure you have a little bit more talent available than, than you know, some of the legacy.
You know, companies do LA large enterprises and stuff, so yeah,
Irina Malkova: we haven't figured it out. Yeah. But I do think that the, the reality where PM has to decide what engineering technique to go to, it is a difficult reality because then PM sort of needs to understand the art of the possible a little bit. What to decide even is this a data engineering problem?
Is it the ML problem? Is it the software problem? So I wish we find a way out of it. I think we soon we'll force, we'll be forced to, um, I had an anecdote. Our data team now deploys, uh, two Salesforce production agent deployment. So we have this big agent on health.salesforce.com That is awesome and wonderful, and our data team plays a part in developing it.
And, uh, they're doing a lot of great work. But early on in the process, they did something that resulted in an outage. In that agent for a short time. Thankfully nobody was affected, but that's because we are very smart, very well intentioned people, but we do not have those software engineering practices that the professional software org has.
And unfortunately those things are gonna start being visible very quickly as we start deploying in the, in the flow of work. You don't wanna be the slowest person running away from the tiger. You don't wanna be the one who always causes the belt to to break, right. So I think we would need to figure that out.
Brian O'Neill: This has been great. Irina, thanks so much. Is there any like closing thoughts you wanna share with the audiences? I'm sure they've gotten a lot outta this already, but I wanted to kind of give you the last word.
Irina Malkova: Yeah. I think we, with data folks spend a lot of time being anxious about our craft. I think we should be excited.
The thing that gives me a lot of excitement, for example, is a scale AI's recent valuation. Of close to 30 billion. And what does KL AI do? They do data things, right? They, they make your data ready for ai and they do use data to relate AI and that it just, they just focus on unstructured data and just do their job really, really, really well.
I think every day the team out there. Has a potential to be the scale AI for their organization and even more valuable possibly because we truly own the most important asset that AI can ever have, which is data to train it, to use it to, to turn into value. So I really think this is our moment. I think we all need to just slow down, take a deep breath, listen to some really good podcasts out there, get some good advice, and, uh, just change the trajectory of where we're going.
I'm really excited for the future of data.
Brian O'Neill: Cool, Irina, thank you so much. Where can people stay in touch with you? Follow your work? It's LinkedIn, where do you hang out?
Irina Malkova: Yeah, I think just LinkedIn. I'm very bad at external writing, which is is something I need to deal with, but so LinkedIn is perfect. Irina, Koa,
Brian O'Neill: I love your writing.
Your posts are fantastic. So when I, when they come up in my feed. So I think you're really good at it.
Irina Malkova: Oh, thank you. Thanks Brian saying.
Brian O'Neill: Awesome. Well thank you so much for coming on, experiencing data. I'll, I'll put those links in the show notes.
Irina Malkova: Thank you. Bye.
Brian O'Neill: We hope you enjoyed this episode of Experiencing Data with Brian O'Neill.
If you did enjoy it, please consider sharing it with the hashtag Experiencing Data to Get Future Podcast updates, or to subscribe to Brian's mailing list where he shares his insights on designing valuable enterprise data products and applications. Visit designing for analytics.com/podcast.