With GenAI and LLMs comes great potential to delight and damage customer relationships—both during the sale, and in the UI/UX. However, are B2B AI product teams actually producing real outcomes, on the business side and the UX side, such that customers find these products easy to buy, trustworthy and indispensable?

What is changing with customer problems as a result of LLM and GenAI technologies becoming more readily available to implement into B2B software? Anything?

Is your current product or feature development being driven by the fact you might be able to now solve it with AI? The “AI-first” team sounds like it’s cutting edge, but is that really determining what a customer will actually buy from you?

Today I want to talk to you about the interplay of GenAI, customer trust (both user and buyer trust), and the role of UX in products using probabilistic technology.  

These thoughts are based on my own perceptions as a “user” of AI “solutions,” (quotes intentional!), conversations with prospects and clients at my company (Designing for Analytics), as well as the bright minds I mentor over at the MIT Sandbox innovation fund. I also wrote an article about this subject if you’d rather read an abridged version of my thoughts.

Highlights/ Skip to

• AI and LLM-Powered Products Do Not Turn Customer Problems into “Now” and “Expensive” Problems (4:03)
• Trust and Transparency in the Sale and the Product UX: Handling LLM Hallucinations (Confabulations) and Designing for Model Interpretability (9:44)
• Selling AI Products to Customers Who Aren’t Users (13:28)
• How LLM Hallucinations and Model Interpretability Impact User Trust of Your Product (16:10)
• Probabilistic UIs and LLMs Don’t Negate the Need to Design for Outcomes (22:48)
• How AI Changes (or Doesn’t) Our Benchmark Use Cases and UX Outcomes (28:41)
• Closing Thoughts (32:36)

Quotes from Today’s Episode

• “Putting AI or GenAI into a product does not change the urgency or the depth of a particular customer problem; it just changes the solution space. Technology shifts in the last ten years have enabled founders to come up with all sorts of novel ways to leverage traditional machine learning, symbolic AI, and LLMs to create new products and disrupt established products; however, it would be foolish to ignore these developments as a product leader. All this technology does is change the possible solutions you can create. It does not change your customer situation, problem, or pain, either in the depth, or severity, or frequency. In fact, it might actually cause some new problems. I feel like most teams spend a lot more time living in the solution space than they do in the problem space. Fall in love with the problem and love that problem regardless of how the solution space may continue to change.” (4:51)
• “Narrowly targeted, specialized AI products are going to beat solutions trying to solve problems for multiple buyers and customers. If you’re building a narrow, specific product for a narrow, specific audience, one of the things you have on your side is a solution focused on a specific domain used by people who have specific domain experience. You may not need a trillion-parameter LLM to provide significant value to your customer. AI products that have a more specific focus and address a very narrow ICP I believe are more likely to succeed than those trying to serve too many use cases—especially when GenAI is being leveraged to deliver the value. I think this can be true even for platform products as well. Narrowing the audience you want to serve also narrows the scope of the product, which in turn should increase the value that you bring to that audience—in part because you probably will have fewer trust, usability, and utility problems resulting from trying to leverage a model for a wide range of use cases.” (17:18)
• “Probabilistic UIs and LLMs are going to create big problems for product teams, particularly if they lack a set of guiding benchmark use cases. I talk a lot about benchmark use cases as a core design principle and data-rich enterprise products. Why? Because a lot of B2B and enterprise products fall into the game of ‘adding more stuff over time.’ ‘Add it so you can sell it.’ As products and software companies begin to mature, you start having product owners and PMs attached to specific technologies or parts of a product. Figuring out how to improve the customer’s experience over time against the most critical problems and needs they have is a harder game to play than simply adding more stuff— especially if you have no benchmark use cases to hold you accountable. It’s hard to make the product indispensable if it’s trying to do 100 things for 100 people.“ (22:48)
• “Product is a hard game, and design and UX is by far not the only aspect of product that we need to get right. A lot of designers don’t understand this, and they think if they just nail design and UX, then everything else solves itself. The reason the design and experience part is hard is that it’s tied to behavior change– especially if you are ‘disrupting’ an industry, incumbent tool, application, or product. You are in the behavior-change game, and it’s really hard to get it right. But when you get it right, it can be really amazing and transformative.” (28:01)
• “If your AI product is trying to do a wide variety of things for a wide variety of personas, it’s going to be harder to determine appropriate benchmarks and UX outcomes to measure and design against. Given LLM hallucinations, the increased problem of trust, model drift problems, etc., your AI product has to actually innovate in a way that is both meaningful and observable to the customer. It doesn’t matter what your AI is trying to “fix.” If they can’t see what the benefit is to them personally, it doesn’t really matter if technically you’ve done something in a new and novel way. They’re just not going to care because that question of what’s in it for me is always sitting behind, in their brain, whether it’s stated out loud or not.” (29:32)

Links

• Designing for Analytics mailing list

Transcript

Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. Today I’m rolling another solo episode, and we’re going to talk about designing and selling enterprise AI products worth paying for. With GenAI and large language models in particular—which is probably the most prevalent of these technologies right now in terms of what’s going into software product applications—comes great potential to both delight and, I think, damage customer relationships, both during the sale and in the user experience, in the user interface we provide and the user experience of customers.

So, how should AI company founders and product leaders adapt? Between my conversations in my consulting business here at Designing for Analytics and my advising as a mentor in MIT’s Sandbox Accelerator for student-entrepreneurs, I often talk to people that have significant technical skills—they may be coming from PhDs in data science or in the hard sciences—and they’ve figured out an idea for a product or they have a product in market, usually at an earlier stage, and it’s underperforming, usually in terms of sales, it’s hard to close sales, or the customers find it difficult to understand the value of the product, or to get the value soon enough out of the product, or they’ve gotten it into the hands of some customers and they’re finding out people really aren’t using it because it’s a bit overwhelming. For the pre-product crowd, those who are still kind of in the zero-to-one phase of going from IP, whatever your special sauce is, to your first user interface, or experience, or actual marketable product, particularly if you are a technical founder, you’re often trying to figure out whether or not your machine learning models or your AI tech or your intellectual property is actually worth something. So, is there a market for your solution that you have in mind? And you obviously don’t want to go too far with product development if there isn’t.

So today, I wanted to share some of these conversations, all masked for privacy, that touch on this game of finding product-market fit, and why sales demos either may not be happening, or why you’re not converting to customers, or why some of the adoption challenges may happen. And some of this is also about helping you get ahead of problems before you introduce them into the experience of the product. So, as of early-2025, when I’m recording this, adding AI to your software product almost seems like a given now, you know, and where ‘GenAI’ and ‘LLM,’ these labels are everywhere now, right?

So, how will we use AI to make our product indispensable is really what founders are wondering. And it seems easier than ever to experiment with these technologies to increase customer value. The tooling has gotten easier, the compute power is there, there’s so much off the shelf stuff that we can leverage without, you know, rolling models from scratch and this kind of thing. So, if that’s true, then what is making AI products hard to buy in the enterprise? So, I wanted to give a variety of real-world examples of situations that I’ve been in or just heard about.

Some of these are also things I’m predicting that are going to happen—and those predictions may be wrong, but I wanted to share what’s in my brain about this at this moment—and how I’ve advised some of the founders and product leaders who are typically the people that come to me for design consulting help on what to do. So, the first idea is that AI and LLM-powered products do not turn customer problems into both now and expensive problems. So, if you’re like me, you’re seeing AI slapped on everything in product marketing right now, which to me is a reaction to executive leaders that are probably scared shitless that someone with an AI focus is going to eat their lunch with a better product. And they probably should be thinking about that to an extent. I also have yet to hear of a single customer—a business buyer in particular, since I’m focused on enterprise—or a consumer, even in my personal circles, who is making buying decisions based on whether or not something is using AI or not.

So, putting AI or GenAI into the product does not change the urgency or the depth of a particular customer problem; it primarily just changes the solution space. I’m going to say that again. Putting AI or GenAI into the product does not change the urgency or the depth of a particular customer problem; it just changes the solution space. So, technology shifts in the last ten years have enabled founders to come up with all sorts of novel ways to leverage traditional machine learning, symbolic AI, and now we have all the neural network-powered solutions like LLMs to create new products and disrupt established products. And the speed of tech progress here, it’s astounding, as you all know, with companies like OpenAI touting that they now know how to build AGI.

However, it would be foolish to ignore these developments as a product leader. What all this technology does is to change the possible solutions you can create and potentially the depth of the value of these solutions. And what it does not necessarily do is change your customer situation, problem, or pain, either in the depth, or severity, or frequency. In fact, it might actually cause some new problems. I’m sure there are exceptions to this and these are broad generalizations, but as a product leader and a founder, especially as you grow, I feel like most teams spend a lot more time living in the solution space than they do in the problem space, and falling in love with customer problems is obviously integral to doing good work in this space, whether or not you’re using AI or not. So, I want to keep hammering this point that the problem space is not really significantly, I think, being impacted because we have this new tooling and capability.

So, fall in love with the problem and love that problem regardless of how the solution space may continue to change. If you’re selling cybersecurity software, for example, to protect an enterprise’s critical IP and infrastructure, that need does not necessarily increase or decrease because now you can, say, you know, use AI to do more advanced threat detection, for example. You might be able to reduce the time to catch a hack or find more hidden vulnerabilities in the tech stack using AI because you’re able to crawl through all the data in a new way, but these are simply value improvements on the solution side of the coin. And as I said earlier, AI products can even introduce risk and create new problems that status quo solutions don’t actually have.

While your customer, as in the company as a whole, might benefit from your product’s machine learning capabilities, the buyer may only see incremental improvements that do not outweigh the risk associated with changing the status quo for them. More, better is probably a weak strategy for any product, and my prediction is that customer trust—as in the trust of the human buyer on the end of your call—will continue to erode as AI hype increases. You’re probably going to have to work harder to land the sale and the value will have to be even greater to potentially offset potential new risks that probabilistic solutions create inside the user experience. So, the key idea here: keep your ICP—your Ideal Customer Profile, your Ideal Customer Persona—super narrow early on, and stay in that problem space long enough that you can retain objectivity over your solution. And while your competitors and their feature teams will be scrambling to put an LLM into the product, you’ll be hyper-focused on internalizing the customer problem space and delivering a stellar UX and a product, regardless of what the underlying technology and implementation is.

So, why not just let the rest get caught up in all—the coming dotcom bubble number two, or maybe it’s a dotAI bubble, I think there probably is something like that coming, and I think you’re going to be on the winning side if you’re really living in the customer problem space, and you’re not artificially trying to use artificial intelligence as a tool at all costs because that’s what everyone else is doing. And product leaders that are not CEOs, they’re not at the highest tier of executive leadership, that’s a game that you have to play, especially if your leadership team are not technical, and they’re worried sick that someone is going to eat their lunch. It might be time to reenvision your product with AI. I can’t answer that, at least not without talking with you specifically about your situation, but I think that’s part of the role of a good product leader is to make sure that those conversations are staying in check, and that you’re not wasting resources trying to artificially—no pun intended—apply this technology to your product.

So, let’s talk now about trust and transparency in the sale and in the product UX. So, handling LLM hallucinations—or confabulations, as I’ve learned that they really should be called—and designing for model interpretability. So, when I put in intentional effort into improving how to do consultative selling in my own business, one of the key ideas I learned was—this was just not immediately obvious to me—that despite a business being my client, my customer, I wasn’t really doing business with a faceless, non-corporeal entity. People inside my clients’ businesses are the ones spending the money on behalf of the business, so the gains or the losses that the customer’s business incurs whenever they’re making a purchase are generally felt or experienced by the human buyer that is representing the business.

So, it’s easy to think that your enterprise buyer represents the company objectively and only cares about what’s best for their company. Yeah… probably not, right? [laugh]. So, the big point here is that the sales user experience is—I like to think of it, this hasn’t changed with AI products, particularly if you’re in enterprise sales. And I’m really thinking about that right now. I’m not thinking about single sign-up licenses, SaaS products where you can just swipe a credit card and get going. I’m thinking more about large tools that need to be sold through a human buyer. But that experience, I don’t think has greatly changed—if at all—with AI products.

So, let’s say you have an AI product that allows enterprise sales teams to generate better predictive insights on sales deals, and it can summarize lengthy term negotiations that might have taken place over voice, and email, and chat, et cetera. So, we come back to who is the customer? Is it the sales SVP named Vicky? Or is it Vicky’s sales team, her ICs that are hitting the ground, hitting the phones, hitting the email? Or is it Victoria’s Vaporware, Vicky’s company? Yes.

In other words, as a product leader, you need to think about all of these parties, but often, if you focus only on what might be obviously good for the company, you may misunderstand, miss, or disregard what is in the personal interests of both Vicky and eventually her staff, the end-users that are going to actually use this product. And this is especially true if you don’t allow individual users to buy your solution directly online. Again, this is for situations where your product needs to be licensed in from a senior buyer, it’s a longer sales cycle, and this type of thing. So, AI doesn’t change anything in terms of the sale that happens between the human buyers and the sellers. And if anything, it might actually hurt trust or raise skepticism, since I think skepticism is only increasing in terms of data, privacy, AI, the fears people have about AI replacing jobs, all of this is continuing to increase.

It’s probably increasing in tandem with every time there’s a big news drop about OpenAI, or Claude, or one of these other large foundation model providers that comes out with another big article—whether or not it’s true or not, it almost doesn’t matter—but the point is, I think that concern from both general public, let alone more informed buyers who actually understand technology, I think that skepticism will continue to increase.

So, let’s talk about selling AI products to customers who aren’t the actual users of the solution. This is not uncommon in enterprise. So, what are you asking of Vicky and of her staff that might be required to use your AI product? What risk are you asking her to take if she brings your product into her team, and potentially has to remove her status quo solution or process or whatever that is? If you’re asking Vicky to change her process, the team, the workflow, or risk her reputation, you’re making big asks, and this only increases if the company—Victoria’s Vaporware—is a risk averse company already where ‘nobody gets fired for buying IBM.’ The old slogan probably needs to be updated for 2025.

But the point here, the LLM feature in your product could be a delighter for Vicky’s staff, and it could also be a real risk for Vicky and for her budget. Your AI product can also be theoretically great for the company—Victoria’s Vaporware—but it could be bad for Vicky’s personal interests. And that basically means your product is great in theory, but not in reality. A simple example? Let’s say your product requires a lot of integration, data sharing, data pipelines, privacy, going through privacy loopholes, replacing an existing solution, changing safe and established business processes that nobody’s complaining about right now, or something similar, all forms of risk that Vicky incurs to take a chance on your solution.

Or this AI product might be great for Vicky and for her executives upstairs in theory, but getting that value is entirely dependent on what a bunch of constituent actors, Vicky’s own staff actually do in the product. Why? Apart from the usual problems here, such as asking users to switch tools, to incur a learning tax, slowing them down in order to then speed them up, et cetera. Et cetera, there’s also the issue of trust inside the actual product, the actual application, particularly when new forms of AI—GenAI in particular—are involved. If Vicky and her executive management team, also known as the business customer that you seek to sell to, if these people need their individual contributors and staff to use your product before that business value can actually be realized, then that solution has to be designed with trust in mind from the start within the UX.

So, let’s look at that next, how LLM hallucinations—or confabulations as they should be called—and model interpretability impact user trust of your product. With certain forms of machine learning-based software applications, you can expose the model internals and the “thinking”—end-quotes—to an end-user. In fact, sometimes you can even give them explicit controls over some of the features so that they can tune the results that the software application gives them. With neural nets and neural net-driven solutions, you’re effectively locked into this black box experience when leveraging these models. As many of you probably know much better than I do, the number of parameters now are in the billions to trillion-plus range for advanced models like GPT4. In short, this means explaining the generated results is difficult, and sometimes that explanation is either extremely valuable or just helpful before a human user on the end of the software can actually maximize the value of the AI, which effectively means the value of the product.

So, now ideally if you’re building a narrow, specific product for a narrow and specific audience—hello, startups—one of the things you may have on your side is that a solution focused on a specific domain—let’s say insurance claim assessment—that is also intended to be used by the users who have that domain experience—or expertise, say claims adjusters or underwriters. So again, the thing that you have on your side is that if you narrow the solution space, you’re probably also going to—or at least should be—narrowing the personas, the number of people, and the types of behaviors they will exhibit in the product, the use cases that they will do that is also narrowed. And my prediction is that products that have a more specific focus and address a very narrow ICP are probably positioned to do better against those that are trying to serve too many use cases, particularly early in the early to mid-stages.

So, narrowing the audience you want to serve also narrows the scope of the product, which in turn should increase the value that you bring to that audience. So, when you combine AI appropriately into an application UX, often with traditional software UIs, you can naturally limit the possible problem space, which may also mean literally the prompt space, and you may have more control over the UX—all things that are good—such that you can deliver a better experience because you’re not trying to boil the ocean. So, then by potentially leveraging technologies like Retrieval Augmented Generation, or RAG, or knowledge graphs, and incorporating feedback loops, for example, allowing users to correct incorrect model outputs, and effectively helping to retrain the model—your custom models—your overall accuracy score when you’re relying on predictions or generation, that accuracy score can increase while you’re simultaneously building trust with end-users. Narrowing your product scope and audience may also reduce costs associated with using GPT-based models at scale, and in some cases, you know, leveraging a small language model may be sufficient to delivering a sufficient UX for the portions of the product needing things like natural language processing. So, I know one of our DPLC, Data Product Leadership Community members, John Cooke—with an E at the end of Cooke—I’m sure many of you probably know about him, he posts a lot about leveraging small language models, so if you’re not familiar with that, you may want to look into that.

And finally, a narrow scope also may help reduce the regulatory work associated with ensuring your product’s compliance with all the various AI laws that are now coming out. And in situations where accountability matters, it may make it easier to provide a useful audit trail or accountability user experience when that’s required. In fact, there may even be opportunities to make these, like, quote, administrative features—I’m thinking audit trails, accountability, this type of thing—those could potentially become core or secondary value propositions in your product, depending on how often, or how important, or how valuable that capability may be to your customer and their domain. So ultimately, accuracy of an LLM’s response is part of the puzzle with user trust, but ultimately, trustability alone does not make a market viable product and a valuable UX. Product teams and designers need to deliver outcomes, not just features, outputs, and user interfaces.

These outcomes can be thought of in two ways, and you’ve probably heard them before on this show. Product outcomes, also known as downstream benefits that result from the technology and product that you’ve built, and user experience outcomes, so these are improvements to the lives of the people using the product. So again, there are two kinds of outcomes to think about. Product outcomes, or think about this as the business benefits for your company, or actually for your customer’s company as well; and user experience outcomes. So, that’s the improvements to the lives of the people using the product such that they’ll find it indispensable.

So, in the field of product management, more and more teams are familiar with the idea of the quote, “inspired” product teams focused on outcome versus outputs, as made popular by the Silicon Valley Product Group, and Marty Kagan’s work in particular, but in my experience on the user experience side of things, this is still an immature practice, with many design teams, designers, design firms all still believing that their core role is simply to deliver outputs in the form of wireframes, diagrams, flowcharts, research deliverables, and UI designs in Figma, of course. So, ensuring users of your AI product actually experience positive outcomes and improvements in their lives using your product, that ultimately is the measure of whether design is doing its job, and this is not different in the world of AI products.

So, let’s look at the design in terms of these AI products. Let’s dig into this a little bit more, especially around large language models, since this is a very popular technology that many companies are trying to integrate into their solutions. So, probabilistic UIs and LLMs don’t negate the need to design for outcomes. That’s the big idea here. I talk a lot about benchmark use cases as a core design principle, and data-rich enterprise-thick products. Why? Because most enterprise products in particular tend to think about product as a game of adding more stuff over time.

And you can see it in how, as products and software companies begin to mature, you start having product owners and PMs attached to specific technologies or parts of a product. So, I always tend to think of this as, like, they’re attached to a noun, an object, a thing. Figuring out how to improve the customer’s experience over time such that your product becomes indispensable to them is a harder game to play than simply adding more stuff, especially if you have no benchmark use cases to hold you accountable.

So, in a moment, I’ll talk about how this thinking is impacted by LLMs and GenAI-driven products, but first, if you’re not on my mailing list, I recommend you join that designingforanalytics.com/list. I post about once a week there, alternating between these podcast episode summaries and an insight piece, but that’s a great place to get ongoing insights about this topic if you’re not familiar with it.

So, let’s talk about this benchmark use cases and UX outcomes a little bit. If you haven’t been on my list and you haven’t read any of my writing on the website, what are benchmark use cases and UX outcomes? So, when your product lacks benchmark use cases tied to specific UX outcomes that you track as KPIs, it makes it easy to just grow by adding stuff. And the thing is, there’s a cost associated with that growth, and a cost associated with that growth that goes beyond the cost of developing the new stuff you’re adding. And that cost is that you may be making it harder or more frustrating to accomplish the benchmark use cases that are the most important aspects of your product, and that’s why they’re called benchmark use cases rather.

The thing is, if you’re not even defining these benchmarks now, let alone measuring them, then you really have no idea if you’re making your customer situation better or worse. And on the worse side, you don’t know until they decide to cancel a subscription or not renew their license, et cetera. And at that point, you know, now you got the sales team or retention team trying to claw them back with short-term techniques, and price reductions, and special deals, blah, blah, blah, but relying on that is not going to serve your business for the long-term. And I’m not saying you shouldn’t try to retain a customer that you’ve already got, but if you’re running into this kind of problem, or just crickets, lack of use, there are ways to get ahead of this so that you don’t have that problem.

The other option, if you don’t want to wait for this problem, is to define your benchmark use cases. What are the most important, and often this is tied to the most high frequency use cases for your product? And how will you measure that experience or those experiences on a scale of delight to frustration, to use Jared Spool’s terminology. And he loves to draw an X-Y graph, and you know, your Y-axis is your scale from frustration on the bottom to delight on the top. It’s critical for product leaders to work with UX design and research professionals to determine what these use cases are, what the right methods of measurement are for those, and how you’ll react to the data that you get back, particularly if you are adding new features and doing new feature development.

Many UX teams do not lead their product counterparts with a clear experience vision these days and a strategy, and are instead doing primarily this kind of execution and deliverable-oriented work. So, creating UIs for engineering or something, you know, UI-UX assets for product management to show in a demo, et cetera, et cetera. And this effectively puts all the onus for business value creation on you as the founder or the as the head of product. And additionally, while product teams are good at assessing market appetite and viability and understanding regulation, sales, marketing, all those aspects, only focusing on what somebody might buy may overlook what the downstream users might be willing to use. So, if usage of the product by Vicky’s staff is required for this buyer Vicky to see the ROI on the product that she is going to buy from you, then by definition, the user experience of Vicky’s staff should matter.

So, if you can delight Vicky’s staff with your product’s experience, then one of the hardest parts of the product’s leader’s job is now solved: the adoption piece, understanding what the day-to-day or week-to-week or whatever the frequency is of the actual end-users and how this fits into their life and how it makes their life better, if you can nail that, personally, I think a lot of the other aspects of product are much easier to deal with. Product is a hard game period, and design and UX is by far not the only aspect of product that we need to get right. And a lot of designers don’t understand this and they think if we just nail this, then everything else solves itself. I disagree, but I do think the reason the design and the experience part is hard is because it’s tied to behavior change, especially if you are, quote, “disrupting” an industry, or an incumbent tool, or application, or product, or thing like this, you are in the behavior-change game and that’s just… it’s a hard thing. It’s really hard to get it right. But when you get it right, it can be really amazing and transformative.

So, let’s think a little bit. How does any of this change or what does it mean for AI products, so how AI changes—or doesn’t change—our benchmark use case and UX outcomes idea that we’ve been talking about? Frankly, my short position, as of, like, this podcast is that AI really doesn’t change my stance on the importance of benchmark use cases, and the need to define what user experience outcome, what positive outcomes look like for your product. And if anything, these aspects of design become even more important in AI products because of the probabilistic nature of the solutions that are driven by AI. That only increases the more your solution is dependent on any type of software or methodology—and in this case, artificial intelligence—that can be wrong.

So, if your AI product is trying to do a wide variety of things for a wide variety of personas, it’s going to be harder to determine what the appropriate benchmarks and UX outcomes to measure, what these are, what are the appropriate benchmarks and outcomes to measure and to design against? Ironically, though, given the confabulations that LLMs can generate, the increased problem of trust, model drift problems, like, you know, when you’re—maybe because your product is either out of touch with what users are actually doing with it now, where it’s not delivering the promise of the original UX, and the fact that all your competitors also now have ready access to the same foundation models that you do means that your AI product has to actually innovate in a way that is both meaningful and observable to the customer.

So, I’ll say this again: your AI product has to actually innovate in a way that is both meaningful and observable to the customer. It doesn’t matter if you’re using AI to change how supply chain transparency works, blah, blah, blah. If they can’t see what the benefit is to them personally, it doesn’t really matter if technically you’ve done something in a new and novel way. They’re just not going to care because that question of what’s in it for me is always sitting behind, in their brain, whether it’s stated out loud or not. Design and UX, the practices of design and UX provide methods to do both problem discovery and innovation, aka solution work, such that you can remain truly customer-centric instead of AI-centric.

After all, your customer is rightfully selfish. They’re paying you and they want something that will benefit them regardless of how you go about implementing the solution. They’re rightfully selfish because they’ve exchanged money with you. AI is opening the possibility to deliver shorter time-to-value by approaching customer problems from a new perspective, and while there are the aforementioned challenges in developing machine learning and AI-powered products, there is also opportunity to disrupt the larger incumbents who typically cannot innovate quickly, and tend to get more risk-averse the larger they grow. Additionally, while it’s also probably true that the few large companies that have the largest troves of data assets, and mature product, and innovation talent will probably be hard to beat, as a smaller software company, you are probably not really competing with these players anyways.

After all, the incumbents’ huge customer base probably spans a whole variety of customers, and by definition, that likely means that their solutions are trying to satisfy a lot of different use cases and needs. But that breadth, however, is also a weakness that a smaller AI-first product company may be able to exploit, particularly if your marketing, positioning, sales experience, and UX can all come together in a way that makes the value of your AI-driven product completely obvious.

So, some closing thoughts here. At the end of the day, regardless of which AI method, LLM, or services your product uses to deliver its customer value downstream, two things will likely continue to be true: customer value is king, and your products UX will continue to have a lot to do with whether or not customers and prospects can actually perceive that value. So, as such, having a product strategy that is dependent on your product enabling both UX outcomes and those business outcomes will continue to remain relevant, if not even more essential, in an AI-powered playing field. Anyhow, that’s it for today. I’m hoping this was helpful. If it was, I always appreciate folks that leave a quick podcast review, particularly in Apple Podcasts. And again, you can subscribe to my weekly insights mailing list at designingforanalytics.com/list. Until then, stay tuned for more episodes of Experiencing Data.