432: Product-Market Fit in AI Security with Gidi Cohen

Welcome back to the Predictable Revenue Podcast. I'm your host, Colin Stewart. Today, I'm joined by Gidi Cohen, the founder and CEO over at BonFi, and we're gonna talk product market fit. Before we jump in, founders, let's be real.

Scaling a company is tough. You're juggling product, revenue, hiring, and a million other things. But what if you had a proven framework, proven people here to help you navigate the chaos? That's where our founder coaching program comes in, whether you're trying to find your first customer or fine tune your go-to-market strategy.

We're here to help you build a business that's, well, predictable. Welcome to the Predictable Rated Podcast, where sales leaders teach you what's working for them so you can build it yourself. Gidi, welcome to the show. Thank you so much for joining us.

Yeah, Colin, great of being here. Thank you. Thank you for having me. Of course.

I'm excited to dig in. I want to start talking about Bonfi. Bonfi, sorry. Bonfi.

Bonfi is good. Where did the idea come from? Yes, so I would say the origination of the idea came in 2023, before we started the company, obviously, where it was clear that the AI is taking off in a very substantial way. Now, I think we'll see it nowadays in a substantial way.

Given all of my experience and my co-founder experience in the enterprise security market, it was clear to us that it would create a big shakeout of what happens in the security space, and especially as related to data. into AI, within AI, outside AI, and all of that. So it's okay. There is some real thing going on or will go on in this space.

And then let's dig in. So that's how it started. And so from like, did you see something like Mythos coming all the way down the pipeline? Or was it more the interacting with the models becoming a greater security risk than we typically are used to?

Yeah, I think that it's probably all of the above. I mean, it was clear to us that a few things will happen, and I think it's happening big time. One, that due to automation, regardless of automating writing an email or reviewing a document or taking much more complicated stuff, will mean that, one, AI can make mistakes. Second, humans are going to get more and more out of the loop due to the automation and trust in it.

Third, you're now connected to enterprise workflows and the like, and definitely the risk level will increase significantly. So it was clear to us that, again, automation, humans getting out of the loop, the inconsistent behavior of AI, LLMs, even today, not just three years ago, all of that will just cause a lot of anxiety and actual risk in organizations. So you have this insight, which I think is in hindsight, obviously, you know, pretty on the money. How did you go?

Did you just start building and saying, hey, this is the vision. This is what I see coming in the future. I am the Oracle. Let's go build that.

Or were there some steps involved talking to customers, interviewing folks? Like help me, walk me through from like idea to when you first kind of started getting serious and maybe started writing some stuff. Yeah. So I would say maybe the first advice I would give to everyone, including myself, if you have a great idea, sleep on it for a day before you kill it completely.

Right. So first of all, right, you need to soak yourself. Right. Especially us.

Right. We've been in the industry for a while, Danny and myself. We've seen a lot. We've done a lot.

And we know not every great idea is an idea worth pursuing. Right. Interest, competition, the customer needs, all of the above. But I would say right after that, it was clear that something big, potentially, right, big can happen here.

It's just talking to a lot of customers, a lot of prospects, right? I know many of them, right? Many of them were my customers in previous life and many others that I never talked and met before. And we spent a few months, right, of just talking to tens and tens of people that could be investors, chief information security officers, right?

our domains, I think cybersecurity domain and a lot of others, just to basically poke holes in the idea on one end and on the other end to see if, you know, the idea has some merits and some lags and some interest and whether what we see that will come a couple of years after that is something that others share the same vision. So I would say a lot of validation calls to tune both our understanding whether this is a real pain, is it understood at all the pain, and what should be potentially the strategy of addressing it.

tens and tens of discussions. I love that. I've got a couple of follow-on questions. One, what was it specifically that you were hearing from these people that you were interviewing that made you say, this is the thing, that gave you enough confidence to say, yeah, we're going all in on this direction?

And then two, how did this process differ from your approach at Skybox, your last company? Yeah, I would say that the initial part was relatively similar, right? talking to a lot of folks, getting a lot of feedback, et cetera, for sure, right? So that was from that perspective very similar.

I think that what was different, as opposed to, let's say, my previous comment, Skybox, where network security, vulnerability management were relatively established things. It was not mature on them, but it was about, can we solve some kind of a painful problem or not, right? Here, the problem was different, right? In a sense, it was clear that AI, from an enterprise perspective, is just in the very, very first baby steps.

So it wasn't just about whether there's a current pain at that point in time, but whether there's some short vision of, I would say, future pain, which is not easy to do, to understand whether it makes sense that things are going to align, pain is going to develop, needs are going to arise on one hand. And second is that it's clear enough that existing solutions, because data security, right, the space that we are in, right, AI, data security. But if you're looking at data security by itself, it was not a new space.

So the fact that there are rising needs possibly in the future doesn't mean there's a need for a new startup with a new approach, right? So I would say a lot of it was a conceptual validation more than we have a problem today that we must solve. And that was very clear to us from day one. And maybe just for the uninitiated, help me understand the difference between just a traditional cybersecurity play and maybe a cybersecurity company focusing on data like yourself.

So I would say that if you're looking on cybersecurity as a whole, it touches a lot of different layers of the IT stack, right? It can touch network and storage and cloud and on-prem data centers, application level, data level, users, right? So there are a lot of different elements. And most of the cybersecurity vendors focus on one of those elements and try to be really good at it because they're complementary to each other.

And each one of them is a very complex world by itself in general. So that's that. So one, if you're looking, let's say, on endpoint security, anti-malware, email security, firewalls, CASB, right? Each one of them is a wall by itself, right?

If you're looking at data security, which by itself has a lot of different, you know, segments within it, it's about focusing on the data itself and protecting data from misuse, leakage, compliance issues, and a lot of different elements regarding the actual data. So the focus is data as opposed to the focus is on network connectivity, identity. Focus here is on data. Now, when we started the company, it was clear to us that the level of satisfaction by organizations at large of their data security stack is very little, very low.

A lot of reasons, but primarily accuracy, technology that are not kind of up to task. We're going to talk today about product market fit. It's a whole space that between us never had a product market fit. Selling billions, right?

this above a 10 billion dollar market and still did not find paypal at market fit. And this was part of what was exciting to us, right, as a new startup, saying, okay, fine, there's going to be a whole set of new interest in paying due to the option of AI. But we thought that a lot of the legacy data security tools are just not up for task even before AI, definitely not fit for the world of AI. That might create a great opportunity for us.

That's a really interesting way to think about it. I'm curious, you know, when you think about your, the incumbents not having my, I like to think of it as like product market fit is strong as opposed to binary strong or weak. Cause it's binary means like, ah, they can't sell anything. But if they have billions in revenue, they clearly have something.

Exactly. That being said, if I have one customer and $200 in ARR, I might have some form of product market fit, but it's not very strong. And so I'm curious, looking at competitors, looking at fairly large incumbents with millions or billions in revenue, what made you think that their product market fit wasn't strong and that they were in a weak enough position that would open up a gap for you to come in? So, multiple reasons.

One, as I said, I talked to tens of CISOs and I like many of them. And it was kind of very broad consensus. So, it's not something that I need to discover or uncover in the market. It's almost like a well-known chronic disease in the space that most of them are sharing the same type of challenges.

And talking in a second about why AI made it even tougher, right? But in general, right, data security is all about understanding content. I mean, what does it mean this piece of content? Is it regulated or not?

Can it get from point A to point B? Should it allow access to those type of users to get to the data? Without understanding the data really well, you just can't apply any of those type of, let's say, logic or controls around it. So the issue is, as I said, the chronic disease in the space that the solutions are just not accurate enough.

Such enforcement can actually take place with high enough confidence, right? Think about if every 10 emails in a company, let's say one out of 10 emails in the company is being flagged as a leakage wrongly. You have a big company, maybe let's say 100,000 emails a day. You have 10,000 of them are flagged and stopped along the way.

That's a big business disruption. No one's going to use a solution like that. So what's happening in the data security space over the years, that on one end, the organization bought it for compliance reasons, so they showed their controls and visibility. But the use of that was so limited or is so limited due to lack of accuracy and the minimal level of enforcement, again, due to the level of disruption.

Now, all of that has nothing to do with AI. That's the state of affairs that everyone understood or agreed to before AI. Why AI makes it tougher? Not only because architectural information can flow in a lot of different ways, and who knows what LLNs will do with the data.

it's primarily because humans are getting out of the loop. So think about, let's say, when someone is writing, let's say, an email that is leaking information from the company, let's say, by mistake. You trust employees to apply judgment, to avoid those mistakes, correct them, et cetera. They have context.

They have the context of the dos and dos in the organization, ethics, policies, their training, et cetera. AI doesn't have any of that. Now, when you take the humans out of the loop, how do you know what it does? So not only does it at large scales, in new flow, new architecture, in huge volumes and fast, it does that with very, very little context of the organization.

And that's what basically kind of, if you're looking at one, the deficiency or the chronic disease, let's call it the data security space, the lack of accurate understanding of content. So you cannot apply enforcement rules. And all of the challenges that happens with AI, potentially, right, that humans are getting out of the loop and basically you are leaving the judgment to AI to take care of your data. These are actually the two out of three I talk about the second and third one but two main reasons why we start the company Interesting It funny when I got started in my career data security was disabling the export button in all the apps that I used.

Like, no, you can't export your accounts or your contacts or your whatever. Yeah, you can't forward that email. And you're like, well, okay. That's come a long way since then when we've got Claude and ChatGPT writing our emails, preparing our spreadsheets.

a friend of mine's a hedge fund manager and he's having it it's got access to his bloomberg and he's got it creating all these models and stuff and i'm like man can you imagine what would happen if there was a hallucination in that chain exactly i i'm honestly it's terrifying because he's controlling a lot of money like i hardly trust it to build code zero to one that that doesn't break i couldn't imagine having millions at the on the other side now in fairness he's just doing a lot of modeling he's not moving stuff around with cloud but but that's exactly why we started the company.

At the end of the day, this unknown type of risk, when you want to adopt AI fast and to enjoy all the benefits, creating basically from our perspective the opportunity. And as we looked at the data security space, we said, you know, I'm not saying that those companies are bad. I'm sure they have good engineers. As you said, they're selling billions.

So probably they've done something well, but not well enough to be the control for AI with enforcement and replace or fill the gaps that humans are leaving behind. Yeah. And I mean, you're trying to sit there at the user level, CLAW, CHPT, Codex have hardly figured this out at the engineering level where you have a lot more control over what the models can and can't do. So you go through this, you've got these interviews, you go through these interviews, you find this gap.

Did you just immediately start building or did you do some validation first of like, hey, here's a thing that we're going to build. How does that sit with you? What is the size of this? Who are we selling to?

Or did you immediately have a good sense because of your previous company that, hey, this is going to be a CISO sale. Yeah. So I would say that a lot of the validation was to understand who is the buying persona, actually. Because again, we knew that today, we assumed that the need will arise, will develop solutions where the concept already the concept of the technology of how to do that, to implement that, at least in our heads.

What do we want to validate these two things? One is who is the buying persona, which wasn't clear initially. I'll talk about it in a second. And second, what are the highest priority use cases for those personas?

So what was our debate in the bank persona? The early days of AI in the context of 23, not in the context of AI, I started 50 years before, 60 years before, whatever. Patients say, did not know exactly, including security teams, whose responsibility will even fall under. So think about, let's say, if you're using a model and the model is wrong in something, elucidation.

Is it the operational issue? Is it security issue? Is it the business unit that owns whatever the business process issue? What is it?

So initial response was, yeah, it's not security issue. I mean, they're not responsible for an application you run. Fine. But what about if the integrity issue resulting from cyber attack or from prompt injection and people scratch their head?

Yeah, maybe it's their issue. So my point was, it was very, very unclear. Should we serve to legal, compliance, and this line, security, IT, who is the buyer? And we talked a lot.

And it took us a few months, I think, to figure out that actually our initial intuition, that security buyers are going to be the right ones, that's where we kind of settled at the end, right? With enough feedback and enough background in cybersecurity space that even if things start outside of security, at the end of the day, you need to put some technical controls in place. It lands on the lap of security team, even if it's not stemming initially from there. Anyway, so that was one dimension of validation.

or if they're going to be the buying persona, which team in the organization is going to be responsible for adopting those solutions. And second one was more about within that, they're going to be the preferred use cases, so where we need to put the priority. And I would say that that's where it was toughest to get the, what's called, the credible answer because it requires a lot of imagination of people that are not sure yet they're going to own the problem of where would they want to deploy a technical control that, you know, will fit one of the use cases they are responsible for.

I like that. Does that make sense? Yeah. So you've got these different kind of layers of the onion, so to speak.

Yeah. And so from, you do all of the validation, you kind of get a sense of the size, the shape, the different layers and the different ICPs of who you're going to have to sell to. At what point did you nail your first customer or have sights on your first customer? Was it folks realizing, oh, you're working on this, I want to pull you into this, or was it more of a push in a rock up a hill?

I would say it was probably closer to a push than a pull from that perspective, right? So we have a lot of network ourselves, investors, and others. So we talked with a lot, and there was a lot of interest for different design partners, some people that we knew from our network, but some of it was actually completely called outreach, that we've done a complete cold outreach, which was a good test for messaging. And we got kind of a pretty good response for that.

So I would say very early on, probably very few months after we started development, We had design partners where we can actually test super early implementation on their data so we can actually verify whatever we do is drawn with real data as opposed to synthetic data that we need to generate ourselves. Gotcha. And so it was more of a push. We're talking about, and you don't have to tell me who it was, but talk to me about that first customer landing and what was that experience like?

You're pushing, you're doing the cold outbound. What got that first customer to say yes? I think that during, we started the company in 24, right? So I would say probably in the latter part of 24, they just start to realize, especially on the security side, that something has to be done.

So some of them were starting to talk about AI governance and some of them talked about specific security concerns. So I would say that it was kind of a pure, still is, but then definitely pure, kind of the early adopters type of crossing the chasm type of situation, right? So there were early adopters that were very curious about what can be done in the space, what kind of problems they need to think about in the space, where it fits in their priorities. So I would say there was a lot of interest from people that wanted both to collaborate, but especially because they had a lot of interest in actually learning about the space, understanding pain points and potential solutions.

Because you're doing something that was new and unsolved. And so there was a lot of willingness to collaborate. Exactly. It was unsolved for many, many years, even before AI, if I'm not solving the context of AI.

And there was a lot of room for collaboration between us and them because they want to learn as well. It's not that they had kind of very specific requirements that you need, you must solve. It happens slightly later. But initially it was, yeah, we did something.

We don't know even how to call it, but it makes sense that the data will be a big risk. And to work with startups, actually focusing on that element is of interest. Gotcha. How did you figure out your first kind of scope of like, all right, we're going to cover this ground as part of it?

because I imagine that one of the struggles with cybersecurity around data could be that you could cover every attack factor. And so how did you come up with like that first list of like, it's going to be A, B, and C? And then how did you think about pricing? Yeah.

So I think that we understood pretty well, again, both because of background, but also because of working with a lot of customers and some design partners, et cetera, in total scope of the use cases. So I'm not saying there are not new ones. we just introduced some this year things we could maybe imagine a couple of years ago, but, you know, driven directly by agentic development. But even then, I think I would say that probably 80, 90% of the use case where the domain was pretty clear, right?

So from our perspective, we tried to, in the Venn diagram, right, to look at the cross between two things. What customers thought is a high priority use case for them to address on one hand. And for us in the, let's say, the ecosystem that they typically have, which was not tough to get, Microsoft 365, Google Workspace and the like, right? Super common.

So we didn't need to get esoteric around it. And second one, we want to make sure that it's viable technologically because we knew from day one of starting Bonfire, it's not a technology for the faint of heart. It's complex technology, needs to work accurately, right? As we said, it's an unsolved problem at this point in time, even before AI, needs to cover a lot of situations, needs to be very scalable and need to be cost-effective, right?

So we knew it's going to be a very complex technology to develop, right? It took us about five calls to get to beta with quite a few engineering and it continued since then. So part of the Venn diagram is to look for what the customer wants and prioritizes their use cases in their environments. But also what's doable is the first one or two use cases we can address, right, in terms of performance, in terms of ecosystem integration, etc.

So basically that's how we made the decision. So it was definitely not driven only by the demand, but also by the supply. Again, we knew it's going to be complex layers of technology we're developing that would not be able to do everything we want in just version one, definitely not in a better version. How do you think about the timing of when, you know, there's a technological risk in the project?

You know, we're not even sure we can do some of this stuff. How did you think about paying that off? You know, did you have some of this solved before you went to customers or did more of that come up the more you learned about the different things that they wanted to solve? Yeah, so I would say that the core technology we had in our head before we raised money in the very early days of actually validating the concept with customers, right?

Before we started the company, basically. So we kind of had a very, very good answer. Again, we have a lot of experience in enterprise scale, algorithm development, and data-driven solutions. So we had a pretty good idea of how it's going to be working.

One of the reasons why we worked very early on with some design partners to get access to the data because we want to validate the concepts. conceptually can work really well on real-life data and not just synthetic data. That's why we engaged very, very early, way before we were ready for a beta or alpha version, just to be exposed to data, which helped a lot, right? Some stuff you just can't guess, right?

How data looks like, how it comes about, how to deal with it, et cetera. So when we got to, I would say, beta phase, about four or five quarters after we started, the product already worked pretty well, actually. So it worked really well because we tested it. I think we designed pretty well.

We knew pretty accurately how to develop this technology ahead of time. So it was more about implementation and testing it early on customer data. Gotcha. If it worked so well in the beta, how did you think about pricing it?

Was it, hey, you get to use it till a point where it's working, or this is a paid pilot proof of concept and it's going to be six figures? Yes. So luckily, data security space is not new, as we said earlier. So there's already relatively thinking some established price points of how much organization we need to pay for solution data security at large per user, per volume, per stuff like that.

We didn't want to, let's say, we'd not have any motivation to get too creative about the pricing price points because actually the established price points are pretty good. What's not good is the solutions, right? So we didn't want to renovate pricing. There's nothing bad in that, but there was no need to.

to the one that was more making sure as we are using a lot of AI ourselves, where AI native cloud native solution is to make sure that while we can keep similar frameworks of pricing, like established data security, actually established is to make sure that our unit economics makes sense Again not optimal right Starting but just makes sense which is very tough to do from the get But it was very important for us Gotcha Your first customers came from that kind of early conversations with investors and friends and network When did you start to move outside of your network and look for customers that were, you know, you couldn't get a referral to?

So we, almost from day one of the company, always did also cold outreach. Always. One, because you need to, right? You want a bigger pipeline, bigger exposure, et cetera.

And secondly, it's just a great way to validate messages, right? There's a big difference between someone not doing favor, but you know, someone trusts due to the network effect. I would say it's more trust versus someone that never heard about us, don't know who we are, no trust is established, but care about what we are saying and what kind of value we can deliver. So we always did it and always do.

I love that. I'm a huge fan. And I think, you know, the failure state is with outbound can be very unkind in terms of you try a bunch of things, you send a bunch of emails, you get zeros. How did you think about the, you know, testing?

You know, is outbound working or not working for us? Or is it the message that's resonating with folks or not resonating for folks? So we were very, very, I was very, very systematic in that in the early days. So we had, not kidding, thousands of outbound communications, thousands when we were still in stealth mode.

And basically, every few hundred, I kind of played with the message. Did message like, you know, we are data security companies solving AI problems. Message, okay, this is my background, love to get feedback, right? So different takes, some of them are more personal, some of them are more pain-oriented, some of them are more solution-oriented, and see what resonates and repeat it.

Change messaging along the way because AI is moving so fast. So even if self-messages worked in 2024, 25, they will look some outdated. Think about Copilot was a big story in 2024. Now, not a lot of people talking about that because it's bad or good, just the world moved on architecturally and conceptually, right?

So that's part of the challenge and opportunity space that the interest of organizations is changing so rapidly. And the knowledge or lack of knowledge is changing so rapidly due to AI. And, of course, data security needs to protect AI or AI type of usage needs to come along. So I would say a lot of experimentation, but in big volumes, significant volumes.

What would you say was the thing that made the, like, was it the experimentation worked and it was the volume that worked and you just sent so many emails that eventually you got a strong enough signal that said, hey, it's this segment resonates with this message. And it's this particular piece of the product. And like, that was the through line and you just kind of brute forced it. Or I find a lot of people say outbound doesn't work these days, which I disagree with.

I think they're just doing it wrong. And so I'm curious, what do you think? What do you attribute your success to? Was it the testing or was it something more like people just needed what you're doing?

Yeah, I would say that it changes, right? At the end of the day, when you're trying to get the attention of early adopters, early adopters know that there are early adopters. You don't know that, right, if you don't know them. So my point, the early adopters react very, very differently than people that are, you know, the early majority can terminology of crossing the chasm.

We can use more modern type of analogies, but they are very, very different, right? And a lot of the early adopters are looking to learn about new stuff. They want to influence new stuff. So they enjoy the benefit of basically being sponsored to a company and being part of the friends, family, even if they never met you before.

Because they are also curious about the domain. So it's a very specific type of persona that you just can't tell by not knowing the people. And that's why you need to contact a lot, right? In general, there would be very, very few percent in any segment that would consider themselves as early adopters at large, and you cannot get to all of them.

So that's why it requires a lot of touch point and not try to sell too early when the market is not mature to that. In a sense, understand that whoever is going to respond is going to be the early adopter. The data just wouldn't. It's just too early.

Too early in terms of your brand, too early in terms of your lack of readiness because you're telling them that we're still in stealth. So they say, ah, it's not for me because I'm not an early adapter. I don't have time for that, right? So just understand your audience and the persona that you are targeting and just assume that because there are a few of them, right, a few percent of the total population, whatever it might be, just need to contact a lot of them and or to use your network on top of that.

I mean, I think it's a both-and situation that both cold, you know, Pure Cold is a channel that will work as long as you give it enough time and attention and do it in an intelligent way. And working your network is going to work, assuming you have more than one person in your network. Exactly. Yeah, it's me, myself, and I are going to hustle our network.

Describe the moment when you realized you might have product market fit. I would say that that's starting to see when you start to close the first deals and you see why really the customers, why they really buy. And again, by the way, there are different segments of customers. And the reason, the why might be different to different segments, right?

Depends on the product. Think about when Microsoft is selling Excel, there's a very, very different why if you are a financial analyst versus someone completely different, right? Same tool. And for us, right, we knew from day one that we were building a data security platform.

We're not building a tool for a very specific attack vector. Nothing bad in that. But that's not what we're doing. because part of what we believe that AI is going to touch data in so many different ways.

And again, one of the, I would say, second chronic diseases in the space, maybe in general, in cyber, not just data security, you know, to solve one problem, you need so many different tools. It just kind of feels unattainable, right? Not budget-wise, not attention-wise, etc. And it's true for the data security space as well.

But beyond that, we believe that AI is going to touch data in so many different ways, input from the user, output to the user, third-party system, reading data repositories. talking to MCP servers, right? So it's kind of like a four-directional type of communication of data that we want to provide a solution again with all of that. So to actually really provide a real platform that can cover all of those directions of communication for data in rest, in use, in transit, in one swoop.

So we can imagine that once you have that, you can do a lot with it, maybe too much. So to find what is the right circumstance, why customers would buy, why us, was they would say the first time, they say, ah, it's maybe early science, but now we understand that we can find a lot more like that because we know what to say where we are positioned such that we can have a very unique, valuable position compared to other, compared to incumbents, compared to maybe a more traditional, but bigger data security players or other startups as well.

Interesting. And so to you, it started to feel more repeatable, more like the product market if it was strengthening when you were able to understand why customers really bought and then understand what was really driving the sale. Yeah, exactly. So it's almost understanding, right?

You always have a thesis when you're building a product of how you're going to win, right? You're thinking, you know, we have differentiated technology, better pricing, better integration, better whatever, better UX, all of the above. But then when you see this thesis, and of course it takes, it morphs along the way, right? But when you see the thesis come to fruition, say, no, that's why we won.

That's how we designed it. That's what the customers appreciated. That's what other vendors could not, provide and that's why we were selected at the end and when you see that a few times already with the same type of let's say thesis of the capabilities value prop differentiate tools and accepted by the customer say no we're seeing something here that can repeat the how different was your thesis coming into it versus what you landed on when you felt that moment of like oh i get what they are they're wanting to buy was it apples to apples or was there something surprising in what they actually wanted.

So I would say what I'm saying now, it's not surprising, but it was a major evolution, right? So it was very clear to us from day one that we want to provide this multi-channel approach, dealing with the same platform with different communication channels and data source, again, because of the benefit for the customer, right? To consolidate the different kind of solution for different tech vectors in one platform that can do a much better job than kind of six, seven different tools.

I think what was clear to us, not clear to us, clear to the market even, or our interaction with the market is what's going to be the, let's call it, winning type of use case. Winning, not in terms of differentiation, but really in terms of high priority use case for the customers. I'm going to now select a new vendor, startup that I'm going to solve the problem for. And that thing was the most confusing element because primarily because the market is changing so fast.

So when we asked priorities for customers about when we started in 24, these are not the priorities of today. I can tell you that, obviously, but we're not even 25. So the point is that the priorities changed. We knew they were going to change, but it was sometimes tough to predict how fast and to what direction exactly they will.

And that's one of the reasons why we decided from day one to build more as a data security platform for different use cases as opposed to bet on a single use case type of use. because we knew that there is a very good chance that we're going to miss in the bat because the bark is moving so fast. If you're trying to chase the wave, you're always going to be reinventing and reinventing. Exactly.

So basically what we said, well, let's focus on the core. Let's develop the right platform such it's very easy for us to not adopt the platform, but to create, to be able to, let's say, take the same platform, same concept, same technology, and just apply it to another communication channel. So I'll give an example. For example, data in use.

So data in use kind of helping an agent to understand whether data they're exposed to create, share, resurface is, let's say, consistent with the corporate policy for how to handle data, right? This is a use case. Probably we imagined it two years ago. But, you know, there was no demand for that customer.

They don't know that they're going to get two agents, et cetera. For us, because we build a platform ahead of time in a way that's going to be very easy for us to apply to different information flows, was actually very, very simple in a matter of one short release to be able to support data in use for agents' reasoning loop because we build a platform to do it. So the point is we could not guess everything. We knew we are not going to be able to guess everything and do a bet right on every use case.

And it's definitely timing. So it's okay, part of the way to hedge it, not only to provide a better solution for the customer, but part of the hedging strategy, let's make sure that we have such a robust platform that it's easy for us to apply it to different information systems and channels as they evolve as opposed to try to guess ahead of time when exactly each one of them will come around. Make sense? Yeah, it's like throwing darts at a dartboard that isn't quite there yet.

It's going to be impossible to kind of hit a bullseye if you can't see exactly where the board's going to live. Exactly. So let's plan for it ahead of time as opposed to be surprised if we threw a dart and it did the target, right? Yeah.

So in this case, you built one big dart and you're like, we'll throw it in that general direction and it'll hit something. I wouldn't call it that way, but we knew the target is there, right? But there was a lot of, let's say, confusing signs, dark, missing lights, et cetera. And you don't see the target well, but you know it's there.

yeah and the and instead of betting let's create something can hit the target as opposed to try to bet with a very narrow dot and hope that it will hit the target in the right place at the right time were there any customer requirements or priorities that surprised you when you were developing the the platform doing your research you know going through the interviews um probably Probably not I would say could be surprising I think that was actually one of the areas where I thought it was relatively easy to see the scope of what's possible, what's needed relatively early on.

I think what was surprising maybe to me that some of the use cases that we thought are not sold well at all by existing technologies. And the customers or prospects or design partners highlighted it. Still, it was not always a really good enough reason for them to actually make the replacement. Or to say, you know what?

They know it's not good enough, but it wasn't always not good enough in a way that justifies to put a different solution in place, in a sense. So there was always kind of like acceptance of, let's say, some of the things that are not working well, but if it is what it is, let's not focus on it. On the other hand, we're definitely seeing a lot of interest, right? To focus on a lot of the net new AI driven challenges, which makes a lot of sense.

That's why we exist. It's tricky selling into apathy where you know you've got a better solution, but they've already got something in and they're like, listen, we've already get 8,000 errors a day or notifications. Yeah, we don't want another one. Exactly.

We don't want another one. And you're probably saying, no, you shouldn't have 8,000 and you should have 12 and you should put a lot of time and effort into those. But they're like, no, no, I'm sorry. We already have 8,000.

We can't handle 8,012. Exactly. How do you get around that? Is that just saying, okay, coming to terms with, all right, we have this incumbent.

We feel like they've won this segment, even though we know their product is inferior. Customers aren't getting value out of it. We just ignore that segment for now. And we focus on the net new stuff where the people are trying to pull us in.

And then maybe we can expand into their territory once we land the account. Yeah, great question. So I think that's where it comes to ICP. And I think that the ICP in a very surgical way, right?

And I think part of what we found is that over the last year, is that there actually, without getting too many technical details, etc., there are actually three or four prototypes, let's call it that way, of ICP where we can be uniquely strong. Not just uniquely strong in theory that because we know we have a win-day arm wrestling, strong in a way that we are setting to a solution where, One, it's a must-have to buy. Second, we have a significant competitive edge.

Third, there's a big white space that is not served or underserved with existing vendors. Some basically say, you know, these segments will buy us. They buy us because we provide a solution, much more cost-effective, works great, no good alternative, no strong incumbent. And apparently, when you have enough interaction with the market, you can find them.

And we found a few of them. And that's where we're focusing, knowing that there's always going to be in the future the opportunity potentially, right, to maybe do a displacement campaign as we grow. There's more trust. Do it later.

What we want to focus now on buyers that have significant challenges. They have realized it and they just don't have good alternatives for, again, different reasons. We can get to the details in our specific domain. But that's what we are looking for.

And I think we found a few of those patterns. And what we are working now is to find more systematically a pipeline, right? new customer, new prospects that fit that type of patterns. Interesting.

So that was leading right into my next question of, you know, it sounds like you started outbound in the early days. I imagine you've got a few sales folks, some marketing folks on the team. You've got these new segments. What comes next for Bonfi?

Bonfi. Yes. No, no, you're sure. So what comes next?

It's basically, I would say, proving this product market fit in slightly bigger scale, right? So to make sure that those, let's say, the early signs and the early customers can are the prototype for the next ones behind them. Let's go that way, et cetera, to refine it. And as we do it for probably another two, three quarters, it then starts scaling much more significantly.

Gotcha. From a going multi-market, multi-product, how do you think about that? Versus, you've got this thing that customers are pulling you in for, right? They're excited about the AI piece.

And you know you have these big incumbents that you can do a better job for. Is that something you've got your eye on now down the road? or is that years down the road in terms of how you're thinking about going multi-product? So as I said earlier, right, our platform already does a lot.

More than typically it will do for a very early stage. So it does a lot, supports a lot of use cases, a lot of ecosystems. So from my perspective, a lot of the innovation, which of course we continue to do forever, the main focus is not necessarily, let's say now another use case. It's more about one, making sure it works really well in customer environments.

There are, if you're looking on the ICPs of the segments that we decided to focus on currently, there are thousands of enterprises we can sell there. So it's not kind of like we found 20 we can be good at. Let's win three of them or five and then go to the next one. There are thousands that we can hit with the current value proposition and the unique capabilities we have and we bring to the table for them.

So we're not in the hurry to get to, let's say, additional pockets of the market. I think it will come very naturally as we mature, the market demand will mature. Some of those older players have kind of big kind of enterprise penetration that a lot of those enterprise will be probably next year or two or three in a cycle, big refresh cycle, which will be very natural for us to get into. So the point is that they will not inherit to invent yet another feature and find a few more buyers, not because it's not legit.

It's just not needed in our space. I would say we are very feature use case rich already as a platform, relatively mature for our age. And now I would say it's more to have the repeatability in the one or two ICPs we're selling to see showing repeatability grows as fast as we can once we see that and put more resource on that. And then we can kind of explore additional ICPs regardless if it's the displacement of all the solutions or any other type of strategy.

I love the focus. I find it so easy to get to, all right, we've got one. Now let's go wide. And now we'll build every single feature, every single platform, every single element of the, you know, that we heard in the customer development interviews.

And then you end up with this huge kind of dinner plate of, you know, everything. You went to the buffet and you just grabbed everything. And there's no rhyme or reason to, you know, why is this here? And why is that there?

I love the element of focus. Is this something that came from like a learning that came from your first company, like when you were working on Skybox? And, you know, or is this just naturally the right move? And so logically, it makes sense.

Well, everyone takes a lot from their experience. And of course, I have similar from Skybox. I would say it's not that we were, I mean, we were focused there. I think the difference, right, is we start SkyMesh selling primarily to very large enterprises always.

And when you start with very large enterprise, you have a long list of requirements in a lot of deals, right? So you end up with a very long day of capabilities that are great for those enterprises you sold to, but creates a big technical debt, right? It's almost too big, right? Too tough to test, too one-offs.

Even in theory, they apply to every customer on Earth. They are very specific to one customer or five customers that they take this very specific situation. So I would say it's not that we are designing and design bonfire to be enterprise-grade from day one. But I think what we are trying to focus on is the set of use cases, which, again, as I said, we have quite a lot.

It's not that we start very narrow. We start relatively wide. But the focus on use case, we think, based on what we've seen in the interaction with the market, that there's going to be a lot of repeatable type of demand for that. A lot.

A lot means thousands of enterprises. Now, it doesn't mean that we're not going to be opportunistic here and there. doesn't mean that we're not going to have mistakes. Here and there are things that we think are applicable to a lot and then you find yourself only one or two customers adopt.

I'm sure that we'll have those type of mistakes as well. But I would say that I think what I found in data security that in general, the level of use of the old solution is not high. As I said, there's a big spending, relatively little use of those solutions. So we are intentionally not trying to do everything the old solution did and now do more.

It's more like the Blue Ocean strategy, right? You want to drop things. Say, no, if someone wants to buy some very, very complex features and outdated ones, go ahead and buy it from a different vendor. You want to have a streamlined solution which is accurate, easy to use, scalable, with your AI challenges, that's what we're doing.

So basically, not trying to do everything for everyone. Definitely not trying to repeat the old generation capabilities, just add another layer. Say, no, we all learned from the old generation what's good and what's not. let's not try to replicate again with new code base what is not useful let's focus on net new which is useful and again it's a lot of the daily decision making one day you know we can tell if it all made sense or not but it's our approach it seems like the pace of startups has accelerated the pace of you know competing against build it yourself you've got to work with a number of startups where you know they're working on something and it was you know the value prop was a little bit thin, maybe pre-AI or like early AI.

And now, you know, you go up against an internal competitor with an engineer who's like, oh, I could build that myself in three days or in a month or in a week. And so I'm curious, you know, I don't imagine this is happening as much in the cybersecurity space, but I'm curious, is this something you're seeing? And then is this something you think is going to be more or less prevalent as AI continues to get better? Yeah.

So first of all, I think it does impact the cybersecurity space, right? We know about MITOS and everyone looking at the code scanning and vulnerability management, incident response. There are a lot of areas where at least some organizations believe they can do a lot without, let's call it a commercially available tool, etc. I think the data security space, not the only one, there are a lot of space in the cyberspace doing data security, which I would say is very unlikely.

It's going to be driven by or affected negatively by adoption. I think it's going to be primarily net positive. Main reason for that is the missions are very different. Think about, let's say, in our domain.

Think about, let's say, we want to look to make sure that data access to your SharePoint, Google Drive is secure. There's an enforcement layer. The amount of access that is happening is huge. If you try to use kind of like some smartly, smartly talking about frontier model for every time just to analyze what the agent may do or may not do, this will go bankrupt very, very quickly.

You want to look, let's say, inspect that with, let's say, big LLM, every email the organization is sending. Every file was created over the last 20 years. It's just not scalable. It's not economic, not scalable, and not needed.

So there's a lot of algorithmic work beyond, of course, the heavy use of AI that we do to make it efficient, accurate, broad coverage a lot. I would say that there's definitely our space. I think that I'm not saying data security at large. What we do at Bonify, I'm not concerned a lot about net beneficiary of we and our customers indirectly, right?

Net beneficiary of AI technologies. I love it. I really appreciate you coming on the show today. I feel like I could have kept you for another hour here, but we got a timetable we got to stick to.

If people want to learn more about BonFi, what's the best place for them to go take a look? I would say the best is to go to bonfi.ai, our website. I think it's pretty rich with content, direction, et cetera.

So go at it. If you want to talk to us, fill a form or write in the chat, and we'll be happy to talk with anyone. Again, thank you so much for coming on the show. Bye.

Thanks for having me. Thank you. Thank you. And thanks to everybody for listening.

We'll catch you all next time.