The AI Portfolio Dilemma: Why Most Companies Can't Account for What They're Spending | CDO Matters Ep 104

Speaker A: Foreign

Speaker B: hi, I'm Malcolm Hawker and this is the CDO Matters podcast. The show where I dig deep into the strategic insights, best practices and practical recommendations that modern data leaders need to help their organizations become truly data driven. Tune in for thought provoking discussions with data IT and business leaders to learn about the CDO matters that are top of mind for today's chief data officers. Foreign. Good afternoon, good evening. Good whatever time it is, wherever you are in our amazing world. Thank you for joining us today on um, this, the 104th episode of the CDO Matters podcast. I'm Malcolm Hawker, I am your host, your guide in today's discussion. I am thrilled today to be joined by Igvo Sokolov, who is the managing director of the specific group based in amazing Vienna, Austria. Ivo's, uh, also the book author. He's not the book, he's the author of a book. Sorry, it's Friday afternoon, my brain is slowly leaving the building. Uh, he's the author of Finance Grade Data and AI Products. Uh, a book. We're going to talk a little bit about today. We're going to talk about Ivo's, uh, perspectives on finance, finops, financial responsibility in an era of AI. We're going to talk about roi, we're going to talk about how to treat these AI products and these big large initiatives. Evo's got some really interesting perspectives here. He's got a great substack as well with some really awesome thoughts in his substack. I, I, I fell down a rabbit hole reading his recent substack that he published on Bill Inman's substack. So it's a substack in a substack. Uh, but it was a great, uh, article talking about how things are changing through the lens of kind of finance and financial operations. Ivo, thank you for joining us today. It's good to see you.

Speaker A: Thank you for having me, Malcolm. Uh, appreciate the invite and um, it's great to chat again after a recent discussion in person in Vienna just a few weeks ago.

Speaker B: Yeah, it was good. I was glad I ran into you. You and I had exchanged, well, probably a few, you know, a few comments here and there, of course, uh, on LinkedIn, uh, you had recently gone to Data Day, Texas and I don't think you went to the last one. Right. Where was the ice storm? With the craziness in the ice storm. Yeah, I didn't, I didn't go.

Speaker A: Yeah, well, that was quite the experience. This was the, this was the, the final edition so I had to be there. But Yeah, I think the community will continue to have such, uh, awesome kind uh, of practitioner led events.

Speaker B: Yeah, well, let's, let's get into it. Let's talk about money and uh, let's talk about AI. Let's talk about your framework. I do want to learn a little bit more about something you're calling the vein loop, which is kind of your approach to valuing efforts around AI. It's not just AI, it's all data and analytics projects. Right? I mean your framework is a way to consider ROI on all of these investments in the data world. Right? It's not just AI.

Speaker A: That's correct. That's correct. I think, uh, the interesting with AI is that everyone is running with their AI use cases list, right? We got 100 use cases, we got 200 use cases. The larger the enterprise, uh, the more triple digit the use case list is. But at the same time this didn't evolve out of nowhere. I mean people have had machine learning and other initiatives before and also data products trying to perceive, to look at more those things as standing products rather than just one off projects. So the complexity, as I mentioned, I think there's like a hype wave, overstacking, hype wave, overstacking complexity one after the other. And my co author, Mario Meyer Huber, um, and I, we were just thinking that, um, based on our experience as consultants, based on what we're seeing in industries that everyone is running, trying to say how much value they provide, but we saw little substance about how to simplify this in a framework that you can actually apply. And the frameworks that we've seen seem very theoretical and not something that you could run off to a boardroom and be like, well, it's a good approach. And so that brought us thinking, well, since we aren't seeing this, how about let's just rough one up and let's see what people think. Uh, one thing left to that is that we spent the better part of last year and especially over the holidays, just finishing up the book. But the idea is that uh, we're seeing that it already. There's a ton to update. Even though we publish it in January and post cowork, we're already seeing things that we wrote in that article and things like that you mentioned where we would add into the second version of the book, uh, just to keep it updated because this is just how fast things are moving right now into the three months.

Speaker B: Three months. You wrote a book that came out in January and already you're talking about updating it and it's April.

Speaker A: Yeah. Already. Because I'll tell you why. I mean, one of those things, if you remember of the second part of last year, you know, it's still a real concern, but back then it was, I think, a bit more real, is that everyone was talking about the AI bubble. Right?

Speaker B: Yeah.

Speaker A: And we were saying, well, it is absolutely true that the ROIs don't pan out. It's absolutely true that, you know, after the ends and then someone asks you, how much money did we spend on AI and what did we get for it? The CFO and the CEO may not be thrilled. And at the same time we were thinking, well, what does that mean for you as an individual company? How do AI bubble proof your portfolio while going significantly long on AI and implementing these things? But now the update is not like the bubble has shifted a little bit towards, um, how do you control the cost such that you're not, uh, beholden to a single company where the API breaks and the token costs explode. We've seen examples with the recent switches where out of your $200, uh, dollars subscription, if you recalculate the token cost for certain use cases, all of a sudden it's 7K. And so that's quite the jump. Right. So that's what will go to an update to the book. And also, uh, frankly, another update, if

Speaker B: you,

Speaker A: if you see what's happening, um, is that, um, I think we're seeing a world where you would want to buy specialized AI solutions if you're a major enterprise rather than try to develop everything on our own, even though you possibly could based on your teams and whatnot. Because the difference between very, very good and just okay, um, is huge in terms of perception, adoption, et cetera. And so that thing actually solidifies our thesis in the book, which is portfolio steering is actually relevant. Again, it never really went away. Many companies would claim we are doing portfolio steering for AI projects. What do you mean, of course, with portfolio steering? But our point is. Yes, but you might have a particular blind spot on data and AI because the things are moving so fast and because the, uh, make and buy decisions keep changing. Because you probably run off with a vendor where you do a strategic bet and you only know this company for two months. And that's what many large corporations are doing right now, as these specialized AI applications, uh, are solving particular problems in various industries. And you're not going, uh, with the generic model while at the same time, obviously you're going with the big labs for various other use cases. So it's a very exciting time to look at this in your data products and AI, especially your AI use case list as a portfolio of bets, uh, which more aligns with the theory of managing like a financial portfolio really where you don't know what the winners, losers are. You're looking at yield curves, you're looking at things that you don't really talk about when you're looking at a classic IT projects portfolio list. So yeah, um, things are moving fast.

Speaker B: So there's a lot there, there's a lot there to unpack. One is you, you talked about kind of the changing financial dynamics here and things starting to lean a little bit more towards build. We should talk a little bit more about that because I don't think you're talking about building everything right. Like you're not talking about building a foundational model that, that's, that's, that's cost punitive. But, but, but you are talking about bu, building these customized application layers, something I think in your substack you called maybe a financial layer. But I think you're talking about building more than that. So we need to talk about what the build actually is. That's something that you talked about. You talked about the unit economics here and a focus more on AI as an infrastructure than, than purely an individual capability or capability by capability. I think that's something that we need to talk a little bit uh, uh, more about because on a unit cost basis, I mean I'm living it right now. I, I, I, I deployed OpenClaw a couple of months ago and, and I just, and I don't use my, my personal Gmail that often.

Speaker A: Right.

Speaker B: I'm usually in my work and I'm heads down to my work and I looked at my Gmail box and all the invoices from Anthropic, I was just like, oh my God. Like just. I had no idea how much money it was. Mostly my wife, but whatever. I had no idea how much money was going out the window in these, in these open claw tokens. Like good grief. Uh, so we need to talk about unit economics. And then the third thing we need to talk about is we call portfolio management and this kind of, this broader portfolio view of AI investment. So wow, there's, there's a lot to, there's a lot to go deep on there. One thing I do want to say, one thing I do want to say to everybody is that if you are still in the, if you're a CDO and you're still in the camp of well, I can't measure the value of this Stuff, yes you can. Ivo's got a tool that can help you. He's got a book that can help you. We're going to talk about, yes, we can measure this stuff. But let's go back, let's talk about the economics, the building. What, what do you see people building and what do you recommend is, is the build part of all of this?

Speaker A: Right? So uh, what I see across the board is that, I mean obviously people are eager to build stuff with the newest uh, frameworks that leads to the fact that something you built like a chatbot you built, maybe you invest a lot of money to make it production grade whatnot, uh, just a year ago and that is already something you should decommission and build from scratch. And maybe you can do it in three, four weeks, uh, with the newer stack because the customer experience would just be so much vastly more better and improved and relevant that uh, is actually you uh, can consider your investment, um, more like a learning um, capability rather than something that you basically uh, have to explain to someone. Well, we just finished this project. What do you mean we have to kind of start a new one. Uh, did you guys do a bad job or not? And no, the technology is changing so we really should. And the point of the Vain loop framework, the word loop comes from, also from the OODA loop, which we talk a lot about, uh, which um, comes from the US military, then also adopted by the consulting industry but now kind of back again. You don't want to be the, you're not really trying to be fast failing. What you're trying to do is inside your competition's basically decision, uh, cycle and try to be a step ahead. And so in terms of building, what that means is that you have to really evaluate first of all, you know from the fundamentals what is like what are your, what are your platform bets that you're doubling down on, how do you get the maximum out of it and really what are the use cases that you should decommission and start from scratch and maybe think them end to end rather than mid to mid to interior business processes, which is a difficult organizational problem to tackle, but an easy technical problem to tackle. And so, and then also the option is of course that you're bringing someone specialized in that particular vertical of like, I mean we already mentioned what we do, for example an agent that solves AI management of AI use cases which you can go ahead and build and you can take a team of three, spend three, four months building it. Why should you? We've already done it so that example replicates across multiple use cases. But also what you don't know, and this is another finding from the build, is that some of your use cases that are real winners, they didn't come from management, they didn't come from you. They came from business departments to scatter around the organizations, from people that found something that really scales up and brings a lot of value. And you have to have a framework that surfaces that up and scales that even though it's not your classical way of how it projects blow up. I mean I'll give you, we actually have a lot of examples in sales and marketing. In finance, people have built amazing things that actually save a ton of work. Uh, and also the question that comes is how about use cases that span multiple departments where you didn't really encourage that sort of thinking because every department brings up their own use cases and they're trying to optimize, uh, their own workloads. They're trying to optimize their own relevancy. Uh, but maybe uh, you should think of it holistically in a way where you uh, compress certain functions, certain processes and build up others. So um, quite exciting to be in the build space in AI right now, uh, because of the uh, amount of possibilities that open up, but also the amount of responsibility and amount of care that you need to take in order to not get things wrong. Because now you can get things wrong on steroids.

Speaker B: So something I kind of concluded in reading your, one of your substacks and I want you to keep me honest on this. And you, and you, you just inferred this in something that you were just saying building is, is, is part of the motivation or even maybe the recommendation to consider building when two or three years ago, maybe that wasn't the recommendation. But would you be recommending this because you believe that, that AI investments should be capex and should be considered infrastructure and should be where the cost should be deferred over three, four, five years. Is that, is that, is that part of the kind of the portfolio play here? Is that, is that, is that you see AI as being more of a capital investment than just purely this one off OpEx. And, and, and the problems that come along with being opex.

Speaker A: Actually quite an interesting question. And the answer, I'm sorry to say, is it all depends, right? Because um, it all depends because it might be neither, right? It might be, just might be adding it to the cost of goods sold and just pricing it completely differently. Uh, right now AI is also eating labor budgets. So there's Various things to consider, especially consider a newer iteration of coworkers where it's not just design, it's like a procurement person, a marketing person and all of a sudden how do you treat that? So it's quite a valid question but I think you really need to separate the fundamentals building and they are solid. I mean you see databricks, uh, and even Snowflake and I mean they're actually continuing to grow and they're not, you know, they didn't experience that SaaS apocalypse moment because people know these foundations are needed and you kind of have to be on the platforms now you cannot be on not there. So, so that fundamental capex build out is there despite you'd consume it as opex. But the internal investment is for you to build your own capabilities, be able to turn um, um, you know, projects, use cases at a quicker cycle to know how to use these tools, uh, and to not use the slides from two years ago and databricks but just you have to be very current with this within your team. If you're doing this, you go all in and utilize it uh, across the systems. And my thesis, and the thesis will put in the book is strategic decommissioning. You should double down on shutting things off because this is eating your innovation budget. It's just basically your people experimenting with various systems, trying every new fad in AI and basically you're still running your old system, you're still running your oracles, you're still and whatnot. And so uh, you really want to use this moment to do some architecting of the base layer. Having said that, now the economics keeps changing again because on premise is the new cloud for various types of workloads. In Europe we talk a lot about sovereign AI, uh, the fact that everyone is saying, well um, to not name any name but the main lab right now. Their API has been very shaky um the past few weeks. As soon as Wall street opens, the uh, servers start not responding. If you're, let's say most of my clients are banks. Are you going to base your very critical workload on an API that works like that? I mean, no. As a startup, yes. As a major organization you probably think twice. There's a shortage of GPUs. They can't roll this out as quick as the demand, uh, commands and that leads to the token costs exploding. So um, there's various things you need to consider when developing your AI strategy, uh and it's a continuous thing. But one thing is certain though, uh, it is quicker to build New things than it ever was before. And so, uh, if you manage your portfolio of bets on AI in the proper way, you kind of balance your longer term investments that have a longer yield curve where you really have to build a, a one or two year investment in teams, uh, in internal, uh, build outs, uh, until we can fully utilize it while keeping options open. One thing you just mentioned with your open claw, and that didn't exist just a few weeks ago, right? Or months ago. And so uh, all of a sudden now you can do a bot like that. And that opens up new opportunities for you, but opens up a ton of problems as well. Not only security wise, but also, I mean I was just commenting on Carly Taylor's post today. She, I saw she commented back, is that um, I mean the Internet wasn't built for, for something like this, right? It wasn't built for everyone being able to have a bot that is basically active 247 and churning out trend slop across the board. So what do you do with that? I mean it changes the nature of communication and so.

Speaker B: Well, that's something else. That's something else you talk about, you talk about the fundamental differences between kind of legacy approaches and what's needed now, right? You. And in, in the substack that I read, you talked about the idea of, you know, AI ready data quality and how that's. That that is fundamentally changing. I couldn't agree more. Um, I've been saying this for years, right? What is AI ready is not the same thing as what is BI ready. And what you, what you've been describing is very different. How, what, uh, frameworks do we need? Not just financial frameworks, but also kind of, maybe even development frameworks. What you seem to be describing, Ivo, is this new logic layer, this new decisioning layer that is extremely agentic, that works across multiple contexts, works across multiple domains. Because this is something you're talking about, this portfolio perspective, right? And is that, I mean, that's the world of the cto, is it not? What you're kind of describing, they all

Speaker A: kind of, um, I mean it keeps shifting. It keeps shifting. The reason, the reason it is. So let's walk this back. Data quality was something we spoke data people for years. We need data. We need to go. Why? Well, just because. Why would you be against good data quality? There's no good argument against it in regulated industries as we've seen. It didn't get solved until you remember the global financial crisis. Then the BCBS239 regulation came for data aggregation because they figured okay, risk. Data aggregation was a problem that led to Lehman Brothers failing, et cetera. And so, for example, regulated industries like banks, like healthcare, they were pushed. They have good data quality. Well, other businesses had to learn it the hard way. And you had to argue extremely hard to the board about why do you want to do, like a data governance framework with owners and stewards and data cattle. So this wasn't really obvious to everyone. You had to invent stories to get these projects approved. You had to make stuff up or show progress in other areas where they'll be like, well, who cares? Two more million, we'll invest in it. Just get it done. Data quality doesn't sound bad. Now the game is kind of changing where architecture, proper architecture is critical to your business staying in the market.

Speaker B: Right.

Speaker A: And so you want to be set up in a way where your legacy applications and your modern stack can interact and we have bots and people addressed properly. And so, uh, data quality becomes an issue. Where you don't want data quality for the sake of good data quality. You want data quality for particular things where it's super great. And others where you're like, you don't care. Uh, the A.I. can fix my data quality. So all of a sudden I'm seeing super deterministic things like, um, entity resolution projects where you want entity resolution on your master data becomes as relevant as it ever was. While in other areas you just don't have the same problems anymore because it's bots interacting with your legacy, uh, system, not humans. And you can kind of build it into the skills and they can work around the quality issues. So, um, it's something, I think, takeaways that you need to do a conscious effort to address this to both for different. I don't want to use the agent declare, the big vendors use it, but for something like the agent declare, because ultimately it's ETL's and APIs. There's nothing, there's nothing more to it. And where do you apply it? I think, um, it's a huge tailwind for, uh, our catalogs and master data management and metadata management initiatives that many in the market are using to set things up. Right.

Speaker B: Yeah. It's funny, I was typing some notes to myself while I was listening to you, and I made a note to myself that said, this sounds an awful lot like my 1997 services layer that we were trying to build in the late. This service layer that does it all. That was kind of like, then it went to WSDLS and then it went to APIs. What you just said it's all ETL and APIs. Yeah, go ahead.

Speaker A: Did you want to hear another, uh, late 90s analogy that I think applies to.

Speaker B: Oh yeah, I love when people were,

Speaker A: people were doing this AI. You know, everyone has their AI center of excellence, enablement centers, I mean all of those big words. And it seems to me that it's basically the shared services of the early 2000s all over again. Where, where back then it was like, let's outsource. These guys are going to outsource us to India, um, or whatever. Um, and you guys should talk to this enablement center. And there's a lot of context that got lost. They didn't see any usage. All the divisions and departments, they found their workarounds, they found ways to argue why they should keep their critical vendors in the U.S. and Western Europe and whatnot. And it took decades for a setup to evolve where you have international teams working together only after the technology improves and collaboration methods improve. And now we're seeing the same thing in AI. They're treating it as like, how is this any different than just the shared services from before? But it's a bit more technology than it was back then. You're making the same mistakes. Uh, because from the management perspective I think you need a different sort of really board level leadership to understand how to embed this correctly. Ah. And make use of it. Or else we're back to late 90s analogies. Right?

Speaker B: Yeah, well, right. But something, something that just popped off in my head while I was listening to you. Yes. I, I see a lot of similarities here around the shared services models of the 90s. And I, I lived and breathed those models and to a certain degree they kind of, uh, especially from a finance perspective, at least for me, they kind of worked as, as long as I could get everybody bought into the idea that they truly were shared services. Right. And I could just allocate the costs on a percentage basis back to Everybody. You get 10%, you get 10%, you get 10% and I build the thing and everybody benefits that works. And there's this attribution models are still being used widely by a lot of financial groups. But uh, what may be different now is that what we were building then and what we continue to build and what exists in the ETL and particularly the APIs, and now increasingly MCP, most MCP gateways are just hating APIs. Right? They're just, they're just, they're just agentic doors on, on APIs. Is, is that the APIs are, are executing, you know, features, functions, capabilities. And what we're talking about here are skills. I think and I think, I think there may be something different between this layer of skills versus this layer of capabilities. Or maybe I'm rabbit holing a little bit too much here, but let me ask you something. Go ahead.

Speaker A: How many, uh, other big companies you think, maybe not Fortune 50, but like, what would you consider a significant, a major company with, you know, multiple divisions, large it, etc. How many of them do you think can answer the question how much are we spending on AI this year?

Speaker B: Oh, I don't, I think.

Speaker A: And what number they give you? Would they give you the cost to like open the Azure cloud?

Speaker B: My guess would be accurately. Could they accurately tell you what they were spending?

Speaker A: Tracking it as a category, to be precise. How many attract. Actually tracking it as a category of spend that is distinct and not just some five sums pulled up together and say, this is our AI spend.

Speaker B: Uh, my guess would be under 5%. This reminds me so much, Ivo of the birth of the cloud. When Amazon came to prominence, there was a corporate account. Ah. And I was managing an IT function when this was going on. Right. Talk about the anthropic bills showing up. What was happening in my organization was engineers were going and opening AWS accounts on their credit cards and then expense reporting back all of their AWS charges every month on through company expense reports. And we had no idea how much we were spending. Amazon came back to us and said, do you know that you're spending blah, blah, blah, every month on a cloud services? And I looked at the corporate Amazon account. I'm like, what? Like the corporate Amazon account, it says a thousand dollars and you're saying, uh, uh, $10,000. It's like a function of 10x. How is this possible? Well, here's all the people with your business domain who have signed up for personal AWS accounts and that are spending on a. It's exact same things happening now with AI.

Speaker A: Yeah. And exactly. And also so you have basically central AI driven by the, I don't know, cio, cdo. Then you have the shadow business department AIs that are really critical. I mean these guys are actually doing the work. Then you have the unaccounted for external vendors and whatnot and products. And should we consider this? Should we not? But actually we got it because of AI. Does it count? Does it not count? Then you have the use case build out that you're doing. Then you have these data products that you somehow never package in, uh, under the AI stuff. Because you have to get them approved and otherwise, you know, boards don't get excited about it. And so it's very tough. And I've seen some company companies are thinking uh, of moving to a more structured approach to tracking this. And the difficulty is that it's in the previous era where companies had significant spends on machine learning. Uh, and I'm thinking major manufacturing corporations, they actually had a person from controlling and accounting, uh, sitting in it, just doing that, just like doing it not as a software doing it, not as um, a gentic, uh, infra, but like an actual human that is just tracking spends on these machine learning projects. Now with the AI, the confusion is even higher. And I think what Borzo require and ultimately shareholders will require in the market is to say if you guys, if you're a large company, we expect the CEO and the CFO to commit a large amount of money to modernizing with AI. We want to know um, how it has to trickle down to every individual person and project level that has to get tracked and somehow pull back into the accounting systems, into the daily operations of the IT is doing that in order for you to show that you're doing savings, that you're improving capabilities or increasing revenue. Right now, um, we, I think we're quickly reaching the stage where just storytelling and feel good use cases is not relevant anymore. Right. Well, I mean there's actually, but there's uh, we can talk about where's the caveats in how this could go astray on a macroeconomics perspective. But on individual company perspective, it makes absolute sense to do this, to do this correctly and honestly. Uh, and uh, I think we'll see also some of the big software vendors implement functionality that would support this ROI view of things in order to stay relevant, even though they somehow got in as a vendor, they would have to do this, a better job at showing the uh, roi.

Speaker B: So in my experience this uh, is a message to data leaders. In my experience, and maybe you're listening and maybe your experience is different. It's just that in mine, and this is, this is real gray hair here my friends. And if you're just listening, you're, I'm poking at my increasingly white head. In my experience, if you as a data leader or any IT leader, it doesn't have to be data. Um, uh, I, I was running an IT function. I was, you know, acting cio. If you don't manage your costs, your costs will be managed for you. That's, that's, that's my experience. Meaning that if this AI Thing gets out of control and, and the, the tokens start flying out the door and the car cost going up, up, up and there is no story there around value. There is no story being told. Maybe it's enough to just check a box and maybe your board will give you a year, maybe your board will give you two years because maybe you have checked the box even if it's net negative roi. But my, in my experience, if you're not managing the cost, the cost will be managed for you. And this is why I'm actually seeing more and more, more and more AI functions. Not a lot of, but, but greater than zero. Get getting folded under a uh, CFO for this very reason. Oh yeah, yeah, to manage a lot of these costs. So this, this my recommendation here, something I've been saying consistently for the past couple of years is hire somebody who knows numbers. Hire and, and evo. Like you're basically saying, take a portfolio management approach here. Manage this as a portfolio, stand up, in essence a PMO like function to get your hands around all of this spending. Because if you don't, it will be done for you. What do you think about that?

Speaker A: Uh, I think you're onto something here. Um, I am also, uh, I have also this management accounting background and I um, sit on the U.S. uh, Institute of Management Accountants board. And the discussions that I have with a lot of companies with management accountants is that they're also, I mean they're wondering, uh, in a traditional economy like if, let's say if you're producing a product, you have a fairly good grasp of how the cost structure is. Fixed cost, variable costs, overheads, attribution, all of that stuff is actually done in a pretty solid way. Once it comes to data and AI, there's no rigor in doing it the exact way for various reasons because it's a bit more technological rather than physical products and bill of materials because the frameworks, the technologies, the methods keep changing. You uh, know so many things are, you know, make versus buy. There's so many things that flow into understanding the economics that it's, it quickly gets, it quickly gets too complex. But I think now we're going to enter the era where the management accountants will get more involved into the data projects. So the CFO function as you allude to, will get more involved. And it's going to be a collaboration with cio, cdo, cto. Whoever runs the technology show based on the industry is going to be, well, either working for or with the CFO in a more detailed and more rigorous uh, way than they did before because you're going to have to show results and not just capabilities. So uh, that automatically makes it uh, more uh, financially exposed. The token economics you alluded to is one example. But it's not just right. It's the life cycles of the products, it's the risk decision. I think was something we didn't mention so far, but it's definitely top of mind for especially the regulated industries. They're looking at all of that and they're like if I'm a bank, well we have cash for the projects. We're not worried that we're going to go over budget on the projects as much as we're worried that we're going to mess up the risk surface area in terms of introducing either something that messes our results, that is not accepted by clients, that is not accepted by regulators. I mean the risk component is a huge one for many organizations. Uh, and there's also a third option for organizations that have a huge uh, R and D basis. They're neither worried about cost nor about risk. They're worried about how do we get the most verifiable bang for our buck. Uh, investing in AI spend and data projects in this new era. So um, each one of those are going to have to settle into some sort of a value proving world that they just weren't doing right now.

Speaker B: Two roles that I've been saying consistently and I will continue to say product management. Right? Because Kizivo, what you just said, I mean I think you could argue in very large companies for a PMO type function, product management or uh, project management office with professional project managers who are managing all the Gantt charts of all the deliverables and everything that are helping do the cost basis up front, that are helping do the analysis upfront. For very large companies, I think that makes sense. But if you're not in the Fortune 500 but you're running a data function, I think a product manage, not a project. A product manager can be a huge help here because they know things like lifecycle management, they know things like doing business cases, building ROI analysis or whatever your preferred financial metric is. Maybe it's tco, it doesn't matter. Uh, but product managers are skilled at this stuff, right? Plus having somebody who knows the numbers, right and who can help you build these models using tools like EVO is built using, using insights that are out there. This is, this is possible, right? This is not theoretical. I would argue this is absolutely, in 2026 what we just described. Good portfolio management, right? Good Product management, good project management and good financial management. It's two people. I, I think, I think you could get away with two people. That's, that's, that's what I think. Let's, let's finish the conversation. In this idea of, of you know, AI and maybe building. I, I'm really attracted now to this idea of like building this library of skills, right? Like building, building out as, as my new AI services layer. Like I've got, I've got a bunch of skills, uh, like you customer diligence or, or supplier due diligence or

Speaker A: name

Speaker B: a skill AI as as infrastructure. So when it comes to AI as, as infrastructure or architecture, that's something you said often in your substack. This kind of AI is architecture and not capability. What does that mean to it, to a cdo? Does, does, does that mean how do I go about this, looking at this as architecture and what benefits does it give me?

Speaker A: Okay, so um, go ahead. What you need to understand is that uh, the architecture component is even more important now. And. What's behind us is the decision what is a good architecture that purely, it's just the best technologically. And now the question is what is the best, uh, architecture that is the most adaptive, that is the most financially viable and that is basically architecture, uh, is a financial variable rather than a pure technology discussion. Of course it is a technology discussion, but you view it through additional lens. And I would actually go ahead and from various project managers question the financial rigor for many product managers. I would suggest to improve it because um, if you're taking decisions on architecture, you can miscalculate and misallocate a huge amount of money um, compared to what any procurement department might save you by just being great negotiators. So all of a sudden that architecture decision is, has implications. It always had, but it always was a longer time span. It didn't change all that often. You could do all of these RFIs, RFPs, you could have multiple gates of making sure that you're uh, insured against a bad decision. Right now with the quickly changing technology aspect in data and AI, um, uh, just really reinventing your architecture if you will. Um, uh, you know, where needed is a critical skill. Uh, one thing I want to comment on is the product thinking. I just want to um, mention that what you said is super valuable because this data product, the rise of data product kind of uh, coincided with the AI wave and I think it kind of went out of fashion unnecessarily. I think um, the way that we view it is that you need to marry them together. The data products list with the AI and I know the discussions, if we were to having a nerdy discussion about the semantics and be really pedantic about what we mean by data products and what that we could spend another five hours doing that. But the point of the matter is that if you have responsible people for products, they act differently than just um, a collection of highly capable technologies that want to get the best architecture possible. In fact I'm telling uh, some of my clients that uh, where they need this portfolio steering lens and product thinking lengths the most is the bigger companies that had a lot of architects. So it's a function of if you have a lot of people that want to build great uh, and complicated infrastructures, this is where you actually have a problem with the cost. Not if you have very little capability there. You tend to be way more pragmatic and way more focused on what's really relevant than if you just have like uh, five enterprise architects uh, in the CTO function. And so it all plays together. The point from, you know, uh, from the article that you mentioned that Mario, uh, and I wrote for uh, Bill Inman's substack was that you need to treat this architecture decisioning with financial lens. Uh, and our uh, suggestion to this is most companies start feeling some sort of a private equity type environment pressure, just in the general sense, even though their financials might be healthy and they might m not be private equity owned. But the same principles apply. Right? You need to map everything to cash. You need to map everything to how you're building out the asset base and protecting equity. Uh, uh, you need to map all the initiatives into what reduces risk. And that was just not really the discipline that both data practitioners and especially software development teams and application development teams used to operate in. We're very um, eager to see how the industry develops. I think there's never been a more exciting time to be in it than it is today.

Speaker B: Could not agree more, could not agree more. So I love the idea of managing a data function. Like if you were at a PE firm or maybe even a VC firm where this is a capital allocation question. Right. I've got certain amount of capital that I can deploy and how do I deploy that and looking at taking that approach to your investments in AI, I think if we did that we'd be a lot more efficient, we would be better at prioritization. Uh, I think we'd move a little faster perhaps. So I love that perspective. Uh, I can't avoid the discussion on data products.

Speaker A: Let's click on that if we get a little bit of time.

Speaker B: Yeah, we do. I have a little bit of time. But uh, I'll be honest, Ivo, at the beginning, during all of the hype around the mesh, I was not a big believer in data products. And that's because most of the time people referred to data products through the lens of scale. If you asked the question of why should I do a data product? The answer was so you could scale your data function. And there's plenty of books out there. Some friends of mine, P10 Strengthhold, talks about this in his book of um, data management at scale. Uh, Andre Aguya talks about this in his book Managing Data Products. Excellent book by the way. And they talk all about scale. And I come from a product management background. I'm like, well that's very internal and who cares about that if our customers aren't happy? This should be about customer success and customer happiness and customer enablement and driving value. Hard stock products should be about driving value. As it turns out, we're fast approaching a world where our customers are agents, they're robots, right? And the robots want data products, they want data contracts, they want SLAs, they want, they want automated governance policies, they want metadata, they want lineage, they want all of it in this packaged thing that they can consume very quickly in a machine readable format. Well, they, they. So I was always right and so were Andre and P10 and everybody that was talking about products for scale. We were both right. Because if your customer is a robot, you have to build the data products. Right?

Speaker A: Right, Absolutely. But let me unpack a few things about how we, by writing the vein loop framework, approach this and say we look at all that literature and it's all valid, it's all absolutely 100% true. But uh, our view on things was, and it's similar to the Gartner quadrant to say if I come into a company and I want to see what are your data products right now I want them mapped out on a quadrant and I want them mapped on a quadrant that I can see where the access that we talk about were. Feasibility and impact. But the feasibility and impact are kind of multi determined by 70 factors. So it's not, you know. How do you define feasibility? Well, we have to build it by aggregating a bunch of information around anything data related like data quality, data freshness, data readiness, infrastructure, capability, people, teams, risk, uh, many things. Impact. How do you measure impact? I mean, is it just roi, is it just improving Capabilities. If you want to do data products with all the bells and whistles that you mentioned, with contracts with, with SLAs, I mean building a data product like that is not free. Uh, you can build a simple data product. You could build like a serve procedure and a view and then. Data product, Is it a data product?

Speaker B: Love it, love it.

Speaker A: But if you add all of the thing around it to make it a product, well then the economic shift, is it still worth it? Maybe. Show me. And so, um, if you map them out, if I wanted to invest, um, if I want to be sitting in a committee and deciding on whether I should fund these data products or those data products, I don't want them to be bringing me slides, uh, and saying, we figured this are the five greatest data products, they will scale like crazy if we only spend like another million building them out. What I want to see what's the decision on the margin and how, how would these cores move. And so that's at the same time very technical and nerdy if you wish. But I figured if we were to be uh, a more, if we were to take a more detailed approach into what would it actually take? This is what we came up with. And so the idea to rank them in a garden similar quadrant and have your data products visible. There is a different qualitative discussion. If someone is saying, well, actually we thought that this scales better or produces a better result. And then you can say, well, let me see all the 50 assumptions that are built in there and I can tell you why. If you believe any of them is wrong, uh, then let me know. We can adjust it. But people seem to be. The disconnect between the board level decisioning on this data stuff and the actual teams has always been crazy. No one ever talked about it that much because it makes them look bad. But it definitely is the case because the board doesn't understand that some of the stuff that's being promised is not feasible. Not immediately feasible, not feasible if we do everything all at once feasible. And so, um, I think that was kind of missing in the data product discussion.

Speaker B: Everything you talked about is portfolio management, right? Like the idea of evaluating spends on the quadrant. Feasibility, impact, cost. That's how a board thinks. You're absolutely right, it is how a board thinks. And we need to do more of that. Ivo, my friend, thank you. It's a great discussion. Um, if you are not connected or following ivo Sokolov on LinkedIn, you should be following him. He's brilliant, as you could tell. You should absolutely check out his book. And I do need to make an apology to Mario. I called you the author of the Finance Great Data and AI products. You're the co author. So thank you, Mary. Thank you Mario for your efforts on the book as well. Check out the book, check out Evo on LinkedIn. Check out his substack as well. He's got some great thoughts there with that. Uh, Ivo, thank you for joining today.

Speaker A: Thank you, Malcolm. Thank you so much.

Speaker B: Thank you. And if you have listened this long, please take a moment to like to subscribe to join this growing CDO Matters community. We do this every two weeks. I'm creating content for CDOs and people who want to be CDOs and hopefully you find it valuable. With that, I will see you on another episode of CDO Matters sometime very soon. Bye for now. Thanks, Ivo. Cheers.

Speaker A: Bye. Bye. Ciao.