Transcript:

Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. Today, “Buyer’s Block: Why Your B2B Analytics or AI Products POC Didn’t Close the Deal.” If you’re selling B2B products right now in the software space, obviously, on this show, you know we’re talking about analytics, insights, automated intelligence products, you may very well likely have a sales engineer or a sales process that’s involved, and you’ve got some kind of proof of concept or demo, and this POC sometimes goes really well, and you hear customers say, “Oh, this is exactly what we need,” and things sound really promising.

And then the silence kicks in. You go away, that last Zoom call is over, you know, goes to the weekend… and silence. There’s no deal closing. Maybe there’s, “Oh, we’re going to get to it soon,” or, “We’re waiting on legal.” Whatever the reasons are, your product is not closing the deal. Something is wrong here.

And what I want to talk about today is imagining this problem as not being a sales or marketing problem, but instead a product strategy problem. And your product’s design, its user experience, which may involve a user interface—or not; most products have some kind of interface, even if it’s an API, but there’s some type of experience there—that’s just where this product strategy problem becomes visible. Or as you’re going to find out in this episode, it’s invisible, and this is part of the challenge we’re going to get into. So, what is happening in this POC to contract gap? You’re trying to move this thing to a closed-won, and it’s not.

And what kinds of fixes might there be if we approach this as a product challenge and not as a sales process challenge here? And especially if you’re pretty convinced that you have a good sales process, you’ve got good salespeople, they know what they’re doing, and for some reason the deals just aren’t closing. So, that’s the first principle idea to take away today is to imagine this differently, that the job of selling the product is not just on the shoulders of the salespeople, but it rests first on the product doing a good job in the first place, right? So, this requires less dependence on applying this, like, environment of additional people and processes and marketing and enablements and all this other stuff around it that’s ancillary, and it’s trying to make up for what might be an issue with the underlying product itself. Okay?

So, let’s first talk about two jobs. There are two jobs happening here, and I don’t mean people’s job necessarily, but two roles that are, kind of, involved in this here, and I want you to think of the POC process itself, when this product gets into that demo phase and they’re actually trying it out in their environment, that’s only one of the two jobs. And this POC’s job is really to prove that the product can actually do the thing that marketing—your marketing efforts, your positioning, and messaging—said that it could do. And in many B2B situations, especially if we’re talking about high-impact, high-value products that might also have higher costs associated with them, more integrations, things like this, we rely on sales and sales engineering to move this POC forward such that our prospect or hopeful customer can realize sufficient value in a low-risk way before they commit. Signing a contract, though, to actually license your product and operationalize it requires something different of the customer, and this is proof that the customer and/or their whole team can get this value on their own without you.

So, this means alignment across the stakeholder group, willingness for all the humans-in-the-loop to change their behaviors or do whatever is necessary there. This could be operational changes. This could be, we need engineering to build a connector or some kind of pipeline for the product in order to do its wizardry with the data, whatever it may be. Ultimately, the buyers and stakeholders have to earn this—get this confidence that they can get the value out of the product without you and your sales team, your sales engineers, being there. So, the key idea here is that while the POC is closing the understanding gap that’s happening, it’s only closing that for the people who are in the room on these sales calls that you’re having.

So, what happens when you go away, right? Well, the buyer has to solve the rest of this challenge alone. Or another way to think of it is, the product has to continue to do this work, this sales work, through its user experience, which is in part determined by the product strategy and the decision about how should the product work during—what should it do? How should it work during this phase? And so, we’re actually talking about before it’s been operationalized, before it’s been purchased, there is still an experience being had here. What is that experience that the buyer is going through right now? Which may or may not be entirely inside the software, so to speak, right?

So, the imagination gap here. I actually like to think of this as the invisible intelligence gap, and I’ve talked about this before. If you go back to Episode 189, I go much deeper into the invisible intelligence gap. But what happens when we have the invisible intelligence gap? And this is the gap that happens when you have analytical and technical sophistication in your B2B product, but the buyers are not able to easily see this, or it requires that human sales effort for them to realize this value on their own.

When this builds up, when this gap presents itself too far, at this phase in the buying cycle, you end up with what I call the buyer’s block. I think technical founders often assume that buyers can and will connect the dots, but I think they often don’t realize that the product—the buyers aren’t doing this, they’re not able to do this, and the product is not closing this gap for buyers. They don’t realize this until deals are not closing and they can get over this idea that, despite our tool’s analytical sophistication, it’s clearly not working. Something is not working, despite the technology being really good, so what is going on? Well, this is that invisible intelligence gap.

For newer category products—and I’m saying hello, agentic AI everything right now—buyers may be arriving without a mental model for how it’s going to work in their company and their situation, so you are likely relying more on human effort, sales engineering in particular, and salespeople to build this understanding in real time on live phone calls and things like this. And I think when you have a sophisticated general-purpose product, such as some of these agentic BI tools and data-analysts-in-the-box, and this kind of thing, I think that mental work is even larger and you are likely going to end up with buyer’s block in many cases, the wider you’re going with the purpose of the product here. Despite the fact that we can all imagine it gets human work done faster, I don’t think it’s that simple here because I think buyers are aware with all this AI stuff, there’s trust issues, accuracy, data issues, yet not everyone is living in this space, not all our buyers are super sophisticated and technical, they don’t know what they don’t know about this. Many people are still figuring this out. So, you are fighting all that doubt, those trust issues, the doubt, and the uncertainty.

There’s this huge promise out there, but there’s not as many working mental models. It’s not like, say, you’re buying a CRM product. Well, CRMs have been around for what, 30 years, 40 years? Generally, people understand what that is, so you don’t need to be explaining how that works or what it’s going to do. The general ideas for a business are fairly well understood.

So, the moment your team leaves, this invisible intelligence gap can reopen. So, you rely on the champion to resell without you—and usually you have some kind of champion at your target company that you’re trying to sell to—you’re relying on them, effectively, to keep this deal alive when you’re not there. And the product is the other part of that. The product is doing the rest of the sales work, and then the buyer has to make the final purchase decision on their own. Well, you can’t control what the champion is going to say, and you can’t—or do—nor can you control when the buyer is going to buy and whether they’re going to decide, but what you can control there is what is the product doing, what is it affording during this phase of your customer lifecycle? What is happening? That is something you can control.

So, ask yourself, can your product close the invisible intelligence gap without a human explaining it to them after the POC is over? So, during this time, when you’re waiting for them to make a decision, you haven’t gotten the yes, but it feels really good, is your product doing work for them during this phase? Is the product overcoming the buyer’s block?

So just, I wanted to give you a real example from some past client work that I did. And not—this actually wasn’t from client work; this was something that came out of some research that I was doing with people that are in my space, in this B2B analytics and AI space that I focus on, and what I heard from them was that their customers would sometimes tell them things like, “I see so many ways to use your guys’ product, but I’m not sure which is best.” And so, they didn’t sign. And so, capability wasn’t the problem. The product couldn’t close the invisible intelligence gap without the SE.

The customer in this case was being asked to identify some of the use cases, and then apply this solution to those use cases. And this is what I call the Two-Costs Model. You are imposing two things. First of all, there’s the monetary cost of buying the product, so your customer has to whip out some dollars or pounds or whatever money they’re going to use—Bitcoin. Hopefully not. Maybe—the point is, there’s a fiscal cost there, but you also have the effort that you’re asking them to put into to figuring out the best use cases for the product, how the product is supposed to be used, setting up the product—like, hello agent training right now—learning the usability, like, how to actually go through the workflows and all this kind of stuff, or training, as sometimes it’s called, all of this stuff is effectively Tool Time, as Jared Spool would call it.

So, we have two costs: the fiscal costs, and then all this additional effort costs. And one of those big efforts is when we ask the customer to figure out the use cases and then apply the solution to them. That’s a lot of cost and a lot of mental effort that the customer has to go through in order to make a buying decision. And this compounds when you’re positioning—your market positioning—is really wide and you’re trying to sell a general-purpose product. Oh, it could apply to finance, but it also works for healthcare, and it also works for retail and CBG.

Maybe technically that’s all true, but if you start abstracting things and trying to genericize things, and everything’s operating at this abstraction level here, this is all these forms of friction, and we require the user to have to figure out, how do I apply this to my expensive, urgent problem that I have right now that I read about was going to get solved, and all your marketing messaging and things that I heard, it sounded really good. How do I get that magic, right?

So, let’s jump into this. Where is this fixed? How do we close this invisible intelligence gap and help customers overcome buyer’s block? Particularly after we feel like we got the demo, we got them on the phone, the POC got in there, it seems like things were going well, and then stall. How do we fix this?

Well, we’ve already talked about this. A lot of companies, they throw sales energy at this human effort explainer videos, training, and even if you think, “Oh, I can use AI now to do the training,” or, “I can provide a bot that will tell them how to do all this kind of stuff,” perhaps. Maybe that’s a low effort way to do it, but I wonder, are you actually treating the underlying cause or not or are you really just telling them, here’s how you handle the workarounds because it’s not obvious. Here’s how you get through it because it’s not obvious. Well, that means that the underlying situation, the product itself, perhaps has issues.

So, the first principles fix is really upstream. It’s back to the product strategy and the decisions that your product group, your product management group has made. What is the problem clar—what does the actual problem space look like? And does the team have really good clarity about what an outcome, both business and user outcomes, improvements in the lives of the people who will be touching this product, what do those look like? Who is it for, and who is it not for? What should the product do? And right now, with all of this magic that AI is doing for us with product delivery, what should it not do?

I worked with a financial services company, an AI startup, a few years back, working on a tool for institutional traders to convert their chat conversations into actionable trading intelligence. And the challenge was that the product’s intelligence, which was rooted in natural language processing, was really only available as an API. And I think the assumption here was that their target ICP, which was very well narrowly and well-defined as a handful of the world’s largest banks, they would be more interested in the intelligence here versus buying another application. In other words, they have an application stack that their traders liked and it’s the intelligence that was more interesting to them. However, buyers weren’t really buying.

And one of the signals that they were getting in sales conversations was that it was difficult to imagine how exactly this was going to work. Where was this going to appear in their workflow? How would the traders leverage this, keep track of this information, and use it? This was not clear by simply publishing an API for sale. So, they made a decision that we need a visual way to see this.

And so, the decision was made, let’s build an actual UI for this. That, early on, was seen as a sales enablement tool. So, it’s like, give us access to some of your trading chat conversations there, and then we can show you in the POC, you can see what this is going to look like, just one possible execution of it in terms of a user experience through this user interface. And the result here was that the value became much more tangible and required less narration here. And they also realized that a new market segment could open up here as well, which is that some banks, smaller banks, may not want to inherit the engineering costs to figure out how to integrate this intelligence into their existing applications, and instead, for them, having a standalone tool might make more sense.

And this wasn’t currently on their radar because they were very narrowly focused on a very specific ICP who they felt was not going to adopt yet another SaaS product in their environment. So, the three, like, product strategy moves here, let’s talk about these. Make the value visible. And this is partially through the interfaces and the user experience is there, but the point, whether it’s limited to just that or not, the point is making this value visible without live human narration. So, thinking about what is happening in the product when we are not there, when our sales team is not there. What is going on during this period?

And if buyers can’t see it without a human, there you may have a gap. But it’s not really a sales gap. It’s not, we didn’t follow up. We need to follow up again, follow up again, send some more content, send another explainer video, ask some questions in order to keep the engagement alive. We’re not addressing the underlying issue when we’re doing those kinds of sales nudges. And I’m not saying there’s not a role for that, and I have full respect for salespeople out there, and what kind of job that is, and that is an art and a science, but if the product’s doing its job, it shouldn’t require so much of that.

I will also state at this current moment—it’s 2026, it’s spring of 2026 when I’m recording this—if you are entirely relying on a chat-based UI and using large language models in your product, there are inherent discoverability problems that this presents. When we wait for stimulus and prompts to be entered before the system can provide value, this is a potential intelligence gap because you’re assuming that customers always know what they might want to type into the prompt box. What should we be doing? What should we be asking? What could it possibly do?

What’s all the magic stuff that we don’t know it can do? Because AI can do everything, right, so there’s a bunch of discoverability challenges that go with this, and there’s a lot of inflated expectations about AI, so you need to figure out how to make the value visible in the UI and/or user experience without human narration, without sales enablement, and engineering people being in the room to ask all the questions, and to keep nudging, right?

The second one here is to get opinionated about your use cases. We do everything, or we could do it for—this works for all industries, this really wide positioning out of the gate, this is going to lead to buyer’s block in disguise. It’s really that simple. I think, for every product, like ChatGPT and Claude, and some of these foundation models that did come out cross-industry, they are general-purpose tools, there are probably a hundred to a thousand other companies that have also tried to do this and failed. That is not the model that you are likely copying here. And there’s lots of investors out there that are looking for products to move at that scale like that. Those are the exceptions, not the rule. So, get specific, get that sales traction early. Look for repeating problem sets, repeating patterns that your product can get indispensable at solving. Get narrow and specific before you try to go wide.

The third one. Design means designing not just the operational user experience and the UIs that go with that, and I think of an API endpoint as a user interface as well, in this situation. It’s the exposure of your product, it’s how it is exposed to users, but the point is you need to be designing for what happens during this phase between POC complete and assigned contract. What is happening during that phase? Should there be value? Should the customer be getting additional value through touchpoints, through usage of the product? Or perhaps intentional non-usage of the product because they know it’s done its job. So, they’re still receiving value, even if it’s not in the form of usage, they are receiving value.

And how do you know this? Well, because you’ve defined your user experience outcomes. This is how you know. You know what an improvement in the life of the buyer and in the purchasing team, you know what an improvement in their life would look like, and if they are feeling that improvement there, even if it’s through non-usage for some reason, that’s okay. The point is, we have put intentional effort into designing this phase of the product experience.

When we don’t do that, this is where that buyer’s block creeps in. I think of it as, like, they’re sitting in this submarine by themselves, and there’s tons of pressure from the water from the outside, and then there’s cracks in the hull of the submarine, and water slowly comes in, and this is that buyer’s block. It’s starting to slow things down, it’s creating fear, it’s creating anxiety. We don’t want that. Engineers, technical founders, data scientists, designers, a lot of these hardcore product people, especially in the B2B product side, they tend to love to live in the day-to-day feature build out and the operational side of the product, and I think right now my suspicion is that because Claude Code and these Copilot tools feel like they can do so much, we can finally get through all this backlog of stuff, we can finally ship all these features. Even if we’re not sure they’re going to be used, it’s no longer the impediment here.

So, it’s almost like there’s this drug to build even more and to build faster, and the assumption is just keep building and getting it out, and then see if they buy it. And there’s an assumption that there’s no cost to that on the side of the buyer. There’s no cost to the business beyond the token cost. I don’t actually agree with that. The question is, are you closing the invisible intelligence gap as perceived by the buyer? Are you beating back the buyer’s block, or not? That’s what you need to be focused on during this phase of the customer lifecycle.

So, key takeaways here, again, the big idea here is, what would your product look like if the sales engineer was never in the room? How are they experiencing this product, and is it doing the job of selling itself? This is the big idea is addressing the sales problem, not as a sales problem, but actually as a product problem. The POC success is not equal to deal success.

There’s two different jobs going on here, right? It’s you proving the value to them during this POC process and sales process, you’re proving that it can do what you said it could do, but then the second half is, can they get that same value without you being in the room? The product has to sustain this intent to buy when you leave that last Zoom call and you’re waiting for that decision to be made. When the gap isn’t closed, the invisible intelligence gap is not closed, this is when buyer’s block creeps in. The product is not answering your prospect’s real questions without a human present, and sometimes the buyer doesn’t even know what to ask in the first place.

They don’t know exactly how to apply it. They start thinking about all the operational challenges. What, I got to get data engineering to do this? I got to get legal and risk to sign off on this. They don’t understand the value that my team is going to get out of this. How do I show that val—I can see the promise. I can see how this is going to save us all kinds of money. I can see how this is going to make us stop guessing about where to put our manufacturing resources next, or whatever it may be, but the rest of the team can’t see it. We got to close down the buyer’s block.

Fixing this—the last takeaway is that fixing this with more or better sales processes or people might just be more of a Band-Aid kind of fix. You’re not addressing the underlying problem here. So, the first principles perspective here is to get better customer-problem clarity. Understand their problems and needs better through solid product work, good product management, good user experience research, and good design work. That enables your team to close this invisible intelligence gap before it can even open, to understand where the risks and concerns are, not just in the operational stage after purchase, but before the purchase happens. So, in other words, fix the product so it’s doing more of the selling for you.

That’s all I got today. I got in right under 30 minutes, which was my goal. I hope this was useful to you. Check out designingforanalytics.com/podcast if you found this podcast helpful—this episode helpful, rather. I’d love for you to leave a quick review on Apple Podcast, or to share the episode here. Until next time, thanks for listening to Experiencing Data.