Transcript:

Brian: 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 and insights, 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 might 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 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 moat, 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 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 probably already table stakes or very soon will be, and so 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 and some of the big older names that most of you I’m sure know, and so this is partly—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, the moat is this idea of your 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 largely through conversational interfaces.

When every product in the category is going to ship the same AI for BI, talk to your data 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 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 you know your source data needs to be governed and believable and it needs to have the right 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 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 going to quote numbers here because 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 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, this is fairly cheap now, or at least easy, and much faster to copy with engineering, especially with Copilot 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 against your competitors.

So, you probably know this. This is probably not real, but I think this is something—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.

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.

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 an expo hall, and all of that, part of it’s the scale. These are usually much larger conferences, but my perception there, having talked to both buyers of the solutions, but also seeing it from the vendor and the software product side, which is what most of you are most likely listening here, it’s a much more transactional relationship. There’s definitely sellers who 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—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 [laugh] 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 going to require your upfront investment, and it’s going to require a lot of giving, but when everyone can build software really fast, I think this kind of stuff is partly what is going to 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 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 system here, 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 that might hold. 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, you’re kind of doing the modeling as you go, as someone comes up with a really good, you know, data definition for a model for customer churn, 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 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, and 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.

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 back-end, or maybe there’s 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 with a product through someone else’s interface. So, the customers still have an 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 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 what I don’t see being talked about here, or evident in the marketing websites and all that, is the experience that the AI delivers on their behalf. So, is the answer trustworthy? Does it show the evidence in the providence?

And when I talk about evidence, I’m referring to my CED framework, which you can get at 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 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 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 design 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 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 metrics that you need to move, like, a certain level 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 the 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 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 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 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 the perceived value and indispensability 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 the B2B context, thinking about designing for both fiscal 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 Claude 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 moats—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. 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 of 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 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 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 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 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 and 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/go 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 moat 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.