I’m back!  After about 7 years (or more) of bi-weekly publishing, I gave myself a break (to have the flu, in part), but now it’s back to business! In 2026, I’ll be focusing the podcast more on the commercial side of data products. This means more founders, CEOs, and product leader guests at small and mid-sized B2B software companies who are building technically impressive B2B analytics and AI products. With all the focus on AI, I want to focus on things that don’t change: what do value and outcomes look like to buyers and users, and how do we recreate it with analytics and AI? What learnings and changes have leaders had to make on the product and UI/UX side to get buyers to buy and users to use?

So, that brings us to today’s episode.  Today, I’ll explain why I think model quality, analytics data, and raw AI capability are quickly becoming commodities, shifting the real challenge to how effectively companies can translate their data and intelligence into value that buyers and users can clearly understand and defend.

I dig into a core tension in B2B products: fiscal buyers and end users want different things. Buyers need confidence, risk reduction, and defensible ROI, while users care about making their daily work easier and safer. When products try to appeal broadly or force customers to figure out how AI fits into their workflows, adoption breaks down. Instead, I make the case for tightly scoped, workflow-aware solutions that make value obvious, deliver fast time-to-value, and support real decisions and actions.

Highlights/ Skip to:

• Refocusing the trajectory of the show for 2026 (00:31)
• Turning your product’s intelligence into clear, actionable solutions so users can see the value without having to figure it out themselves (4:32)
• You’re selling capability, but buyers are buying relief from a specific pain point (7:33)
• Asking customers where AI fits into their workflow is poor design (16:57)
• Buyers and users both require proof of value, but in different ways (20:05)
• Why incomplete workflows kill trust (24:18)
• The importance of translating technical capability into something a human is willing to own (30:09)

Transcript:

Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill with a 2026 update. The show’s been quiet for a few weeks, as you’ve probably noticed. I have been publishing this show religiously bi-weekly since it started. I don’t think I’ve ever had a gap in seven years or whatever. And at the end of 2025, I definitely was doing some resetting, thinking about my own business and the trajectory of the show and all of that, so I wanted to give you a quick update on Experiencing Data. I also, fortunately, got the flu on my holiday vacation. It seems like all kinds of people have been sick in the northeast, so that wiped me out as well for a good week or so. I’m hoping all of you are having a decent winter if you are in the same hemisphere I am, and staying healthy.

So yes, let’s talk about 2026. I want to recalibrate what I’m seeing in my work, where I think the most interesting problems are right now, so going forward with the podcast, I’m going to be focusing more directly on the work of founders and CEOs and product teams at small and medium-sized software businesses building analytics and AI products, especially where the technology is strong, there might be some really solid IP or data insights, but selling these products, getting user adoption, or getting customers and prospects to actually see the value, it’s harder than it seems like it should be. So, this means there’ll probably be fewer conversations about internal data product teams challenges and more on the commercial software company side, those founders that are dealing with decision risks, differentiation pilots that stall, and why these data products often fail to translate into something that buyers are willing to commit to. There’s so much going on right now with artificial intelligence in general and trying to apply foundational models to more niched down products, at least in the language model space, this is a very interesting space, and there’s a lot of moving parts here.

And I think design and product strategy are only becoming more important as we try to figure out how do we map these capabilities back onto what never changes, which are customers’ problems, the risks that they have when they have problems, and how they want risk removed, and how they perceive value. These human things never go away. The types of those problems might change, but this is something that as long as we’re still making services and products and selling them to other human beings, this part is foundational and will never go away; all that’s changing is the capability side, so how do we close that gap?

So, if you’re building or leading an analytics or AI product in the B2B space and if you’re wondering why it feels harder right now to get traction, then maybe your company or your technology deserves it, it just seems like it’s harder than it should be. You’re in the right place. This is a channel out there on the interwebs where I want to have these conversations and I want to keep talking about this non-technical side of analytics and AI, and talking about how we meet the humans in the loop, both our fiscal buyers and, of course, our end users, and how closing the gaps on their needs is critical to making all of this amazing technology that I get to see, all the smart founders that I see, so many of them coming from engineering and data backgrounds, highly analytical backgrounds, super smart people with really amazing ideas, but sometimes closing that gap is hard. So, those are the conversations I want to keep having. So, let’s get into it.

First episode of 2026: “Why Powerful AI Products Feel Useless to Buyers Sometimes.” So, AI and analytics or insights products increasingly promise to solve many problems, but customers experience one or a handful of painful workflows at a time, typically. So, in this episode, I’m going to explain why I think in particular, broad AI or data capabilities often can create confusion instead of value, and why I think sometimes companies are mistakenly expecting customers to connect the dots between what’s technically capable and the product with what their actual needs and pains are. And so, this misalignment can prevent you from seeing the business outcomes that you want to have for your company.

So, the core issue, while, you know, accuracy of the models and preventing confabulations and hallucinations and all this stuff, this will continue to be a blanket problem, this is not the underlying sales blocker or adoption blocker: model quality. That will, I think, almost be a commodity that’s out there. And, you know, there might be that, you know, this company’s foundation model is slightly better for this, and this other one is slightly better for that. I kind of see that stuff as eventually becoming somewhat of a commodity. And so, if you’re building on top of those capabilities, simply focusing on that is not going to be sufficient.

The same thing goes for just having more context. There’s a lot of discussions about context windows and how simply having more context is going to fix everything. I do believe that context is really important. I don’t think that’s enough to just simply start to close gaps. So, we need to translate intelligence into a complete defensible decision for users who are looking to buy their way out of a problem space with a software product that’s supposed to do something amazing for them.

So, you know, some of this can apply to those teams doing internal data product work. You know, obviously the difference is you’re not—unless you’re maybe doing internal chargebacks or something like this—you’re not charging your colleagues for these solutions. When we do have to pay for these solutions, we have to get a buyer to pay for this stuff, the quality level has to be much higher, and so I’m hoping those of you in internal data roles can continue to get value out of this show by understanding how this game has to be played. When you really have to monetize these solutions, the level of quality has to be really high. And I’m not talking about code quality and QA testing and all of that. I’m talking about even defining what does quality mean, what does value mean in the eyes of fiscal buyers and end users. This has to be crystal clear, or the game ends.

So, one of the key messages for today. In your product, you’re selling capability, but buyers are buying relief from a specific type of risk or pain that they’re having. When I model this and I talk to my clients about this, I tend to think about it at two primary levels. The first level is your fiscal buyers. So, this is your customers and your prospects and the people you’re chasing down trying to close deals with.

They’re going to usually, depending on how you’re doing it, sometimes the buyer and the user is the same, oftentimes in the B2B context, especially if you’re at the enterprise scale, your buyer and users are not the same. People and fiscal buyers are realizing pains and needs at a management level. They’re looking for, you know, either some kind of increased profits or cost reductions or whatever that tend to roll up as a result of the solution. End users, however, who are often the linchpin, as you’ve heard on this show before, they have pain at the job level, right? They have a discrete job.

A lot of employees are not thinking overall about product or, you know, the company’s valuation and all this kinds of stuff. Some of them are, but a lot of them are incentivized to focus on performing their job properly and keeping risk profile low. And I think that only grows. The larger the company, the more it’s about downside risk protection and less about anything to do with innovation or new value creation. So, we need to be aware of what the interests are of the end users and of the buyers.

And the product, your product, really needs to solve for both. Otherwise, you’re going to end up with either no sale. You have end users that might see the value, but they can’t convince the fiscal buyer—a manager—to invest in the tool because the manager doesn’t understand what’s in it for us as a company or my department. How am I going to justify the value of the expense here? Or, on the other hand, you do let you land the deal, you get the buyer to buy on the promise of what they’ve seen, either through, sometimes this is through fancy demos, or really good salespeople that know how to convince somebody that something’s right for them, or because the buyer doesn’t really understand the workflows and the end-to-end use cases of the people who are actually going to use the solution.

So, what happens is, we get the product into the company, there’s a POC, but adoption is low because end users aren’t able to map the solution onto their problem space very easily. Either it’s requiring too much investment from them, too much thinking, there is risk if they use your solution versus the old way, which might be highly inefficient, but if they’re not motivated to remove inefficiency and there’s low risk continuing to do, you know Excel jockeying or whatever, that might be nice that your tool can replace some chapter of Excel work that they normally do, but despite all the labor involved, that user gets paid for showing up nine to five, Monday through Friday, and keeping a low risk profile is important to them. So, the tool is not making their life any better. You sold something to the buyer, but the end users are not seeing what’s in it for me.

What this leads to is attrition, low product adoption, and concerns that those buyers definitely are not telling other people about how great it is, the word is not organically spreading, and you have a chance of a no renewal, or your POC doesn’t close into a paid deal, if you’re you know, if you’re doing a free demo or POC or whatever it may be, you just don’t close that deal. So, that’s kind of one of the key ideas, is to keep these two different human personas in mind and remember that it’s not just about presenting capability, but it is about offsetting risk and solving the customer’s problem as they perceive it, not as you perceive it, based on what you theoretically could apply your product to, problem spaces you could apply your product to.

So, let’s jump into a few more discrete key ideas here. The first one is, broad AI capability doesn’t map to narrow buyer pain. So, this is, unless you’re a foundation model, you know, and you’re really trying to sell a very general purpose solution here—and a lot of these companies are not profitable; as many of you know, they’re not selling tons of paid-level subscriptions right now—I think this is even more true if you are not owning a foundation model like OpenAI or one of the others, if you’re trying to build on top of this, you need to be thinking more narrow and niche and not broad. AI capabilities, large language models can do many things, but buyers are trying to fix one broken moment, one broken workflow, optimized for one particular area. They are not generally looking for a broad-purpose solution that can do lots of different things, and your solution is thankfully capable of doing all of those.

This requires a lot of cognitive thought for the customer to map back, why would I need this? What would I do this for? And this is not the headspace you want your buyers to be in. You’re going to end up with a lot of tire-kickers, maybe some curiosity there, but they are not living in their problem space and seeing the relief that you can bring. So, generality in your capabilities increases the perceived risk that the buyers and users are going to see, so the value needs to be tightly framed.

This also gets into product positioning on the marketing side, where you might see a data problem that is the same across multiple industries, but when you message and talk about this solution as a general data insights problem that is applicable across all these different domains and industries, the customer is left sometimes trying to bridge the gap here. They’re trying to apply how what you did in your last very successful deployment with JP Morgan, for example, how does that translate to my hospital setting? They now have to do some of this mapping, and if that buyer hasn’t had experience in that, you know, financial services domain, or whatever it may be, then there’s a challenge here because now they’re having to try to map that value across a problem space or a domain that’s not clear to them.

So, the general idea here is that even if there are common workflows and things across the industry, how we message and experience that, if that’s not going to be identical across those spaces and the solution needs to be different, then your product is going to have a hard time trying to look amazing to all of those different users. You probably need to get more narrow and more niche in order to hit those home runs, particularly if you’re early in the product-market fit area, before you try to broaden the scope of your solution.

Like, for example, if we just take this at a very high level, like, software idea, let’s say you’re deciding that you’re going to build a new AI-powered CRM solution right now, and you need to pick a domain here, you might have a hard time rolling out a generic, all-purpose, all industry CRM right now because the needs of a massive enterprise company and a small business of three to ten employees are really different. Now, multiply that times the number of different industries and the different niche things in different industries, and you’ve got a really wide problem space. So, if you’re going to, like, pick something, you can’t assume that just because the data problems are the same between, say, a home services company and a gas and oil engineering firm, that your CRM is going to be right for both of them. It’s true that on the data level, there are still deals, there are still contacts, there are still company objects, some of these very standard CRM data objects. Yes, there’s a lot of commonality across the solution space, but the problems and the experience and the way those customers see themselves are likely very much not the same thing, and if you’re trying to make your solution generically applicable across all these things, you’ve got messaging challenges here about how you talk about it, the level of where the problem is it more at the management buyer level, is it more at the end-user level? What’s the language we talk about this with?

All of these things matter. So, keep in mind the broader you go, whether it’s on the solution space of the product, or even in the positioning of the product, the more you’re increasing risk for yourself and you’re making it harder to sell your solution and find buyers who will have the need, and they will see themselves in the solution that you’re presenting.

The second core idea here is asking customers to figure out where AI fits into their workflow, this, to me, is a design failure. So, you don’t want your product requiring the customer to identify use cases and problems for which your solution could then be attached. If they have to put the workflows together, they have to sit and figure out what the tool is actually good at versus what it’s not good at, and this type of thing, you’ve probably lost the deal here already. And sometimes what I see is companies will try to genericize the tool or start abstracting capabilities because they start to see more—they work with an engineer’s mindset. Instead of making this section or this capability domain and really hyper-specific to this problem space, let’s abstract it out so that someone could broadly apply this to anyone that’s building, say, dashboard reports or whatever the heck it might be.

And as soon as we start doing that abstraction, this is where we create friction for users, and they have to start doing mental translation to figure out, how do I map this capability—particularly if it’s generative AI—how do I map this back to my current problem space? So, customers don’t want potential; they need obvious application. With the effort going into using your solution, this needs to be mapped relative to the investment they’re going to make. So obviously, if you’re selling a, you know, multi six to seven-figure platform style solution, there’s probably a higher expectation that the time to value will be slower, there may be a long deployment cycle and POC cycle, there may be a massive migration involved if you’re replacing an old solution, et cetera, et cetera.

And then, on the other hand, as the price goes down for your solution, the time to value expectation shortens. Buyers expect to see value sooner. So, you need to obviously think about how you are reducing risk early, how are you showing value early? And value can be expressed in a lot of different ways. I think transparency, risk reduction, understanding what it’s like to switch, if you are proposing a behavioral change, a solution that will require either switching from an old solution or perhaps switching from a homemade solution that they’re currently using to solve the problem, or even if you’re asking them to effectively, your solution is solving problems that they’ve never tried to solve before because there was no technology there. The more you can map back to their headspace, their risk profile, how they see value, both on the buyer side and the user side, the more chance that they’re going to make that investment with you.

The third one here is that—and I just want to really restate this one because it’s super important—buyers and users need different proofs of value. So again, buyers need defensibility, they need financial impact, they need to justify the investment, so they’re going to be looking for ways to concretely do that, whether it’s literally expressed in the product somehow, in terms of, here’s some KPIs to show you the value that you got. End users, of course, have this as well. It’s just their proofs of value are different, but both of them have them. Users are generally looking for when we talk about, like, this idea of user experience outcomes. I like Jared Spool’s definition of this, which is an improvement in the end-user’s life. How are we making the end-user’s life better?

This often has to do with making them look good to their boss, lowering the labor, particularly labor that they don’t like to do, not necessarily all labor because your solution might remove labor, but if that end-user is heavily self-invested in that particular label and they see themselves as the reason I’m here, my value to this company is in doing, say, design prototyping, and your solution does automated design prototyping, you are indeed presenting a solution that can remove value at the labor level, perhaps at a level that the management and the fiscal buyer cares about, but your end-user doesn’t care about that because their identity is wrapped up in that. And they may find no incentive for them to start using that solution because you’re taking away their identity, the bulk of what they’re doing right now in their job, and they may be wondering, well, what is my purpose here, if I’m going to start using this tool and it’s going to do a whole bunch of this labor for me, that certainly doesn’t sound good for my job prospects and in my employment. So, we need to always be thinking at both buyer and end-user and how their proofs of value are different. What they each value is frequently different in that B2B context, so you can’t ignore one side only.

And obviously, you know, venture capital-backed companies, things like this, there is constantly this race to show revenue, and I think this tends to drive, despite all the discussion about being customer focused and doing customer research and all this stuff, what’s incentivized a lot of time is showing revenue early. And I think what this does is it ends up, we put out products that give a short term hit, but they don’t get retained because founding teams often are relentlessly focused on what they can convince a buyer to buy right now, but not whether or not that company is going to stick around long enough for you to deliver something they can’t live without, an indispensable solution. So, this is tough, and I just want to say I completely understand that when you’re being funded by outside forces, you have incentives to stay in the game, and you may be thinking, “Well, in order to stay in the game right now, I need to close these deals, and I know that internally, I know we’re going to leave them hanging there.” This is the challenge of startups and small companies and balancing both sides here. So, obviously you need to make the right judgment for your team about, can you afford to say, leave end users hanging in order to close a sale early or do you really need to make sure that your—is your sales channel, for example, possibly going to be driven by end users first, who then will bring your product to their management and say, “Hey, we need this tool. We need this solution in order to do our jobs better.” I think part of this is, how do you go to market and knowing what that path looks like. This is also going to inform for you how you design the product and where you need to invest your resources the most.

The next one is, incomplete workflows kill trust, even if your AI is impressive. So, what do I mean here by incomplete workflows? If we have say, like, a five part task, you know there’s step A, B, C, D, E and F or something—I guess that’s—A, B, C, D, E, F. Yeah, that’s six. See, I can count. I’m a drummer.

Let’s say it’s five steps: A, B, C, D, E. Sometimes, what I’m seeing is that the end users tend to think in workflows and jobs that need to get done, and that job, that workflow, that use case, is A, B, C, D, E. And what happens sometimes is especially with technical founders is they will find a way to massively impact how, say, steps C and D in that workflow get done. We can dramatically lower the effort, we can provide all kinds of insights at stage C and D that they’ve never had before, or we might even add a step here that helps them make a downstream step even easier. The problem is that oftentimes the customer is thinking about the overall workflow there, and they’re not necessarily thinking about individual steps within it and about how your solution might dramatically impact just one stage of that.

So, when we don’t think—and it’s not to say that your solution necessarily has to always be A to E in order to provide value, but I think when you understand how your solution fits into that workflow, you understand what’s happening before it, you understand what’s going to happen after it, and you understand what the users and the fiscal buyers care about, then it might be possible to create a viable company and a valuable product that will sell that only is addressing one of those stages. But more often than not, I see a lot of technology investment that’s simply focused on one of those stages, and it’s not thinking end to end about what the user needs to do next, and when the user perceives the pain has been relieved or the risk has been reduced. So, you know, a simple example of this might be something with analytics and insights. You’re providing these insights, but as many data experts know and people listening to this show, our job, we don’t really want to be in the business of simply providing vanity analytics. ‘This is what happened in the past, and here’s a prediction about the future.’

Ultimately, insights are about helping people make decisions, course corrections, changing where they’re going, providing evidence to back up decisions in the real world. When your solution doesn’t seem aware of any of those solutions, there’s no feedback loop into those decisions, and it’s completely abstracted out. It’s like we’re just at the insights layer, but we don’t have anything to do with the decisions and the operational part of it here. This is an example of where there can be a gap, and so maybe the user needs to understand what are the ramifications of accepting the advice of your product that’s delivering these insights that we’ve never had below. Is there a way for me to monitor what happens if I accept them or I don’t accept them?

The point here is that simply having more information may not be sufficient for them to feel that the value of the solution was actually delivered, and the ROI is there because you spent a lot of time on just one or two stages of the problem, but it doesn’t map neatly into that five step workflow or whatever that the customer has. So, we need to be thinking horizontally. I really push my teams to, in order to get out of the feature orientation and to get more into the value and outcome orientation, you need to be thinking linear linearly, or you need to be thinking temporally. These product and experiences happen over time. Workflows happen over a timescale. There is supposed to be an outcome, an observable change in the world that matters for the business and for the end users. This happens over a time period.

This is a very different approach versus thinking about our job is to ship this output, this static thing that happens right now. It’s not something that’s experienced over time; it’s not part of a workflow; it is a technical capability delivered with analytics and/or AI. This is a very different model because thinking about deploying a thing versus owning the outcome or the change in the world that we want to see, which means your thing, plus the proper context, plus possibly other things, other products, other tools, other solutions, offline stuff, online stuff, whatever it may be, being aware of how your solution fits into that workflow. When you have that, when you can either solve the whole workflow or you can make the entire thing better, even if you don’t cover the whole gamut of it, this is where you’re going to have more traction because you’re not going to be feeling like you’re delivering an island of value that’s kind of isolated and it requires all this bridging to happen on behalf of the customer in order for them to realize that value. So, incomplete workflows kills trust, even if your models or your AI is really impressive.

And the last, like, kind of core idea today is displaying the product’s analytics or intelligence isn’t enough. We need to translate technical capability into a decision or an action that a human is willing to own. So, we’ve sort of talked about this idea that shipping capability alone and presenting technical capability with a product, this is not really what buyers want to buy. We need to translate this capability into decisions and actions that humans are willing to make and they’re willing to stand by. So, the best way I can think of to explain this is, like, this idea of, like, a translation layer.

So, are you putting effort into your product to ensure that when we display intelligence, automation, whatever it may be, powered by data, analytics, AI, when we’re doing that, are we also putting effort into ensuring that we’re translating that, we’re designing this in a way that the customer can inherently understand how it maps to the problem space that they have. Their workflows, their problems, the risk that they see in the world, can they understand that or not? It’s not enough to just stop at the intelligence output; we need to think about the translation part as well. When we don’t have this, we’re pushing hard work onto the customer. We’re putting cognitive—what UX people would call it cognitive load. We’re putting a lot of effort, mental effort on them to close the gap here, to figure out, how does this model or insight or KPI apply to my business? How does this automation help me safely do what I want to do without introducing problems that I don’t even have right now or I’m afraid of emerging because of all the things that I’m hearing about, what can go wrong with AI, et cetera, et cetera.

So, when customers hesitate or deals stall, we often call this a sales problem. I think some of these sales problem—the problem with that is like, if we just adjust how we talk, just how we talk, or how we do our outreach or cast our fishing lines out into the world as a sales problem, this isn’t addressing the underlying issue here, which might be, there’s a design or a product or experience problem. There’s a translation that’s missing, and we’re trying to address it by changing how we talk about it on the sales side, but ultimately, this is kind of a bandage approach because the underlying issue isn’t there. We’re relying on that human sales person to try to do this translation for us.

It would be much easier if the product did all this itself, and the customer isn’t even thinking about translation. It just makes sense, it’s simple, and it maps logically to their worldview. All of a sudden, this is not even an issue. This is not even a discussion point in the conversation. We are not having to translate anything here. So, a well-designed product doesn’t just expose intelligence; it’s going to constrain it, it’s going to frame it as to what matters and what doesn’t, and it’s going to focus on this—particularly with analytics—with this idea of action and decision support and buyers won’t have to focus on trying to grok it or get it because the value is obvious.

All right, so those are pretty much my ideas. That’s what I wanted to tell you about today. You know, if your data product right now, your commercial data product, requires imagination to see the value, then you’re really selling potential, but you’re not selling outcomes. You’re selling capability, but buyers are trying to buy relief from risk or pains or problems or labor. They are not looking for capability; they’re looking for reductions in these things that I just mentioned here.

Sometimes they’re looking for things like status and insight to look better, to look informed, and this is a place where insights come into play. But the point is, having that frame of being empathetic towards customers and buyers about their problem space versus your capabilities, all the different things that the product could do, your technology, your data, the modeling, all that kind of stuff, there’s two different frames here. I want you operating as much as possible in that empathetic thinking about buyer and fiscal, thinking about end user and their jobs and their incentives and all of that, and trying to live in that headspace as much as possible instead of the solution space. Buyers, again, just to restate, they’re thinking about pain at that management level. They’re thinking about defensibility of the investment. Can I defend the expense of this solution really easy to procurement or to my management, or whoever.

And those end users, they are typically less focused on the overall business’s trajectory and all this kind of thing. They tend to be risk averse, they want to focus on doing a good job, they are usually trying to satisfy their management, or manager even more specifically. So, just because you can technically do something doesn’t mean it will be perceived as value to that end-user. So, it’s not enough to go and automate things or remove labor from workflows and just assume that both buyer and end user will see value in those types of solutions.

So, that’s my takeaway for today—or those are my takeaways for today, and the insights. I hope this was helpful. Please, in 2026, I try not to beg you for reviews and things like that, but this podcast has become one of the top 2% of podcasts in the world, according to Listen Notes. I would love to push this into that 1% category. My goal is to do that in the next one to two years. That's a huge change. If you look at the distribution of shows, that’s a massive jump. Your reviews can really help do that. So, if you head over to designingforanalytics.com/podcast, I do have a quick little visual guide on how to leave an Apple Podcast review, or wherever you listen to the show, it tells you exactly where to click and do that, so a quick rating and review is really appreciated.

I also know and want to thank all of you who have shared my podcast with founders and leaders, some of you that are living in the trenches, trying to have the impact there and spreading this to your colleagues in your space, to your managers and things like that, and your executives. I really appreciate that sharing. That knowing when the sharing is happening is the biggest validation for me that these ideas are helpful, that there is a space to talk about the importance of design and product in this more and more data-driven world that we’re all living in, powered by AI, now. So, thank you so much for all of that leading up into 2026 and I hope that will continue. So, feel free to leave me feedback if you want. You can always reach me via my website, designingforanalytics.com/contact. Feel free to drop me a line there if you’d like. And until next time, thanks for supporting Experiencing Data.