197 - Agentic AI Isn’t a Moat for Analytics Products. This is

Speaker A: Do you lead product for a B2B AI company or analytics SaaS and are finding it hard to get product market fit or sales traction in your demos? Or maybe you've got market traction but usage of your product is lower than you'd hoped and you're beginning to think maybe your dashboards, UI and UX isn't where it needs to be to retain crucial customers. Whether you need zero to one design visioning help or a redesign of your existing product, I specialize in helping founders and product leaders at small to mid sized AI and analytics software companies and increase their sales and reduce customer churn by improving user experience. To get a complimentary 30 minute design assessment of your product or situation, head over to designingforanalytics.com contact and schedule a discovery call with me today.

Speaker B: You're 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 principal of Designing for Analytics, Brian o'. Neill.

Speaker A: Welcome back to Experiencing Data. This is Brian T. O'. Neill. Today, agentic AI isn't a moat for analytics products. This is everyone is racing to the same place, chasing a limited set of buyers. So how is your AI for BI product going to stand out? Let's jump in. Customers think that they can build your product themselves. I'm sure you're entertaining buy versus build in your own business at times. And you're probably, if you're selling a B2B analytics product, which I assume you are, if you're listening to this show, you have some kind of commercial interest in getting analytics, uh, and insights, uh, agentic or otherwise, into the hands of customers who will find them indispensable. You are probably hearing about the threat of DIY projects. Let's build it ourselves. And even if they're wrong about that, the customers and your buyers, they think they might be able to do this and maybe they're right. But the real question that you may not be asking is what is your moat right now? So in some ways this really isn't a build versus buy question that's coming into you. If you're dealing with this at the prospect, uh, in the sales stage, the symptom of the problem here is feedback that the prospect thinks that they can build it themselves. That's a symptom. The actual disease that's causing this symptom is that you have no Visible mote, no visible differentiation. It might be there, but the product's technical intelligence is currently either invisible or it's just not signaling the value that you think that it has. So why am I talking about all this right now with you? Well, you know, as of this recording in June of, uh, 2026, what I'm seeing with many of the AI for BI products, agentic analytics products, this whole space right now is a race to commoditization. And so I want to argue that most of what you think is your moat right now is, is probably already table stakes or very soon will be. And so the, the real moat for you is probably hiding in plain sight. I actually did research on about 13 different BI and analytics platforms and products out there, including some new players, uh, and some of the big, uh, older names that most of you, I'm sure, know. And so this is partly, uh, I went out there to see if some of my suspicions here were corroborated, and sure enough, it does seem like they are. And so I kind of want to help you avoid falling into this trap that I think a lot of these products are currently falling into or will be soon. So if you're in charge of your product strategy and you're responsible to make a data product that sells itself, this episode should help you. Okay, so first, let's talk about the moats that aren't moats. Right? Uh, the moat is this idea of your, uh, protected differentiation, what makes you hard to copy, and your distinct value that is both visible and valued by your customers. So some of the moats that aren't better agentic analytics and AI, like, let's face it, almost everyone out there right now is doing AI for bi. We feel like we can deliver better business intelligence experiences through largely through conversational interfaces, when every product in the category is going to ship the same AI for bi, talk to your data, uh, system, agentic analytics, all of this stuff is canceling itself out. So it's not going to be the reason a customer chooses you. And maybe you get in there soon enough. Maybe you have gotten ahead of the pack and we're on lap 15. But the race is infinite. And so even if you're ahead right now, maybe that gives you, uh, some protected status for a little bit, but your competitor probably just demoed the identical thing last Tuesday. This also gets into stuff like semantic layers and ontologies and governed data and shared definitions and all of the technical plumbing that data professionals tend to talk about. I realize that I think the lights have come on that Everyone now believes your source data needs to be governed and believable and it needs to have the right, uh, shared definitions and ontology. All this stuff is finally getting funding because it's obvious now how problems with it surface because of the amplified use of AI. And when you're trying to get factual type information out of these systems, it's much easier to make the case for why all this stuff matters. But that's just the price of admission and it's not a differentiator. On top of this, all of this plumbing does not necessarily prove users will trust or value the solution. It just improves your accuracy and supplies basically cover your ass insurance. And while employees and end users may care a lot about defensibility of decisions, and especially when we start automating these things, ultimately you should be trying to create value. And this is what you know if you're selling into the C suite, they are looking for value creation. So this is a place where users expect one thing, but really executives are looking for value creation here. You don't just get that because you get the plumbing right. The plumbing is foundational to these systems, but it's not a differentiator. And you can get all the plumbing right and deliver a poor product. So it is not the product. It is a foundation for a product that may or may not be valuable, depending on how you design that around customer needs and opportunities. So this idea that better, more and better plumbing is a moat is one that I hope you abandon after this episode. We can also carry this forward. You're seeing a theme here, right around the technology pieces. Frankly, for most of you listening to this, your models and your processing and how sophisticated they are, this is also not a moat. In fact, we're already seeing this with the foundation models in many ways. On a practical level, they're already commoditized. They're all pretty good, especially if you're using the latest versions of all these. And I'm not gonna quote numbers here, cause it'll be out of date by the time this comes to your ears. But I've talked about this for many years here, like more. Better engineering does not necessarily mean you have a better product. So model optimization, analytical optimization, engineering optimization, these things do matter. I'm not saying that they don't matter, but they are not moats. Sophistication that you can't make legible or visible to a buyer isn't going to be valuable to them. Legible here means that they can actually see it. Or I should say more specifically, they can actually Experience the betterness of your AI, of your models, of your analytics. They have to be able to feel it, see it, experience it in ways that matter to them. The technology, the pristineness of the technology. Execution isn't what the value is and it's not the moat. And finally the whole talk to your data capability or integrations with everything, again, all of this stuff I think is going to be table stakes. And it already frankly is. And in many cases I think a lot of this stuff already is so high level, like just to frame this whole section for you. If your moat is something that your competitor can also say in their demo or they can build it out in a few weeks, it's probably not your moat. So what's left? Well, let's talk about it. Let's talk about some moats that hold. Okay? Some things are going to survive here. There will be some moats that survive. So the first one I want to talk about here is proprietary data. So the information itself, not necessarily how you're modeling it and all of that, in some ways the modeling and the processing and all of this, uh, this is fantastic. Fairly cheap now, or at least easy and much faster to copy with engineering, especially with copilots and all the agentic coding going on and this kind of thing. But the actual proprietary information that you have gathered that can be really protected, that can be something that gives you a moat, uh, against your competitors. So you probably know this, this is probably not real, but I think this is something, uh, this is a moat that holds. It's not going away. So let's say that you have a product that helps companies optimize supply chain analytics. Well, again, if you have access to a large volume of supply chain data out there that goes beyond what an individual company has internally and you can use that information to help them do baselining or understand how well they're doing against competitors or whatever it may be. Again, this is where you can't go out and build that the next day because you've done the painstaking work of growing that data moat. So not going to dwell on this one too much. I think a lot of you listening to this probably know this can be one another one here. But you've probably been hearing about this with AI, like what's going to matter when these tools can do so much of information work these days? I literally have a client doing this work right now. And this is vertical community trust and relationships. This company, It's a small SaaS company, they are heavily dialed into, not just dialed in. They are an active member of the community, the vertical, the industry that they're working in. So the founder and the team, they're out at the conferences, they're out meeting the buyers of their software. They know all the big players in the market. And it's not a transactional relationship. There's very much a community feel here. I personally, when I think about the data community, having spoken at many analytics and machine learning conferences and all of that, and going into many, uh, an expo hall and all of that, part of it's the scale. Um, these are usually much larger conferences. But my perception there, having talked to many, both buyers of the solutions, but also seeing it from the vendor and the software product side, which is what most of you are, uh, most likely listening here, it's a much more transactional relationship. There's definitely sellers are actively selling and you can feel that in the room. The buyers, I think, largely are trying to hide the fact that they're carrying around a wallet and that they're even shopping. And it's definitely, I would imagine, um, I'm not a buyer of enterprise analytics solutions, but I would imagine that a fair number of you in that seat probably feel like prey when you're, uh, at one of these conferences. So if you're B2B BI or for everybody, well, it's going to be really hard to develop these kinds of relationships and to build trust in there. So I think a founder really getting to know the community there and finding ways to create a product that again, has a distinct value, such that maybe your competitors, maybe you compete a little bit there, but there might be space enough within that section for multiple players to find their own offerings to serve into that community. But the point here is that it's about relationships. And yeah, this kind of stuff doesn't happen overnight and it's gonna require your upfront investment and it's gonna require a lot of giving. But when everyone can build software really fast, I think this kind of stuff is partly what is gonna help people decide. Because you can't ignore the way people feel in the sale. Do they trust the seller? Especially at the executive level, I think a lot of this comes down to the relationships. Vetting the software on technical feature capability and is it safe, is it secure and all that kind of stuff, that's going to fall down to middle management and all that to make sure that they're making the right, uh, investment. But at the highest levels, we're still people selling to people. And yes, I know there's AI, sales agents and all this kind of stuff. But if you're selling a really high dollar, high value, uh, system here, you're, you're probably still dealing with humans in the loop. So consider what access to communities do you have? What relationships can you form? Can you. And this might require you to make a choice about who you're going to serve. Making a vertical choice, an industry specific choice instead of trying to be AI for bi, for everybody. Because that's basically not a choice, that's serving everybody. So again we're talking about moats, uh, that might hold. Where, where can you build a moat when feature engineering is probably not going to work for you because everyone can copy it so fast? Well, another one here is this idea of making the product value go up as more people use it. I love Seth Godin talks about this a lot with building viral products, building products that improve as multiple people come together to use it. The experience gets better. Really just a stupid dumb example of this is imagine a product like Facebook that doesn't have none of your friends are on there, there's no people, there's no other people on there. There's not a lot of reason to go there anymore because the whole thing is that it gets better as more of your community is on there. So let's put this into the frame though for B2B analytics. So Omni is an example here. You do the modeling as you use the product and so over time the organization's knowledge, the organization you're selling into, their knowledge collectively gets better. And so the way I kind of see this is as you're kind of doing the modeling as you go, as someone comes up with uh, a really good, you know, data definition for what customer model for customer churn. They can, an expert can insert that into the collective knowledge. And so the product starts to get better as more people are using it and contributing to it. And this is a little different because it's less about pre planning and building all this plumbing up front and instead thinking about what is good enough now to get things going because you're never going to get it perfect. So the question is what is good enough and can you make it better over time? So they've kind of distributed some of the tax of getting the system up and creating value, they've distributed this over time instead of having a large upfront investment of all of this. You've heard me talk about if you've been listening to experiencing data for as long as we've been going here, which is a long time, Almost at episode 200 here, sometimes, for example, a 60% predictive model is good enough. A 51% model is good enough for a business user to have an edge, to feel confident to make a better decision. It doesn't need to be perfect necessarily. Of course context matters. There are some times when accuracy is extremely important. But most of these numbers are never precise to begin with. They just seem really precise. And that's based on how we're measuring, which has their subjectivity in how we do the measurements anyways. So the point is, are we getting value out of the system? Well, can you make a product that gets better when multiple people are using it? This becomes a product that becomes more indispensable to the buyer and the organization that you're selling into it. And that's a design consideration. Do you lead product at an enterprise SaaS, analytics or AI company and feel like it's time to make some significant changes to your UI or UX that, uh, really needs an outside perspective? Are you trying to give the sales team a simpler UI or POC UX that helps them close those tough enterprise deals? Is your data or AI powerful? But it's also meant that your UI and dashboards have gotten pretty complex. Is retention becoming more difficult with your adoption numbers lower than you'd hoped? Or maybe it's simply time to produce a new vision for your product with some outside help? Well, if the time to get any of these types of help was yesterday, well, the next best time is now. And I want to help you out. Schedule your free discovery call with me now@designingforanalytics.com Go and you'll walk away with some practical next steps to move your design and product KPIs in the right direction. That's designingforanalytics.com go creation. So let's talk about where that goes. Let's talk about user experience. UX as a moat. I think that UX can very much be a moat, even when more of the experience seems invisible here. Because I know a lot of you are probably conflating user experience and user interface design. UI being the visual artifacts, experience being the subjective feelings of the users who are using those artifacts. But also maybe other tools, other products, integrations, bouncing between stuff, real life experiences. Experiences cross over your user interface that sits at a higher altitude. So let's talk about this as a moat. Increasingly, your customer may not be sitting inside of your beautifully designed dashboard or your dashboard building tool. They might be in Claude or some external application that's talking to your product through a backend or Maybe there is an agent talking to an agent, if there's still a human in the loop here. And most of the time there definitely should be, unless we're talking about fully automated systems. But I'm making the assumption most of you are building products that still have human touch points. There is always an experience. And I've also talked about this for many years. You can't not have an experience. Even if you haven't designed an intentional experience, there is still an experience being had. So all of this stuff with AI, with large language models enabling us to do agentic analytics, to have conversational experiences, BI and analytics, the AI is not removing user experience, it is relocating it. I'll say this again, AI is not removing user experience, it is changing it and relocating it. Especially if you're interfacing through with uh, a product through someone else's interface. So the customer is still having experience with your brand and your data, the provenance, the feelings that it gives, the confidence, all of that, even if they're not directly using your interface. So they can still be frustrated, satisfied, delight. And so the question is, are you owning that outcome and are you measuring that and thinking of that as a KPI over time? So why is this one a moat? Why is UX possibly a moat for you and not something that's table stakes? Well, as I talked about earlier, a lot of companies and again I went out and just took a sampling of 13 BI and analytics companies right now, new and old, there's a lot of work going into the plumbing that feeds AI and its capabilities to get this BI type information out. But what I don't see a lot of evidence of, and maybe, maybe it's there and I'm just not seeing it. I have not gone in and done deep dive user experience audits of these tools, but almost what I don't see being talked about here or evident in the marketing websites and all of that is the experience that the AI delivers on their behalf. So is the answer trustworthy? Does it show the evidence and the providence? And if you're uh, when I talk about evidence, I'm referring to my CED framework, which you can get@designingforanalytics.com CED. Does it make the customer look smart to their boss? Does it provide status? All these kinds of things wrap up into a user experience. And most of the effort seems to be on making the plumbing better so that we can make the accuracy of the information coming back from these systems better. But when we're focused on making experiences better, this is Much harder to copy because it's product design competency, not an engineering spec that a machine can just see and duplicate. So trust effectively is becoming the experience. And so the experience may be your moat. I think a lot of people assume that AI is commoditizing user experience. In other words, or you can think of it this way, AI means less UI needs, and so design really stops mattering. But I think AI, uh, actually makes user experience matter more because the experience is partially of your product, maybe partially invisible or unsupervised, or it's happening in some other product somewhere else, and that the agents are blended in here. So it's partially machine, it's partially human. The lines are really blurring here. We can do stuff really fast, but we can do bad stuff really fast too. The tools can get things wrong. Who's to blame? So we've accelerated speed, but we've also increased risk surface area. Risk surface area feels like an engineering problem that we can just tackle with better plumbing. But the companies that win here, I think, won't be the ones with the best models and agents per se. They will be the ones who designed an indispensable experience around all of this technical plumbing. The agents, the data and understanding, the customer, the organization that they're serving and the challenges that they're having. And those challenges are, frankly, are still being discovered right now. As all of this technology moves really fast, the problem space is evolving. So you can sum this up as the experience of the accrued intelligence as a moat. And this is a hard thing to capture, as UX is not the sum of your UI or the digital assets that a machine can replicate. So I just told you about a bunch of different types of moats that I think can hold. Moats that are not just, uh, technical capability or infrastructure improvements or features that can be easy to duplicate. So how can you all take action on this right now? So I'm going to try to make this actionable here. First of all, stop measuring your moat by what your engineers built, and let's measure it by the experiences that we're giving. Right? And experiences help tell us about outcomes, benefits, changes that we can observe and changes that we know what the baseline is such that we can also identify an improvement when we see it. So in order to do that, though, that means you need to go capture a baseline you need to understand. And this could be business, uh, metrics that you need to move, like a certain level, uh, of sales or trying to land a whale client or whatever. There's business metrics business outcomes and there's also user experience outcomes, improvements to your customers lives. So we need to understand where are we starting from right now? You can't make the product better until you know what better is baselined against. If you do all this, I think this process is going to ladder up into your product strategy. It may inform your product strategy or it will tell you whether or not your product strategy and your product currently how aligned uh are they right now? Do you need to change the product or does the strategy need to evolve based on what you learned about what your current baseline is? And your product strategy may be your business strategy or at least it's feeding, they feed each other. So what I want you to see is that if the experience of the customer with these products in the sale and in the POCs and daily use is very much tied to the perceived indispensability of the product. Again I'm going to say this again. The experience of the customer using these products and uh, let's talk about it from the point of sale, the POCs, the demos, all the way into daily use. This is going to be tied to perceived, in the perceived value uh, and indispensability of, of your product. So that's the first one. Get this baseline. Understand what better is. Define better both for the business but also for customers, users, affected third parties. You can't just look at the fiscal buyer, you need to look at the organization, the users and all of that. And those goals may be at odds. And I have a different episode on this in uh, the B2B context, thinking about designing for both VSCL buyers and users. But we need to define what better looks like once we understand the current problem space. And the second thing you can do, this one actually has multiple parts here, but some questions that you can bring to your team this week. So there's three of these. The first one, when a customer reaches your data through cloud or an agent or is never going to open up your user interface, well whose experience is that? And is that experience on the rails that you have designed? Is that an experience that you've intentionally designed or is it a byproduct of what other people have designed? I think you will not be able to control all of this, but you will be able to control some of this. Particularly if you are a data source for another application to consume your insights or whatever it may be. But you should at least be aware of what's happening so you can start to think about how you can shape an experience that you may not Completely own. So whose experience is it? Are you paying attention to it? Is it intentional design choices that you've made? Or is the current experience just a byproduct of all this technical plumbing that you're doing and or whatever your own products, models decided? It's going to be another question that you can bring which of your modes could currently moats that you think you have right now, could a competitor demo word for word next week or in two weeks, cross those off your list as moats and see what's left, your opportunities, moats that you might be able to sit on, those might be staring at you, but you need to cross off the stuff that everyone else can copy fairly easily. If your list is already empty, you've crossed everything off this list. I'm sorry to hear that. But all is not lost. But this is where you can ask yourself, what do we know? What do we have? What communities are we part of? So this gets back to the proprietary data that you have access to community, human connections within a community, such as a vertical. Do you have an experience differentiator that you can lean into even if maybe you happened upon it accidentally? What's something that a well funded generalist can't copy by next Friday? Okay, let's wrap this up. So just to think about the big ideas here, build versus buy. You might be hearing this right now. In the market, customers think they can DIY solutions in house. This is. You can reframe this as a diagnostic. For you, it's not a threat, it's a diagnostic. In other words, it's telling you that what you believed your moat was is actually invisible to the very people that you need to see it. They cannot see the value of your intelligence, your product's intelligence. I call this the invisible intelligence gap. The work that you need to do isn't building more product, more features and all that. It's actually making what's actually defensible and valuable more obvious, largely through experience. I call this translating technical complexity into commercial clarity when everyone has the same AI. The moat isn't the product's intelligence, it's the experience of the intelligence. It's the proprietary data that makes that intelligence useful, usable value, and safe for agents to go do stuff with it. Since so much of what we're talking about these days is about actually making, turning analytics not just into human insights that wait for a human to make a decision, but to actually automate some of these decisions or allow machines to make decisions based on these insights. And that third one is those relationships with the community that you're primed to serve like no one else because you have some kind of competitive edge there that others don't. Maybe you have a combination of community and vertical proprietary data that allows you to serve that computer like that, that community like no one else can. So just to leave you here, if you're the founder of your company or a head of product and you've identified what you believe is a solid moat, but you just, you, you think it's there, but you can't get your buyers or your users to see it, that's the exact kind of problems that I help with. So this is that idea I told you about, translating analytical complexity and technical complexity into commercial clarity. There's a link, uh, on my website to grab a free discovery. Call with me if you need some help. There's no pitching on these calls. This hour is yours to have. We can pressure test what's actually defensible in your product, and that time is yours. If you would like to schedule that one on one with me, you can head over to designingforanalytics.com again, that's designingforanalytics.com go and you'll see a book your call now button on there and you can get on my calendar and we can talk through what your mode is or what possibilities it might be in the future if you need to make some changes. All right, until then, see you next time.

Speaker B: We hope you enjoyed this episode of Experiencing Data with Brian o'.

Speaker A: Neill.

Speaker B: If you did enjoy it, please consider sharing it with the hashtag experiencingdata. 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 designingforanalytics.com podcast.