Transcript:

Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. Today I have Rana Gujral on the call with me, CEO at Behavioral Signals. How’s it going, Rana?

Rana: It’s going really well, thank you.

Brian: Yeah, you have a book coming out. Well, we’re going to get into that a little bit, but I wanted to drill you a little bit about your product background and particularly this product you’ve been working on for a few years now in the deepfake voice detection space, and kind of figure out how did you do your journey, how did you get to where you are right now. So, I want to tell you, just to fast-forward for listeners, what the product does. I’m going to use it in my own words, and I’m going to let you correct what I got wrong. So, my understanding is Behavioral Signals uses deep learning right now to create a tone-of-voice model to detect deepfakes and help your clients—B2B clients—prevent fraud, as well as, as I understand it, you can do things like routing a caller that calls in that has an issue or something, you can figure out who the right call center rep might be for them based on their communication style. So, this AI is kind of living in the background, and the goal here is to have better call outcomes, I’m assuming for both the caller and the corporate customer that’s buying your software here, as well as all the deepfake and fraud detection stuff. So, what did I get wrong [laugh]?

Rana: You got most of it right, actually. Let me just sharpen a couple of edges.

Brian: Please.

Rana: On the routing side, what we call PAIR, Personalized Agent Intelligent Routing, it’s not just matching communication styles in the abstract; we’re modeling what we call behavioral compatibility between a caller and an agent based on real outcome data. So, say if I’m calling in to restructure a loan, the system’s asking, given how this person sounds in the first few seconds, who on the floor right now has historically driven the best outcome with people like them? Like for example, we ran this with an EU bank during NPL structuring program, and it draws something like a 20% lift in successful restructures and a meaningful call time reduction. So, the goal isn’t just a nicer conversation, it is a measurable business outcome, and ideally a better outcome for the person on the other line as well, who’s on a tough spot financially.

The one nuance I’d add-on the deepfake side, where we’re not purely a tone-of-voice model. Tone is a part of it, but the deeper work is what I’d call behavioral mapping. Every person has a signature in how they speak over time, so think about micro-pauses, prosody, trajectories, coarticulation, the rhythm of how they shift emotion mid-sentence. Static voice biometrics, the stuff that checks does this voiceprint match that’s, right? So, generation models, like the vocoders can patch those tells, so what we model is a temporal pattern, like, how a specific human moves through our conversation.

That’s actually much harder to fake convincingly, believe it or not. And then, yes, all of this sits in the background, the agent doesn’t see a dashboard screaming at them. It’s ambient, which I think is the right design philosophy for something like this, and you know, it’s the right kind of AI. It should make the human better, not replace the judgment in the room.

Brian: Yeah, and I want to actually get into this as well. So, one of the challenges that product founders and operators that I talk to with analytical intelligence products, sometimes there’s this balance between how much do we show about what’s happening so we can convey what the value is there versus how much should it be completely invisible to the customer; it’s unnecessary information to be showing anybody? So, I want to kind of dive into this. So, my assumption is, as call center reps, they’re not paying attention to this model doing its stuff in the background and trying to create a model of the caller and all this stuff. It’s largely invisible, right? So, does that make it a sales challenge for you all? And how much is that—if it is a challenge—is that a user experience problem, is it a positioning problem, is it a technical problem, or maybe it’s not a problem at all. I don’t know. How much does that matter when it’s sort of invisible?

Rana: It’s a real tension, and I think you put your finger on something I do think about constantly. So, let me break it into a couple layers because the answer is different depending on who you’re talking about. So, say the agent on the floor, invisibility is the feature, right? So, the last thing the call center rep needs while they’re trying to deescalate a frustrated customer is a dashboard flashing, “Empathy score 42%. Pivot now.”

Brian: Right [laugh].

Rana: That kind of overlay actually degrades performance. It splits their attention, and frankly, it patronizes them. So, for the end-user of the system, ambient is correct. AI should function like a good Copilot, shaping outcomes, but you know, not demand cognitive load. But for the buyer, the operations leader signing the check, invisibility is a sales problem. So, you’re absolutely right. If they can’t see it working, they don’t trust it, and they don’t certainly renew it, which is a problem for us, right?

So, what we had to invest heavily is an explanation layer, not for the agent, but for the operator. So, you have to build confidence, you have to build audit trails, you have to have an ability to explain contrastive situations. Why did the system route this call to Sarah instead of Mike? What was the behavioral signature it picked up in the first eight seconds? What was the counterfactual outcome if we route it differently?

You know, that is a kind of intelligibility that converts the black box into an accountable collaborator and gets paid. I think what I’ll want to push a bit on is the framing. So, I don’t think the question is invisible versus visible. It’s invisible to whom and legible to whom and when, right? The agent gets ambient assistance, the supervisor gets aggregate patterns. And the compliance team needs the audit trail, and they should get that. And the C-suite gets outcome lift tied to revenue. Same system, four different surfaces of visibility, each tuned to what the human actually needs to make a good decision. I do see a lot of this tension, by the way, on various AI product teams because they try to build one interface that makes it serve everyone, and that’s when you get the worst of both worlds, I think.

Brian: Yeah, and I’ve seen this pattern as well. So, you have to figure out, like, what’s the right information to show, and to whom, at what time [laugh]. And at what level of detail as well because I’m sure, like, the people looking at revenue aren’t going to go down at the call level audit trail stuff to see, like, what happened at what moment, and all this kind of stuff. So, tell me, though, did you come out of the box with that, or did you arrive at this thinking that we have four different surfaces here, different personas with different needs, in order to understand the value of the product so that the renewals keep coming and all of that? Has this been an evolution? Like, did you just have this feeling, we need to have this before we even have a product? Tell me about, like, how you got to where you are now.

Rana: We absolutely did not come out of the box with this. I wish I could tell you we did. Honest answers, we learned it the hard way through churn and through deals that stalled in places we didn’t expect. Early on, we were classic engineers. We built one beautiful interface, packed it with signal, assumed the value would be self-evident.

And what happened was exactly what you’d predict. You know, you’d seen it before. I mean, the operations would demo it, get excited, sign. Six months later, we’d get a renewal call, and they would say, “Well, I’m not sure what this is doing for us.” And meanwhile, the agents loved that outcomes were better, obviously, but the person writing a check had no surface that spoke their language, right, and that’s a problem.

And so, they didn’t want the call level audit trails, they wanted a number tied to revenue or to handle time or to NPS, and so we weren’t giving it to them. So, I always sort of say, like, I mean, the perfect product is the one that you know drives an outcome, and there’s a, you know, measurable ROI, but that’s not enough. You got to ship the meter as part of it. Like, yeah, the ROI is there, it’s measurable, but if you don’t have a meter, what are you going to do, you know? You don’t know what it is.

So, the other thing we learned which was painful, is that compliance and risk teams have completely different appetite. I mean, they don’t want outcome lift, they want to know, hey, can you show me for any individual decision the system made, the reasoning chain and the confidence level at the moment? I mean, if you can’t produce that, you don’t get deployed in regulated environments, full stop.

Brian: Yeah, have you been able to normalize across a set of KPIs that resonate with every new buyer, or it’s like, okay, this bank they need 0.7 confidence level, whereas this one doesn’t care about the confidence, but they care about this other stat we need to compute only over a two-week average because people call in every day. Like, I don’t know, like, I’m just riffing. But tell me about, like, that whole thing. Do you have to constantly rethink the KPIs and metrics you’re going to surface for each new deal, or has it kind of calmed down a little bit, and you figured—maybe you’re even telling them, like, this is the stuff most of our clients want to track.

Rana: Honestly, I mean, I think it’s somewhere in the middle. I mean, it took us a while to find that middle. Early days, every deal just felt like a custom build. I mean, the retail bank wanted average handle time and first call resolution, and the collection shop wanted promise-to-pay rates and the right party contact. You know, the insurance carrier wanted compliant ratios, and you know, want to track various vulnerable customer flags. And so, you’re rebuilding dashboards every quarter for every logo.

What we eventually did is something I call a core-plus-overlay model. That is a core set of maybe six or seven metrics that we found genuinely travel across almost every contact center deployment, outcome layer versus a control group, confidence calibration on a model’s prediction, time to resolution, but for the most part in the CCaaS space, the KPIs haven’t moved that much. I mean, there’s a handful of KPI pretty much every call center cares about. If you kind of look at the overall CCaaS stack right now, it is ginormously complex. I mean, there’s, like, you know, the old-school players and the new-school players and everything in the middle, and it’s like complex stack over stack over stack.

Each of those pieces are going after the same handful of a half-a-dozen KPIs. It’s stuff like, you know, CSAT score, satisfaction score, it’s stuff like first call resolution, stuff like average handle time, more specific outcome-based things such as promise-to-pay or promise-to-buy for collections or sales. And they all claim to move the needle on the same KPIs. And what we have done is, you know, we’ve built a system that impacts all KPIs.

Because at the end of the day, what are you doing in a call center? You have two humans who are going to come together and negotiate on an outcome that is successful for both the business and for the client. And at the end of the day, after all the training, all the tech, all the technology, it’s how those two humans get along and interact, and that’s natural rapport. And so, if you build a solution that maximizes the chances—you cannot manufacture rapport, by the way. Rapport is there, or it’s not there.

And what we’ve been able to do is, we’ve been able to understand how to situate that maximization of the rapport. So, we extract the signatures, and then we do advanced matchmaking behind the scenes, and then we get the right people who are expected to have a maximal rapport, which translates into a great, flowy, clicky conversation that translates into a much better outcome. So, all of these KPIs get a massive lift by that technology. And so, we’re the only technology out there that dips into physiology of a human. We’re extracting that behavioral profile, that conversational signature, and then using that to get the best outcome.

Brian: Yeah. Tell me a little bit about the time-to-value things. So, for some clients, and just companies that I’ve worked with in this space and seen, you can see where an intelligence product might need time in order to prove its value, particularly, for example, there’s, like, data engineering required, or data collection required, or I don’t know, in your case, does the call center voices, the actual employees, do those need to get modeled before you can do PAIR properly? The point being here, do you have to think about designing the POC experience such that the product shows its value soon enough, or do you get feedback pretty fas—do the customer get feedback pretty fast that’s measurable and quantitative, and at the outcome level, in particular. Tell me about that.

Rana: I mean, time to value is probably the single hardest commercial design problem we had to solve in our category. The tech is genuinely good on day one, but the proof of value lives downstream in business outcomes that take weeks and sometimes a full quarter to materialize, right? So, we had to engineer the POC almost like a stage gate. We break value into sort of, say, three phases. The first is what I call signal validation, and that’s what happens in the first two weeks.

We’ll instrument a sample call, show the buyer what the behavioral signature we extract are real, stable, predictive of something they already track. We’re not asking them to trust the outcome yet, we’re just proving the lens works. And that’s fast, it’s tangible, and it builds confidence. Then you need to focus on the leading indicators, right? Week three through six, agent adherence, override patterns, calibration curves, things that correlate with outcome, but show up before the outcome does. And this is where you know you get the right to keep going.

And the third, the, you know, the proof in the pudding is the actual lift, the thing that they signed up for. That could take eight to twelve weeks, depending on call volume and how seasonal their business is. But the interesting thing is, like, you know, so we don’t need any call modeling ahead of time. You don’t really necessarily, I mean, the signature extraction process for us is real time, and we could do it, like, in less than 60 seconds. So, in 60 seconds of voice interaction using our models, we can extract a signature of everybody who’s in the conversation: agents, clients. And repeated conversations just make that signature better, but after a few extractions, you don’t really need to process it anymore, and you don’t really need to model on the person specific-wise. Our models are trained to understand that domain and it extracts everything real time.

Brian: Got it. So, you mentioned there’s, like, a three-phase model here with the, you know, the business outcome, the financial value being at the end here. That sounds like intentional thought about how this customer journey happens and perhaps what parts of the product, or even just the surface layer, the reporting layer, in particular, if this is the way your customers are going to understand, is it doing what it promised it would do? Is that an intentional thing that you or your head of product or whoever would do this kind of work came up with? That there’s a journey here, there’s these three stages, they’re really important.

You know, stage one, this part of the reporting, or whatever, is going to be super important, but once we do that, no one’s going to care about that anymore. It’s going to go over here. And like, the compliance people, like, and here’s how they’re going to stress test it, and here’s what they’re going to do. You know, was this a very intentional thing, or did you kind of happen upon this? Tell me about that. It sounds very producty [laugh].

Rana: It was intentional, but let’s try to be honest with how we got intentional because I think that matters. It wasn’t a whiteboard exercise where we sat down one day and said, okay, let’s design a three-horizon journey. I mean, it started as a pattern recognition across deals that worked and the deals that didn’t. And what we noticed was when the deals died, usually they died at a predictable moment. I mean, there was a week-four problem and week-ten problem.

Week four was, I see the system doing things but I don’t know if it’s the right things yet, and the week ten was outcome data is noisy and I have a board meeting on Thursday. And once we saw those, like, fail modes enough times, we reverse engineered the journey, what does the buyer need to see at week two so they don’t panic at week four? What do they need at week six so week ten feels like confirmation, et cetera. So, yeah, I think you know a lot of this is explicitly designed reporting surfaces on each horizon, and we explicitly designed what fades. And we’re still trying to get that right, by the way. I mean, it’s not fully solved yet.

The good news is that our product is very unique from a perspective that, you know, it is high ROI value that can actually absolutely be measured, and that’s the thing that wins. Like, so for example, you know, any of these KPIs that we’re trying to improve or optimize for, you’d have some way of measuring it before, and you would call it business as usual. And that’s a calculation or a formulation that the client has, I mean, and we don’t muck with that. We don’t adjust that. We’re just like, “How do you do it?”

Like, so CSAT, do you measure the CSAT score? You got to stop there first. And one, do you measure it? Second, how do you measure it? If you don’t measure it, well, let’s figure out a way to measure it first. If you’re measuring it, let’s see how you’re measuring it. But then you have a baseline. Let the system run, and now you see how the system’s impacting it, right?

So, initially you have to do a champion-challenger A/B test. So, you have to have a test group and a control group, and the best way to do that is to not divide the agents on the test and control, but divide the incoming client calls. So, all agents are in the program, and there is no ambiguity in terms of who’s in control, who’s in test, et cetera, but the incoming calls, you could separate, and some you could match, and some you could just randomly assign as a system would, before you know our solution was implemented. And then you could, sort of, see the delta, and it’s their calculation.

And that will show up really quickly. It’ll show up in, like, in a couple of weeks. And at that point, if there’s a debate about calculation, well, it’s your calculation. Let’s fix it if it’s not right. But the good news is that what people realize is that, you know, they went after a specific KPI, but now they’re seeing impact on six or seven others that they didn’t even think the technology could impact. But that’s the nature of the tech, is it doesn’t really, you know, have a champion KPI. It’s going to optimize the interaction, which means everything gets impacted. But you can tune it for a specific API, you could tell the model that the client chooses CSAT, and as a result, the matching is optimized for CSAT. So, you have some of those abilities that really allow the product to shine.

Brian: One of the things I think that’s happening right now, particularly as the AI capabilities keep accelerating, is we dramatically reduce, particularly time or labor around now problems and current downstream problems become now problems. And those downstream problems might have been like, yeah, we’ll deal with that later, or it happens once in a while because there’s so much upstream stuff, but when you compress all that, all of a sudden, what used to be downstream is now, now. So, I’m wondering if this has happened with you. So, for example, let’s take something like fraud detection. Let’s say in the past a human did this work or they had some poor technology solution, and maybe it caught one per month, and it routes it to some other business process, and they have to go through extra screening, or whatever the heck it is.

And now you’re getting ten per day, and it’s [laugh] creating this bottleneck over in some department where there never was a bottleneck because the tech couldn’t detect it that fast. So, now they have, you know, a staffing problem, or an operations problem, or something like that. Have you seen any of this with your product creating new kinds of problems are, like, those downstream problems became now problems?

Rana: Yeah, I mean, I think one of the most under-discussed second-order effects of deploying AI in production is just this: the bottleneck doesn’t disappear, it sometimes just moves. And it usually moves somewhere the org wasn’t staffed or governed to handle it. So, like, for example, like, if you deploy deepfake voice fraud detection at a financial services client, I mean, the prior baseline potentially could be something like a handful of suspected synthetic voice incidents flagged per month, mostly caught by alert humans on the line. And you know, if you turn the system on, and within the first few weeks they’re surfacing dozens of high-confidence flags, great, right? That’s the win.

Except now the fraud operations team had to actually adjudicate each one. And the workflow for what do we do when the system says this caller might be synthetic, didn’t exist in any form. Do you disconnect? Do you escalate? Do you preserve the audio for law enforcement? Who has authority to freeze the account? And suddenly the AI was generating decisions faster than the layer, you know, could actually know what to deal with.

You know, on the PAIR something similar. I mean, you know, when you start routing calls based on, say, compatibility, behavioral compatibility, and the outcome improves, and then supervisors begin to ask questions they never asked before, you know? Why is Sarah getting all the high stress callers? Is that fair to her? Is it a wellness issue? Is it a compensation issue?

And you know, are there specific types of behavioral personalities and profiles that are better suited for our client base? And how do you feed that into hiring, you know? So, I think it connects to something I write about. It’s the accountability gap, you know? When AI compresses the time between, say, detection and decision, you reveal every weak seam in your human process. And I think, you know, that definitely is a real thing.

Brian: If you think about your product as, like, having a fence around it, like, you’re, like, on a farm or something, like, does our fence need to be bigger and start to deal with, like, say, you know, like, the fraud department now has more than it can deal with, and it has to adjudicate, and they’re going to want to compile a case for law enforcement, so I guess our product should expand to help with that and create neat bundles they can send to law enforcement when fraud is—like, you could just see how the boundary, the fence line could keep expanding outwards, or not. How do you think about that as, like, where’s your playground? Where do you shine the most, and where is, like, sorry, that’s outside of what we’re going to try to deliver value on. Is [laugh] that something you think about?

Rana: Yeah. You know, and it’s one of the harder strategic questions in the space because the gravitational pull to expand the fence is enormous, right? So, every customer conversation surfaces an adjacent problem you could plausibly solve, and the tech is general enough that you could usually convince yourself that you should. The way I think about it is our core competency is the behavioral signal itself, modeling how a specific human moves through a voice interaction over time, prosody, trajectories, micro-expression timing, the temporal rhythm of how someone speaks under stress or duress or deception, that’s the moat. That’s where we have the decade of proprietary data and patented methods. Everything else is downstream of that signal, you know?

So, I think there’s a category of expansion that’s legitimate, which is when the absence of next-mile makes your core value impossible to realize. You know, if fraud ops can’t act on our flags because they have no workflow, our signal is worthless, and so we’ll have to—we’ll build the thin connective tissue, confidence scoring, audit-ready logging, you know, integrations into the case systems they already use. But we won’t own the adjudication, right? We’ll make ourselves indispensable to whoever does.

Brian: Got it, got it, you mentioned a moat here a second ago. I wanted to go into that. One of my theories is, like, for analytical intelligence products, like, proprietary data can be a really good moat. So, tell me a little bit about why is that not hard to copy right now, with the availability of compute and data sources out there. What makes that a safe moat for you all?

Rana: I think the moat isn’t just a data alone. It’s the specificity of the data paired with the labels, paired with the loop, right? And that combination is genuinely hard to reconstruct, even in an era where it feels like every data set is just one scrape away from being commoditized. So like, say, most of what’s available out there, the big, say, public corpora, the off-the-shelf voice data sets, even the—yeah, you can generate synthetic audio, you know, and those teach a model to recognize, say, generic patterns, right? So speech, sentiment, basic affect. That’s table stakes. I mean anyone can buy or build that.

What they can’t buy is a decade of voice interactions tied to consequential business outcome. Did the loan get restructured? Did the fraud actually materialize? Did the customer churn 90 days later? Those outcome labels are the expensive part, and they only exist because we’ve been embedded in real workflows where the consequence actually played out.

That’s a concept I lean on a lot. I mean, the idea that skill is a crystallized output of a process, not the process itself. You know, a competitor can train a model that mimics our outputs on a benchmark. That’s okay, let’s call it a skill, a crystallized skill, right? What they can’t easily replicate is the process that generated it, I mean, the years of calibration, you know, the edge cases we’ve encountered, the feedback loop from operators telling us when we were wrong and why. That’s tacit and that’s path independent, and I think that’s the thing that compounds, in my opinion.

Brian: Yeah. I saw a YouTube interview that you had done, and you were talking about your F-score here, around precision and recall, you know—most people probably know this better than I do on the show—one being perfect, meaning you absolutely don’t miss anything, you detect everything perfectly, and what was it, five years to get to, like, 0.5, and then you got up to, like, 0.92 in the last two years because of AI accelerating thing here. One thing I want to ask you about is, at what point is a model good enough that it’s commercializable, like, you can go out and sell it on the value? Like, how do you know if 0.7 is good enough?

Rana: See, F-score in isolation is meaningless. What matters is F-score relative to the cost asymmetry, the decision the model is—the asymmetry of the decision the model is participating in. So like, let’s say deepfake detection in financial services. A false negative, letting a synthetic voice through that authorizes wire transfer can cost millions, right? A false positive, slagging a legitimate customer costs you a frustrated call, and maybe 90 seconds of agent time. Those two errors are not equivalent, right?

So, when we crossed roughly 0.7, what we were really asking is, is the model good? It was like, it’s not good enough that the expected loss from errors is lower than the expected loss the customer is absorbing today already without us. I think that’s the commercial threshold. It’s not a number on a leaderboard. And obviously that’s a different lens for scientific paper, but I think for commercial implementation the internal test is, you know, really how it impacts the KPIs, and if the KPI impact is measurable, I think the model is good enough.

Brian: Tell me about getting your first, say, ten customers. The reason I’m asking you about this is because I think you can build technically right, effectively wrong products, where you could have a 0.9 score and have a completely non-viable product that no one wants to buy. Conversely, you might have a product that doesn’t have the highest score, but it’s commercially viable and it’s good enough to show the value. So, I’m curious, like, at what point did you feel like either you could go to market and try to sell it, and you actually sold it? Where were you at in turn—and whether its F-score or you want to use some other thing to talk about the quality of the underlying AI, where was that at the point that it was good enough to get a customer?

Rana: Yeah, the first few customers came before the model was anywhere near what I wanted today, and I think that’s an important truth for anyone building an AI. You know, the first paying customer, you know, we’re sitting at something like 0.6, 0.65 F-score on, like, say emotion classification and say real conversational audio. That’s not a number you would put on a billboard, but here’s the thing, right, the customer wasn’t buying that F-score. I mean, they were buying a capability that didn’t exist anywhere in the stack.

I mean that’s zero visibility into the emotional arc of the call. We gave them something imperfect, noisy, directionally useful. And directionally useful when the alternative is darkness is a product, right? And so, what we learned fast is that the first few customers are not really customers in the traditional sense. I mean, they’re your design partners. They’re the ones who are going to tolerate the rough edges because they get to shape the roadmap.

And so, you have to be deliberate about who you pick. You know, you have to turn down some logos that want a plug-and-play because we knew we’d fail them. And you know, we said yes to the ones who had a specific painful problem, a champion inside an org, willing to co-develop the outcome metric, we could actually move, even with, like, you know, whatever the F-score is. The second thing, and I think this is where I think a lot of the AI founders get this wrong, is you never sold the model. I mean, you know, you don’t sell the model; you sell the workflow the model enables, right? And, like, whatever the F-score classification is, you know, it needs to be wrapped in an agent feedback loop with clear dashboards and a clear integration, and that’s when you have a viable product. And I think that’s the important piece, and you know, you have to be careful about that.

Brian: Yeah. If you went back five years, so you spent a lot of time on the technology, the actual model here, you spent time on designing it sounds like the POC process, these four surface layers and personas that have different needs to understand how this deep learning model is affecting the business there. What would you do differently if you started this over, you know, say three years ago [laugh]? Is there someplace you wasted a lot of time? You’re like, man, that was so unnecessary.

Rana: Yeah. A few things, and they’re painful to say out loud because they cost us real time.

Brian: [laugh].

Rana: I’d say the biggest one, I’d say, stop trying to sell tech and start selling the workflow much, much sooner. Like, you know, early on we led a lot with how sophisticated the underlying models were, you know, paralinguistics, self-supervised embeddings architecture. The buyer would be, like, amazed and nod, and then ghost because nobody in the call center really, you know, wakes up wanting to buy a transformer, right? I mean, they wake up wanting to fix collections recovery or reduce escalations. And we learned to lead with the problem and let the tech be the engine bit underneath. So, I’d say, if I could go back, I’d compress that lesson into month two, not month eighteen.

And I think the second thing—this is more strategic—I would have picked a narrower wedge. We had a platform that could do a lot of things, so we try to serve a lot of buyers. We dabbled in financial services, in healthcare, customer experience. Every new vertical meant a new sales motion, a new compliance conversation, new pattern for integration, and you’re spreading ten across too many contacts, too many systems, and then you cannot accumulate experience fast enough for any one domain. So, I think you know, pick a vertical, one use case, dominate it, let the platform story emerge from depth instead of the breadth.

Brian: Yeah, I think that’s not always intuitive, the positioning of the product. And especially when, you know, I’m not a machine learning engineer or data scientist, but I’ve read about how sometimes generalized models off the shelf, like, for let’s say image detection, instead of building a cat detector, you can use an off-the-shelf image recognition model and get pretty good at detecting cats. So, from a technical standpoint, it sounds like there’s some bias in the space that these, like, generalizable has a lot of value, but when you look at it from a product lens, a commercialized product, like, there’s so many other things that go into, like, are you speaking the customer’s language? Are the KPIs that you’re talking about the ones they’re talking about? Like, do they feel like you understand our world, and all of that? Is that tension something that you have seen?

Rana: Yeah. I mean, you know, and then I actually argue the tension you’re describing is one of the most misunderstood dynamics in applied AI right now. There’s this seductive idea, and it’s especially loud in the foundation model era, that generality is the highest virtue. I mean, bigger model, broader training data, more transfer.

Technically, you know that’s often true. I mean, you can take a general-purpose model and get to 70-80% of tasks with shockingly little effort, but I think it’s also a trap. I mean, generality on the tech side does not translate into generality on the commercial side. In fact, they pull in opposite directions. A buyer doesn’t experience your model; they experience your product inside their workflow, in their vocabulary, against their KPIs. And the more general your positioning, I mean, the more cognitive work you’re asking them to do to map your capability onto your system. And mapping cost is enormous, by the way, and most buyers won’t pay it. They’ll just pass.

Brian: I want to ask you about your book in a second, but before I do that, just going up a little bit altitude-wise, when you think about building a product that’s a data-driven product, or a data product as I often call them, what stuff right now is no different than it was ten years ago? What stuff has indeed changed about how we build the products? Is there anything that really just screams at you [laugh] that’s different or not?

Rana: I think about this a lot, actually because the hype cycle makes it feel like everything has changed, and a surprising amount actually hasn’t.

Brian: I agree.

Rana: So, what hasn’t changed, and I’d say I always argue, will never change the fundamentals of data product work are still about closing the loop between decision and outcome and a feedback signal. So, if you can’t measure whether your product changed the decision and whether that decision led to a better outcome, you don’t have a data product; you have a dashboard, right? So, that was true ten years ago. It’s true today. The discipline of instrumenting your own product, so you can learn from it, learn from how it’s used, that’s still where most teams under invest, and I see it constantly. Beautiful models, no telemetry on whether anyone acted on the output.

Brian: Right?

Rana: I think, also, one other thing that hasn’t changed is data quality being a silent killer. Ten years ago, we said garbage in, garbage out. Today, people say it less because the models are so impressive that they paper over a lot of the sins, but the sins are still there. I mean, they just show up later, I mean, as confident failures instead of the obvious ones, and they’re the worst ones, right?

So, what has changed? I’d say two things. One, the cost of getting to a working prototype has collapsed. What used to take a team of six and nine months can be stood up by two people in three weeks. You know, that sounds like good news, and it is, but I think it shifted where the hard work lives, right? The bottleneck is no longer, can we build it? It’s like, can we earn the right to be in the decision loop. Distribution, trust, integration, you know, that’s where the product lives or dies, now, I think.

And I think the second one—and I think this is a deeper shift—the product is no longer the output. I mean, the product is the relationship the user develops with the system over time. Ten years ago you shipped a feature, right? Today you’re shipping something that participates in how someone thinks. That changes everything about how you design for memory, for context, for being correctable. Most teams haven’t caught up to that yet. I mean, they’re still shipping features when they should be shipping judgment partners.

Brian: What roles or skills do you look for then in your hiring? Like, do you have a core type of team that you throw on a product like this? You know, the classic model for a long time has been product design, product management, and a technical person, usually an engineer or data scientist, whatever it may be, in the case of a data product. Is that still the formula, or has that changed?

Rana: I mean, the classic triad still exists, right? But I’d say it’s necessary and no longer sufficient. You have to layer two more roles onto every product pod, and honestly, those two are the ones I now obsess over in hiring. The first is, you know, you would loosely call a context engineer. I mean, this isn’t a prompt engineer, it isn’t a traditional ML engineer, it’s someone who lives at the seam between the model’s capability and the customer’s reality.

I mean, they spend half their time inside customer workflows, listening to actual calls, sitting next to the collection supervisors, watching a clinician triage, and the other half they’re shaping how the system represents that world internally, right? What gets remembered, what gets surfaced, what gets ignored. I don’t think this role existed ten years ago because the model didn’t have enough flexibility for context to matter that much. I mean, today the context is the product, and if nobody in the pod owns it, you end up with technically impressive system that doesn’t feel generic to every buyer.

Brian: Yeah. Yeah. The AI Instinct: The Future of AI and Human Decision-Making. What’s that?

Rana: That’s my book.

Brian: [laugh].

Rana: It’s going to come out soon. Uh—

Brian: August 25.

Rana: Yes, August 25. Published by Wiley, forward by Kai-Fu Lee, which I’m still a little starstruck about, honestly.

Brian: Congratulations, I saw that. Yeah.

Rana: The short version, it’s an attempt to take AI down from the abstract and put it in the real world, not as a technical manual, not as a doom narrative, not as a utopia pitch, it’s a book about how humans actually think, feel, decide, and what happens to all of that when machines start participating in the loop. So, the thesis, if I had to compress it, it is that AI is not arriving as a separate species that replaces us; it’s arriving as a force that changes what it means to be us. It’s quietly rewiring what we notice, what we believe, what we fear, what we outsource, and the consequence isn’t catastrophe. The consequence is drift. So, what I mean by that, a slow weakening of human agency that happens not just through coercion, but through convenience.

So, for that, you know speed is enough, and honestly, optimization is enough. So, the book walks through the history from the AI winters to deep learning to transform our base models, and then onto the present reality of cognitive, behavioral, and emotion AI—the stuff I work on every day—and then it pushes forward into territory most technologists don’t want to touch. I mean, what happens when you know cognition becomes distributed across humans and machines? What happens to identity, to consent, to choice, when a system can anticipate what you want before you’ve consciously formed it, right? So, I introduce a concept, and I call it artificial general experience, AGE, as a complement to AGI because I think the conversation about general intelligence is missing the experiential layer entirely. And that’s the line I keep coming back to is, like, the question is not whether AI becomes intelligent. It already is. We know that. The question is whether we become wise. So, that’s the book.

Brian: Thank you for sharing that. I could imagine an author right now writing about this topic would feel very nervous about the first paragraph, and by the time you finished the last paragraph, what has already changed during that period of time? Because book scale is not usually a couple weeks. What was that journey, just as an author? A little side here for you, did you feel like this was evergreen—you had enough perspective that it’s evergreen, it doesn’t matter what the latest model releases are, like, these things are still generally going to be true, and it’s time to write about them or did you have to do some rewrites because the industry is moving so fast? Just tell me about that.

Rana: Yeah, I mean, this is something I generally wrestled with, and I think any honest author writing about AI right now has to wrestle with it. I mean, I think what I decided early on, and it became kind of the North Star for the manuscript, I was not going to write about a write a book about the current state of models because you’re right, by the time the ink dries, three new releases have happened, and two benchmarks have been broken, and then, you know, somebody’s published a paper that reframes a piece of it. If I anchored the book to capability snapshots, it would be obsolete before it shipped. That’s a losing game.

So, I made a deliberate bet. I wrote a book one layer up, not about what the models can do, but about what happens to us, you know, when these systems sit inside the loop of attention and judgment. That question doesn’t change with the next model release. The mechanics get sharper, the stakes get higher, but the underlying dynamic that once a system participates in how you think, decide, and notice is the most important property, is what it does to you over time. That’s evergreen, right? That’s the human story. It’s not a capability story.

Brian: Yeah.

Rana: That being said, I mean, I’d be lying if I told you there were no rewrites. I mean, there were, you know? The chapter on hybrid cognition got reworked when agentic systems became real, instead of this theoretical, right? I mean, so the sections on autonomous agents and long thinking, those needed to be updated more than once. And so, I mean, but I’d say the lesson I took from this is actually mirrors what I believe about building products in this space, it’s that durability comes from depth of principle, not breadth of detail. I mean, if you’re writing about AI today, you have to write about the human side, the cognitive side, the ethical and the experiential side. Because the technical surface is just going to shift under no matter what you do. And I think that’s the focus.

Brian: Rana, thank you for being so transparent about your experience, both as an author here and as a CEO. I wanted to ask you to just share anything you’d like in terms of closing advice for other founders, operators, heads of product at data product companies, any lessons learned that you feel like they need to hear from you.

Rana: A few things. I’ll try to keep them tight because I think the most useful advice is usually the most compressed. First, like, get obsessive about what your product does to the user over time, not just in the moment. We’re all trained to optimize for the session, the click, the conversion, but if you’re building anything that touches judgment—and I think most data products do—the real question is, what is your system is doing to the operator’s instincts after, like, say six months of use, you know? Is it sharpening them or atrophying them? I don’t think most teams have any answer to that question because they’ve never asked it, you know? So, I’d say you should start asking it, you know, build something around it, some telemetry around it. I think it will change what you ship.

Second—and this is for the founders, especially—your moat is rarely the model; it’s the loop, right? Whatever closes the tightest loop between decision, outcome, and learning wins. Not whoever has the biggest model, not whoever raised the most, not whoever shipped first. The loop. If your product doesn’t get better from being used in your customer’s environment, you’re renting, you know, a position, not really building one.

So, I don’t know, the last one, I’d say be careful about the seduction of speed. The cost of building has collapsed, which means everyone around you is shipping faster, and there’s enormous pressure to match that pace, but the things that actually matter, trust, legibility, the operator understanding why your system said what it said, I don’t think they compress. I think they take the time they take, you know? And I watched companies sprint themselves into a corner where they have impressive capability and zero adoption because they outran the human of the side of the equation. So yeah, I think you know, honestly, build something you want to live alongside because increasingly I think that’s what we’re all doing, right?

Brian: Yeah, the third point that you made, I think, is—I mean, this is literally what my LinkedIn feels like right now. It’s just this race, race, race, faster, faster, faster, and it’s always about how much more artifacts we can create faster [laugh]. But you don’t hear about, like, outcomes and benefits being created faster. Like, we’re getting better [laugh]. So, I’m really glad that you brought that up because there is a lot of hype and noise here about velocity and all this. So, thank you so much again for coming on the show. Where can people follow you? Is there a—LinkedIn best? A website? Tell folks how to reach out to Rana.

Rana: Yeah, I mean, thanks Brian. It was a great conversation. I appreciate you pushing on the human side throughout. I think it’s rare and it matters. If you want to find me, the easiest path is probably, you know, ranagujral.com. That’s the hub. There you can get to everything else: my writing, talks, the work we’re doing at Behavioral Signals. If you’re curious about the company specifically, behavioralsignals.com is where to go. We’re building voice intelligence for high trust decisioning, things like intent and risk inference from speech. And there’s a lot more on the site about where we’re applying it.

The book is the AI Instinct. It’s out through Wiley, you know, and there’s a companion site at theaiinstinct.com. You can also get it from ranagujral.com. And I will be posting supplementary material, some of the frameworks I couldn’t fit into the print version, ways to engage with ideas more openly and deeply. If anything we talked about today resonated, you know, the book gets much deeper into experience side of intelligence. You know, we talked about AG, so LinkedIn. I mean, I’m very active on LinkedIn. I post pretty regularly about what we’re seeing in the field, what I think where the industry is drifting, and occasionally things that frustrate me. So, I mean, I think any of those options are great.

Brian: Sounds good. I will drop those in the for people. Rana, thanks again for coming on Experiencing Data.

Rana: Thank you.