I’m digging into a frustrating reality many teams face: even technically superior analytics and AI products routinely lose deals—not because the KPIs or models aren’t good enough, but because buyers and users can’t clearly see how the product fits into their day-to-day work. Your demos and POCs may prove what’s possible, but long time-to-understanding, heavy thinking burden on the user, and required behavior or process changes introduce risk—and risk kills momentum. When value feels complicated, sales don’t move forward.

Adding to the challenge is that many sales efforts focus almost entirely on the fiscal buyer while overlooking the end users who actually have to adopt the product to create outcomes. This buyer–user mismatch, combined with status quo bias, often leads to indecision rather than change.

To address this, I explore the idea of thinking about the sales challenge as a product problem—and I introduce the idea of achieving Flow of Work Alignment (FOWA). The goal isn’t better persuasion—it’s clearer value. Strong FOWA means transitioning from demonstrating capabilities to helping customers see themselves—and their workflows—represented in your demos and POCs. The result? Prospects understand your value quickly, ask deeper, contextual questions, and deals move forward.

Highlights/ Skip to:

• Data products must work harder to expose value clearly to avoid the dreaded “closed-lost” deal stage in your CRM (1:38)
• Making your data product’s value instantly obvious (5:18)
• How the “old model” of selling based on capabilities and feature demos can lead to lost sales (7:22)
• What  Flow-of-Work Alignment is and how it can help you unlock deals (13:02)
• How to know if you have achieved FOWA or not in your product and sales process (13:58)

Links

This is a 2-part episode. Listen to part 2 (episode 188).

Transcript:

Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. One of these days, maybe I’ll do the podcast in a different language, if I can. But of course, I won’t need to because AI will do it for me, right, just like Brian sounds? I don’t know, maybe one day. It’s good to be back.

Today, you can’t close the sale? The invisible reasons prospects aren’t buying your technically superior analytics or AI product. If you’re leading a product right now that has a revenue or a sales cycle pressure, and despite your analytics or AI tech being superior, customers aren’t buying your software, well, today’s episode is for you, if you’re in that situation. So, let’s get right into it. Some of the key points I want to make today: technically superior analytics and AI products lose deals when prospects can’t picture themselves using the solution and their day-to-day workflow.

You know, demos and POCs prove capabilities, but deals sometimes stall because of workflow fit and the time to understanding by the user or the buyer, this hasn’t been achieved during their evaluation. Or, I should say, it’s too long to—the amount of time required to get to understanding or let alone value, is too high. And if they can’t get there fast enough, or they simply don’t see the workflow fit, this can be a blocker to your sales success. Sometimes prospects choose simpler competitors, even when you may know that their technology is actually inferior, it’s outdated, or it doesn’t scale as well, or whatever it may be. When value feels complicated, or your solution solves one thing, but it opens up new issues elsewhere, particularly as it relates to things like new labor behavior change or business process disruption, well, unfortunately you might also be creating risk, even if you’re solving one part of the problem that they have, and risk stalls deals.

And when you do get past the buyer and they go to a POC, your product’s hands-on users or their internal stakeholders become your next biggest risk in the chain. And if you spent all your time investing in sales tactics or sales materials and things that feel like you should be doing because sales is the problem, versus addressing the product itself and you’re not really investing in making the product easily adoptable by the users in these POCs, then you’re effectively just delaying that next close lost, unfortunately. So, you get past the buyer, but now—and you’re into the POC and it’s in the hands of the end-users and the managers and the people who are going to live with this thing, and it doesn’t close. Close loss is around the corner because you might have spent too much time addressing the sales process itself, what we do in the calls, and what we do in the prospecting, but not making that product indispensable to begin with.

So, I’d even say, in some ways, it may be better, and this is—if you’re a startup, I completely understand how this might come across—in some ways it might be better if you lose now, you don’t get the deal now because if your prospect buys without evaluating the usability and utility of the solution from the eyes of the people who are actually going to be hands-on with it, then the news may be worse because now they’re actually paying for software that nobody may be using, or that’s definitely not creating enterprise value, if you’re, you know—or not necessarily enterprise scale value into the organization that you’re selling your B2B product. So, that’s a bad look for your newest customer that you just landed. Internally, that does not look good for their reputation and it’s probably not going to make them see your solution as indispensable, let alone you, the founder or the head of product or the head of sales or whoever you are in the organization, nobody’s really coming out ahead except for the short-term transactional win that you got. And they might even become defensive, and you might have lost a possible champion for the product.

So, I think there’s risk sometimes, if the perspective is, just get in, close the deal at all cost, and then we’ll figure it out. Mmm… maybe. So, as you can probably tell here, I have some beef with how some analytics and—you know, B2B analytics and AI products are sold, and I think this also gets into product development and design. So, I want to kind of talk about those two things and how we can improve our sales close rates by addressing underlying product and user experience issues with data products. So, I’m going to tell you, I used to think sales was the enemy when I worked in-house as a user experience design professional and even as a contractor for many years.

Salespeople were the enemy, especially to creatives and people in the design field. They’re money hungry and they’re selfish and they just want to land their commissions and all this kind of thing. Later in my career, when I got smarter, I learned how invaluable good salespeople can be as feeders to product teams and to not just product management, but also to designers, if they’re aware enough to realize this. And a lot of them still won’t cross over that bridge and engage with the sales team and the sales team rarely is talking to design on their own. On the other hand, I do see and know of salespeople that are focused on convincing and showing and demoing and trying to convince someone that something is good for them, a product is good for them, and they really should have it.

And to me, I’m always trying to think about what if we didn’t have to convince? Because people don’t want to be convinced. No one likes to be sold to, but people do like to buy stuff. That was one thing I learned early on in my own sales training. People love to buy but they don’t like to be sold to. So, what if we just focus on first principles here, which is, what if the product was easier to buy because it was obviously valuable to the person we’re trying to sell it to?

So, I’ll say it right now, your goal should be to design and build a data product that sells itself. When the product is great, you’re facilitating a closing and you’re not trying to convince somebody why your solution is great for them. So, that old model, it looks like generic demo tours, capability flexing, doing very little workflow discovery before showing the product. So, you get someone on the phone or on Zoom or whatever, and you go into presentation mode immediately, touting the innovation and your data and analytics and AI capabilities without thinking about practical workflow fit. And the broader your product is to a wide class of problems and industries, the more you’re actually forcing prospects to do the heavy mental work of trying to map your product into their workflow and their world.

Because by definition, if it’s doing a lot of things for a lot of people, then by definition, it’s not specialized and it’s not high touch, it’s not highly focused on solving a niche problem because it’s trying to do categories of problems and be scalable and all these kinds of things. So, that’s kind of the old model. And part of the reason I think that model of selling can fail for you is things like cognitive load. So, this means your buyers and your users get overwhelmed trying to reverse map your solution onto their problem space. And in the call this is them trying to imagine themselves in a better place, using your solution.

And it takes energy to do that, particularly if the solution is not obvious or intuitive to begin with, or it’s going to require a lot of process change. That’s a heavy brain space to be sitting in, and they’re probably not really listening to you anyways if they’re having to spend a lot of mental energy trying to do that mapping during a sales call. Another reason why this kind of old school sales model can fail, is behavior change risk. So, buyer sense, you know, adoption friction. They sense it’s coming, and then, you know, the sale kind of stalls.

So, you know, let’s say your AI product is dependent on a proprietary data pipeline or some feed that you need to get from the customer in order to show value. But getting that pipeline built costs time and money. Which maybe that’s not a huge deal; maybe the cost isn’t that alone or you’ll eat some of that, but then you realize we also have to get permission to do that, not just to get the money to build it. Even if you’re saying, oh, we’ll eat the cost, well, now there’s legal review and compliance and privacy concerns and all of this. And this is just to get a POC going, let alone the sale. So, there’s friction in there.

Now, it’s not to say you’re just going to find ways to bypass all that stuff. Sometimes you may have to do that to show the value. The point is whether or not you’re aware of that, and if it is a requirement, how easy have you made it to get through that process? Because that is basically all what we call ‘Tool Time.’ Those are all impediments to the sale and friction to the product.

Those aren’t benefits, they’re just cost of getting value out of the product is you got to build the accounts, you got to import your data, and you got to run some model optimization, or whatever it may be. Ingesting data, building data pipelines, none of that is value. That’s all tax.

Buyer and user mismatch. So, this is, in the old model of sales, you may be seeing the linchpin is the fiscal buyer who has a budget, but your sales process is focused on satisfying just them. So, you’re usually talking about the financial ROI and benefits that will eventually emerge, however, the unaddressed dependency in all of this is the end-user, the people who are actually going to be responsible for producing the value that your product is supposed to create. And this is, of course, assuming that the end-user and the buyer are not necessarily the same person. Sometimes they are, but frequently in B2B sales, that’s not the case.

So, if you have this buyer-user mismatch, like either the buyer doesn’t realize they have it, you don’t realize they have it, or both of you don’t realize that there’s a mismatch here, that we haven’t realized there’s two pieces to the puzzle that need to get satisfied here. And I think there’s a lot more energy put into knowing the buyer and assuming that as long as we have the person with the budget and the buying decider, that we’re safe. Close the deal, you got the revenue, it’s gold. And the last one in this list about why some of these old school sales models can fail is status quo bias. Frankly, indecision beats change.

We see indecision all the time. Like, what did you guys decide to do? Nothing. So, your product, while possibly beneficial on one axis of value, could introduce risk elsewhere: financial risk, reputational risk, like personal reputational risk to the buyer, technical risk to the organization, or organizational change risk because, well, in order to get the value out of the product, we need to redo this business process, or we need to get compliance to sign off at these different phases. And they never used to have to do that. They have no incentive to go and log into the tool and yadda yadda yadda.

So, what’s a better way? I’m so glad you asked [laugh]. I have this concept I’ve been thinking about called FOWA. F-O-W-A and FOWA stands for Flow Of Work Alignment. And I kind of see this as, I don’t think it’s directly—it’s not a sales model. It’s something you want to add to your sales model, Flow Of Work Alignment.

Your demo shouldn’t really be a product tour. It should be a preview of the customer’s better future, their workflow, your product embedded into it as much as possible. And really the goal is to get that prospect to say, “I can see the value. I can see my staff using this month.” They’re not asking explanatory questions about how it works or why do I need this?

So, let’s get more specific here. How do you know if you have Flow Of Work Alignment or not in your product and sales process? Well, I think there’s a few things we can observe to know this. The first one is the time to initial comprehension by the prospect is low. So, in other words, you’re not reliant on convincing people with your mouth or via explainer videos.

And this is particularly true with, like, LLM-powered AI solutions, like, talk-to-your-data products and things like this. You’re not forcing the customer to ask, “Why would I want to do that in your product?” That’s taking them out of the flow of work if they’re having to ask questions like that. So, there should be this obvious comprehension about why I would need something like this. And if there’s not, that’s already the first possible risk factor or hurdle that you need to close.

The second one, I think, is not hearing shallow questions. So, I kind of mentioned this earlier, but this means, like, you’re not getting basic how-to explainer questions, why-would-I-want-that type questions. If you are getting questions, you would hope those would be deeper questions where it seems like, oh, the customer totally understands what this is for, and they’re asking some edge case situation, or do you also support Python or do you only support, you know, whatever. This tells you, like, oh, they understand that this integrates with the engineers codebase directly. I didn’t have to explain that to them. They’re just asking about additional language support because the demo shows Python on the screen. That’s a good sign that you’re not having to explain that there’s a code integration, for example.

The third one here, how do you know, if you have Flow Of Work Alignment? They see their workflow, like, represented in the tool as is, or they see it better. It’s been improved. And I think this partly comes down to intentionally designing moments into the sale where a buyer can see the value they are getting, and a user can see the product augmenting their current workflow. And it’s not undesirably changing it; it’s desirably changing it in ways that they can recognize.

So, this doesn’t mean—again, it doesn’t mean you can’t introduce change. Change is always happening in business processes, for example, but that change has to seem beneficial, low risk, and easy to justify, given the relative promise of value. So, if you’re promising this gigantic ROI, then customers may have an expectation that the cost or risk associated with getting that is likely going to be higher. But if the value is somewhat opaque to begin with, and they’re not really sure how they would apply it and all this kind of stuff, this is where we get into trouble. If we have a lot of friction in there or we’re asking users to change a lot of their behavior, it’s just not worth it to them.

So, we need to understand, how do they do this work now, regardless of whether or not that’s the way you think it should be done, particularly if, like, maybe you’ve had—like, I’ve built data pipelines for financial services predictive models for 25 years, and you know the right way to do it, they’re doing it, quote, “The wrong way,” you’ve built a solution that can fix that, and it uses the latest technology, and it’s technically amazing. Unfortunately, as a product that you need to show value against, all that matters is whether they think they have a problem with the way that process is done, and if they don’t think they have the problem and it doesn’t hurt them and there’s no incentive to change it, or little incentive to change it, and there’s a lot of incentive not to change it—because remember the status quo bias, right?—well, guess what? They’re probably not going to change anything. They’re just going to do what they’ve always done.

So, the last one here on how do you know if you have Flow Of Work Alignment, nobody needs to discuss your data product’s engineering, analytics, or AI sophistication to understand its core value. This does not mean, of course, that you’re not ever going to talk about technology or anything like that, but you’re not espousing statistics at them or telling them about, you know, how this predictive thing and we run 900 Monte Carlo simulations per second, and yadda yadda yadda, trying to convince them about what it is. You shouldn’t need to talk about any of that because, frankly, all of that is our technical facets, but at the end of the day, the fiscal buyer wants to know, am I going to get a benefit for those 900 Monte Carlo simulations per second? Am I going to get the benefit I need? Because running the simulation is not what the benefit is; it’s the downstream change that occurs in their world that’s the thing that they want, not the simulations.

So again, let me repeat this one. Nobody needs to discuss your data products, engineering, analytics, or AI sophistication in order to understand its core value. So, you’re probably asking yourself, what you need to do to get FOWA or Flow Of Work Alignment. Well, I’m glad you asked. I’m going to pause here. Next episode—I’m trying to do some shorter episodes here—I’m going to get into that. I’m going to give you some actionable changes, and I’m also going to talk a little bit about some of the objections that I think founders, and particularly technical founders and technical product leaders have to some of this kind of stuff.

And I know some of these things can sound hand-wavy, like, workflow and talking about customer empathy and perceived risk and all these kinds of things, I want to address some of those things, and I totally can understand some of those objections. So, we’ll get into that in about two weeks, so stay tuned. But for now, I’m hoping that you’re starting to think about Flow Of Work Alignment in your tool, whether you’re the one selling it or you’re the one producing it, if you’re a product person. And until next week, thanks for listening to Experiencing Data.