63. Buying more security tools? You might be making things worse

Welcome, everyone, to another episode of the Security Podcast of Silicon Valley. I am one of the hosts, John McLaughlin. I'm joined today by Sasha Sienkiewicz. And we have the great honor to have an amazing guest with us today, Kabir Mather, the founder and CEO of Lean.

Welcome to the show. Thanks for having me, John. Sasha. Lean is a unified API for security data.

Is that spot on or would you like to enhance? Kabir, a little bit. Yeah, that's pretty accurate. We refer to it as unified API for security data.

We sometimes also refer to it as a security data fabric. That term, as I'm sure you know from being very experienced in the industry, is still not very well defined by folks in security. So depending on the audience, we use it sometimes and other times we don't. But yeah, we believe that what we're building could be considered a security data fabric.

There are three different interpretations of it. Yeah, it's actually what we do is we act as a middleware layer for security. Happy to go into more details about that. But our whole hypothesis for starting the company was that there are so many different solutions in the space.

We have all of these different data formats and perspectives on a finite set of assets within security. And there's no real interconnectedness. And that's really the role that we see ourselves as playing. And what would you say the biggest pain points that pushed you into starting this company?

I was really inspired by the work that my co-founder and senior CTO, Neil, did at a company called Blue Point. He was, it's an MDR and its head intelligence provider. He was a senior principal engineer there. MDRs, of course, they typically specialize in a certain stack of tools that they work with.

In this case, Blue Point is a unicorn in the space that had hundreds of fairly large enterprise customers as well as government clients. And they had built their whole platform on top of Demisto. Demisto is a SOAR for those of your listeners who might not know. It's now, after getting acquired by Palo Alto, referred to as Palo Alto XSOAR.

And for various reasons, that platform did not scale for the requirements that Blue Point had. So they decided to rip it out and build their own SOAR platform. And Neil was put in charge of that project. And as you might know, when you build something as complex as a SOAR, the first thing you have to do is you have to build a whole bunch of different integrations to display security systems.

You have to do data normalization. And only then can you actually start to build the automations and workflows on top of that. But that was the key point of frustration. That set off the aha moment, the bulb, like bulb in his mind.

And that's what set us on this journey, because we figured, hey, if he had this frustration, then it says are that other people in the industry didn't. And how did you meet your co-founder? So we're all based out of San Francisco. There's actually three of us.

Our third co-founder is Akash. He's the COO. Neil and Akash had met through San Francisco Circles. This is why, on a slight tangent, I believe this is the best place in the world to start a company is because you have all of these serendipitous connections with really bright, focused people.

They had met, and then Neil and I met separately. And we were all thinking about starting a company. And interestingly enough, when we started the company and decided to work together, we were not working on a security problem at all. We were working on a completely different idea that we tried for two or three months, didn't see any meaningful traction with it.

And that's when we decided to get to this particular idea and security and had been running with this. That's spectacular to have a little bit of experience and to be able to identify, oh, maybe not that. Let's try this. Next.

Yo. And I know as an entrepreneur, you have to be a little bit crazy. You have to see the world in a different way. To see something that's off, something that needs fixing or something that needs a little extra love to make everyone's life a little bit better.

To do that, you do have to see the world differently. We express gratitude for your sharing, like how you saw that foundational piece across all of these different security technologies that needed to be unified, needed that extra love. Would you like to maybe share with our listeners, if you think of the founding team, everyone brings amazing stuff to the table always. And it's always very complimentary, those founding teams.

But what's your superpower? The one thing that really bring to the table that's this. Here's Kabir 100%. And something that you do just flawlessly and amazing and really shines.

Well, I don't know about flawless and amazing as a full thing you're constantly naming. And this is a long journey. So I'm sure I'm still making a lot of mistakes and I'll learn from them. But I think in my case, I've spent my whole career working for startups.

It's been 15 years now. And I spent time in multiple different industries. So I started my career in gaming, like mobile games. This is at the peak of iPhone launching and that whole ecosystem exploding.

Then I was fortunate enough to go to a tangential industry, which is ad tech, learned a ton there, worked for two startups in that space. Before starting Lean, I worked in B2B SaaS at a company called Typeform, which is in the MarTech space. I was leading product partnerships for them. But not only have I had a chance to experience different industries, but I've also worn a bunch of different hats.

So I've done business development. I've done customer success. I've led product teams. I've led partnership teams.

If I reflect on all these experiences, the thing that I really enjoy doing and I think I'm relatively good at is learning about new industries. So this has been a pattern in my career is switching the industry that I operate in every four or five years, roughly, and figuring out what levers to pull that can accelerate growth for both for myself and, but of course, for the companies that I work for as well. And that's why when Neil shared this idea with me, even though I didn't have security experience, I was able to see some patterns from what I've done in previous industries and identify fairly quickly how that experience could help me accelerate things in security as well.

There is obviously a knowledge gap, which I'm fairly confident in my ability to scale that up, especially with the support of someone like Neil, who's super experienced in the industry. Then leveraging those patterns, especially the work that I did at Typeform where I built a couple hundred integrations and technical partnerships around that. Some very relevant work. Now just redirecting to the security industry.

So that, yeah, that's maybe in a nutshell what I think is something that I can bring to the table in the family. Yeah. Switching industries every quarter to five years, that's very often. And you must be able to identify the underlying patterns that connect everything together, the reputable golden nuggets.

Yeah, that's right. That's what I strive to do. And it's actually something I really enjoy doing as well. We briefly touched on the pain points.

Lean is set up to address what is your thinking and what is your approach to connect the solution that you've built with the market. As we know, building a product that is a vitamin is not the best path for many different reasons. Building a painkiller for a very explicit pain point seems to work. So what is your thinking and what is your approach?

Yeah, I love that analogy. And that's one that we refer to very often within our team as well. And we had very direct experience with this. The previous idea that we were working on outside of security was actually in the customer success space was definitely a vitamin.

And the market told us that in many different ways. And when we switched focus to this idea, which, by the way, we still weren't 100% convinced had a big enough market to pursue. And we didn't know if this was a repeatable enough problem. So we went through the classic discovery journey.

And it was night and day difference in terms of the response that we got to this idea. The excitement that people showed, the level of commitment that they were willing to put in a team. At that point in time, all we had was a concept, right? We didn't even have a prototype.

We were literally pitching to people with a one-pager, telling them what our idea was. And they were super excited about it. And that, of course, made us very excited to pursue this. Taking a slight step back, I think what we learned in that discovery journey, we talked to about 100 folks in the industry ranging all the way, very senior people like CITOs and heads of security engineering.

But we also talked to founders of other security product companies. We talked to folks running MSSPs with different segments within the security industry. And we learned that it's a fairly universal problem. And we decided to segment the market.

And the segment that we just need to start with are other security product vendors. But we also see that this problem that we're solving, which is that of tools for all and really massive amounts of data engineering that goes into making sense of data that's coming out of so many different disparate systems that don't necessarily always play nice with each other, also applies to security teams operating at scale. Where if you look at estimates, the range is anywhere between 50 all the way up to 100 security tools that these really large enterprise security teams are using. So that's how we view the market.

But of course, as a small team, you have to make a conscious decision as to where to start. And we decided to start with the vendor signal for a few different reasons. One, of course, they're smaller companies, less bureaucracy, much faster selling to. And also the pain point was very clear.

And the way they articulated the pain point to us from doing those interviews, particularly with product people and CTOs and so on within these companies was, I know integration is really important to my business. I need this data on behalf of my customers from a dozen or more tools. But it takes my team way too long to build these integrations. And also, I don't think it's something that my engineering team should be spending time on.

If there's a better solution, I would rather use that. So that was how they articulated it to us. And that's why we decided to go after this segment in particular to begin with. Like you mentioned, there are many different security tools.

There is a security solution for your corporate security. There is a solution for your infrastructure security. Companies already feed a lot of metrics and application logs into a centralized log aggregator. Often, and you probably hear it from the market, they use Splunk or other mesh provider.

And that's how companies build their response. They build custom queries on top of the Splunk. And then the decision is made or an alert is triggered. And then the security team goes into this mode of handling the event.

Do you see that as the friction point when you talk to these companies that have already integrated Splunk into the SIEM pipeline? Yeah. So I think the question you're asking is very relevant to the enterprise segment. If we were to start selling the security team.

By the way, we don't have live customers in that segment yet. For context, we're about a one and a half year old company. We have 20 customers, all of whom are other security product vendors. But we have started to have these conversations with security teams.

And what we've learned is that we're not going to play with SIEMs, right? I want to be very clear about that. We definitely think SIEMs have a very important role to play within the security stack for auditing purposes, for investigation purposes. Fundamentally, the type of data that we're ingesting over these APIs from dozens of different security tools is different than what you would typically send to a SIEM.

And the easiest way to think about it is SIEMs are very focused on events and logs, whereas we are much more focused on the stateful data. Now, that's a pretty, I think for most people in security, a pretty clear delineation. What we mean by stateful data is the findings, the process findings coming out of these tools. So the alerts, the detections, the vulnerabilities, the issues, whatever the tool calls it.

We also extract the entities that these findings are about. Is this vulnerability related to a cloud asset or is it a network asset? Is it an identity? So on and so forth.

And we also pull some configuration data out of it. Now, this can serve a variety of different use cases that I think is fundamentally different than what a SIEM can do. I think SIEMs are great tech ops, right, hunting investigative tools, whereas, but that's only one part of a typical security team, right? That's one segment.

You have corporate security, you have cloud security, you have AppSec. They have very different requirements and they often care much more about the stateful data than they do about such granular logs and so on. And so the specific use cases, just to be clear, that we've learned about as we have been talking to these CISOs and heads of security engineering is one, understanding the trends across your security products. Because if you think about how these teams operate today, they might have a dozen or more tools in their stack.

They have to log into these different dashboards, even to understand what's happening within those environments, to pair that data with other teams within their org that are actually responsible for fixing the issues. Just reporting, right, as that might sound, it's a really important use case that has come up multiple times in our conversations. The other is around compliance. There are, of course, VRC tools out there and many of them are customers as well.

They don't serve every single use case within these companies. So what we've learned is that many of these teams have to stand up what you can refer to as compliance data lakes, right, where they have to keep pulling the same type of data and they have to create some type of repo. And they have to share this with other teams within their organization, including with auditors. And then there's others where they create the use cases around creating many applications that connect different tools within your environment.

Like, for example, many teams that we'll talk to create a lot of bespoke workflows on top of Slack or Microsoft Teams to triage and automate certain workflows. This is all bespoke code that these teams have to own. And these are some of the use cases that we've identified so far that we can help with, essentially being this littleware layer that connects different tools together, normalizes the data from them, correlates it as much as possible, and then allows these teams to act on the data in a meaningful way. That's really interesting.

Really sounds like a great aggregation and, like, normalization set of services that fills an important gap in the market. I'm really curious, is there ever been a moment that you would count as maybe the proudest moment that you've had as an entrepreneur on your journey so far? Tough question. I think this is, it's such a rollercoaster, this whole founder life that, at least I, I think our whole founding team, doing myself, of course, we try not to get too happy about the highs and too low about the lows.

But I think there have been a few moments that we consider to be pretty pivotal in this journey so far, especially given the context of what we went through as a team before pivoting to this idea. Right. We, those three months we spent on the previous customer success idea, we talked to about a hundred VCs and we got a hundred no's, talked to a bunch of customers. And we, while they thought it was a very interesting idea, we didn't commit any budget or work with us in any meaningful way.

So it was just rejection after rejection. And then when we said no, they said no without saying no. Exactly right. Oh, this is super interesting, but, and the variation of what came after that, but.

Oh, look at the time we have to go. Yeah, exactly. That was painful. It was a pain, very painful experience to go through to deal with that rejection.

And then when we pivoted this idea, like I said, it was very different response that we got to the point where I like telling this story. It's a very interesting anecdote in our journey where we set up a bunch of discovery calls, right? We reached out cold to people on LinkedIn. We had some folks in our network that were in security too.

We spoke to them. We joined some Slack communities that are very security focused and started reaching out to people there. We joined them and we were, we did this with the intention of setting up a bunch of discovery calls with as diverse a set of folks within security as possible. And one of these calls that we had, we thought it was going to be just a regular discovery call.

So we went through the whole spiel, told them a little bit about what we were building, asked a few discovery questions. And at the end of the call, this person we were speaking to said, okay, so I'm in. And we're like, okay, what do you mean by that? You guys are having money, right?

I'm going to, I can wire it to you tomorrow and this will be the amount I'm willing to commit. And we didn't ask, but that wasn't, that wasn't the ask at all. We weren't even sure we were ready to raise money yet. We're like, yeah, sure.

Okay. We'll take, yeah. And sure enough, the next day. Here's the safety.

Okay. And she wired the money the next day and then things just snowballed from there. So that I would say was one of those pivotal moments where we knew we were onto something and we just have been building on that momentum ever since. Congratulations.

And that's very special to have that happen. Sometimes you're raising money and you don't even know it. Exactly. It shows up.

It's still, you're still, it's still a very young company. So maybe this hasn't crossed your plate yet, but what's the hardest thing that you've ever had to do on your entrepreneurial journey? Yeah, there've been several hard decisions that we've had to make already. Few that I can think of are pretty early on in the journey.

When we started to raise money, we knew we would have to raise some institutional money and we had a target in mind. We raised a three-seat round last, in October, 2020. And we talked to a bunch of folks and we spoke to some amazing VCs, but there was only so much room in the round and especially for a small round, you can only have so many people putting in bigger checks. So we had to turn down one amazing VC in particular.

So that was the first probably hard decision that we had to make. We weren't sure how that was going to play out. In retrospect, I think it's played out pretty well because the reason we picked our lead investor, 11T Capital, is because they had a very strong network in security. And that decision has paid dividends since then.

So that was one thing that we weren't sure. Turning down a really reputable VC as a team that had nothing at the time, how would this play out? And then along the journey, we've had to let a couple of folks in our team go, which especially being, it's never easy, but I would say especially when you're a small team, you're so close to everyone. If things don't work out, it's really hard as a founder to, one, come to that realization.

And then of course, share that news with the affected person in part ways. I don't think that ever gets easier, but those have been a couple of the moments that stand out for me. Yeah, those are always tough moments. Building a business requires very strict focus on delivering to market.

It's not everyone's cup of tea. And I know that there have been in many points in my life where it wouldn't have been a good fit to be a founder or to be part of a startup. You learn and you grow. And here we are.

In terms of our own personal growth, oftentimes there's very influential people that have a big impact on our lives. And I'm curious for you, if you could think of maybe one person that had the largest impact on your life or your career, maybe why that person had such a large impact. Yeah, I would say that there have been so many influences, but I would say the largest one has probably been very close to Paul. It's actually my dad who very early on, we come from very modest roots in India.

And he broke out of sort of his corporate job and took a risk and became an entrepreneur, had a successful exit. And that was really fascinating to me, especially the context of where India was as a country in the 90s, where it was almost like an oligarchy, right? It wasn't the very successful capitalist model that you now know India to be. It was a very closed economy.

So the concept of entrepreneurship, especially in the way that Silicon Valley recognizes it, didn't really exist. So watching him do that and essentially create something very valuable out of nothing, it kind of blew my mind as a kid, right? I didn't understand the concept. And the more I learned about it, the more I saw him work towards his goals, the more I was fascinated by it very early on.

And I just knew that that was the path that I wanted to pursue as well. And I think every decision I've made since coming to that realization has led me to the point in time that I'm in the place I'm at now. So yeah, I think undoubtedly that's probably been my greatest influence. And before we started recording this show, Kabir, I think you mentioned one of your co-founders hosts a podcast and you reach out and connect with the audience in India.

I imagine that this is one of the ways you can give back to the community by inviting that community on a platform that will allow the exposure to the wide audience. Yeah, definitely. I do want to credit Akaash, my co-founder, completely for that. That is his own initiative.

It actually has very little to do with Lean. He was doing this even before we started the company. But definitely there are some crossover, right? As we met more folks in security that also comes from an Indian background, he invited those people onto the podcast to help build their personal brand.

So it's a given thing that we've learned being on this journey, especially because we are such a young company is that we recognize how much people have given to us. We had nothing a year and a half ago. We started from zero. We asked for a lot of favors to get in touch with investors, to get in touch with customers, to get in touch with our first set of employees.

And sure enough, we want to make sure that we give back to the community in as many ways as possible. A passion podcast. One way that we do that, we also try to host events for the community. We actually have one coming up here in San Francisco later this month where we've invited a bunch of prominent folks in security to be on a panel.

And they're going to be talking about, these are CISOs and people like that, that are going to be talking about what it takes to break into selling to these large enterprises. So getting in, we call it inside the buyer's mind. So we do things like this as well, not to promote lean, but just to give back to the community and help disseminate this very important knowledge. This is a very good question.

What does it take to sell into the enterprise? I don't know if I'm the best person equipped to answer this question because we're still breaking into that segment. But I think to me, this has been a common theme across these different industries and roles that I've held at various startups. I think everything starts with a really solid product, right?

You have to be solving a problem that matters. I think from a naive perspective, a lot of people place the value on relationships and so on. And I think that's important, by the way, having a playbook in mind to sell to these enterprises, navigating that journey because it is a very complex sales journey where you have multiple interested parties. You have to identify a champion.

And I won't go into too much detail there. I think these things are very well documented. None of that matters unless you're solving a truly important problem for these teams. So I would say to other folks that are thinking about this and are starting to break into the enterprises that pay very close attention to your product, do a lot of these discovery calls, show them prototypes, and don't feed these as sales calls initially, right?

Until you're sure that you're solving a problem that matters, just ask for favors. And what we've learned in our journey is that most of these people, even in fairly large companies, CISOs and these folks that you would think have very little time, usually very open to talking to people that are doing innovative things. And maybe you're not solving the right problem initially, but by having dozens of these calls, you'll probably refine your solution. Only once you feel like you're getting the right type of responses, people are excited about your solution, could you actually move to this phase of actually selling into these organizations.

Teams are struggling with complexity that is introduced historically for many different reasons. The security space is heavily polluted by different dashboards. Often you have to have a four-year university degree in order to understand how to use certain products. And the user experience is extremely important.

If we can solve a very obvious pain point by producing a better user experience or user interface, that in itself can be a good product and could be a good starting point. Thank you for sharing. I would love to go back to that little community connection piece. Like this is the security podcast of Silicon Valley.

We're all connected to this community in some capacity. And if our listeners would be interested to maybe follow maybe future events or are they open to the public and are you, do you post them on like Loom or maybe meet up or how do you stir up and connect with the local community? Yeah, absolutely. They all open to the public.

And the more these events work, the more folks that attend them, the more of them will do. We see ourselves as being this company that plays nice with everyone in security. It's a role that we have to play because as I've mentioned a couple of times, we see ourselves as this middleware layer for security. We want to co-host events with other companies in the space, whether they're vendors or the private security teams.

In this case, we are co-hosting with Silicon Valley Bank and they have a beautiful center on Market Street in San Francisco. And it's a great event space. And it's the second time that we're going to be hosting an event there. So we leverage their community as well when we promote this.

The best place to find out about our events is actually to follow our LinkedIn page. We post every event there. We usually host them on Looma so folks can sign up. We appeal to you as long as you work in security, basically.

And like I said, the more people respond to this, the more events we'll do. Also around the large sort of marquee events in security, like RFA and Black Hat, we're going to be doing more things for the community around those big events too. Awesome. Well, maybe we'll bump into each other there or we'll swing by your next event.

So we try to keep an eye on that. And I'm very familiar with that Silicon Valley Bank and you on Market Street in San Francisco. It's a beautiful setup. Be sure to visit that bank vault that's downstairs.

It's a cool piece of history. And as you build out the company, I know that part of being a founder is having that long-term vision. If you would like to fast forward into the future and I'll let you decide how far into the future we'd like to travel here together. But what do you see as success for the company?

I'll talk first about the trend that we want to align to. That we, as an entrepreneur, you're always making bets, right? And I think the long-term bet that we're making for this industry is that we think it's going to become security teams overall are going to become far more engineering driven. So if you look back on the history of security and its origins, it has a very sort of IT compliance makeup, right?

These teams have had that kind of makeup for quite a long time. And now we've gotten to the point where, as we've been discussing, the complexity is only growing in terms of the threats that these teams are dealing with, the number of tools that the average enterprise has to secure, the number of employees working at these companies. So overall, the entropy in this space is just increasing. And along with that, the amount of data that's being produced by these tools is increasing.

Breaking this down into first principles, our hypothesis on this is that you don't solve big data problems without applying engineering principles to them. And we've started to see, I think it's still nascent, but we've started to see the trend increase where security teams are hiring more and more folks with at least some basic engineering capabilities. Maybe they can write basic scripts. The more advanced security teams, they're actually, they only hire software developers.

And the reason we think this is happening is because it's not good enough to just rely on GUI-based interfaces. And so make these hacky approaches to joining this data and making sense of your environment. You have to actually build bespoke tools for your very complex environments. You can't just rely on what the points in your teams are doing for you.

And our bet is that over the five, 10-year period, this trend is only going to accelerate. And these teams are going to need some type of middleware layer, some type of dev tool suite like software developers have, but very focused on the security stack. So to us, success would be to be the dev tool's lead of choice for security teams, let's say five years from now. Yeah.

I mean, data is so important and it's becoming even more and more important, especially with all of this AI stuff, like creeping it in every crevice and every workspace. And I heard someone, I went to an event once and I heard someone ask a speaker who is an AI expert, this person, like, when do you think AI will replace the developer? And the speaker looked at the audience and said something along the lines of, well, I think that's kind of like asking what our power tool is going to replace construction workers.

And I felt like that was just that perfect little soundbite of, yeah, things are changing and they're changing so quickly, but there's always such an important role for the human component. And understanding, like, when you click a button, like, what is happening underneath the hood. And as you point out, like, understanding, like, what's happening underneath the hood when it comes to all of this data is an advanced problem.

And being an engineer, you're trained to think about the logic underneath the system and the complexities and simplify, like, huge systems down to simple concepts that we can help navigate or make business decisions, essentially, to what's going on in these vast and complex environments. And I think you bring up an important point related to AI as well. So we've been talking a lot about how humans can consume this data and activate it and deal with it more programmatically. But AI, of course, is going to be a very important part of this whole equation.

And with AI, it's all down to the data that you feed these models, right? If the data is not formatted correctly, if it's not normalized, if it's all over the place coming from all these different tools, it's going to be garbage in, garbage out. The insights that you expect this AI to produce for you aren't going to be super valuable unless you feed it consistent data.

And that's where we think a solution like ours also has an important day to play where if we can normalize the data, we can correlate it, we can deduplicate it, then the output that your average team can get, whether it's security insights or building a reporting layer using AI, using actual compliance purposes, will the output should be in theory much better. Well, we traveled into the future a little bit. Maybe let's travel into the past if you want. So if you had an opportunity to meet your younger self, would you?

And would you have any advice for yourself? So I, as I've mentioned, we love to give back to the community. We like to help budding entrepreneurs. I mentor a couple of young entrepreneurs myself.

And yeah, I think I would like to meet my younger self because I have always had this spark and this desire to build something my own. If anything, looking back, I maybe waited a little too long to venture out and do my own thing. So maybe that would be the piece of advice is that don't, it's quite intimidating when you're a first-time founder and you look at all of these great successes. And you see how these amazing founders have raised tons of money and they've had these what seem like overnight successes, but you don't really see what's gone underneath it.

And now having gone through the journey, I realized that it's just about taking that first leap, right? And the great attribute that I think most founders need to have is just tenacity and the belief in yourself that you will figure things out. So I, yeah, looking back at my experience and what I've done. I probably put too much emphasis on trying to collect the right set of experiences before having that confidence to take that leap of faith when I maybe could have done it earlier.

I mean, I think though the caveat there is like everything that has happened made you who you are today and the struggles that you face and how you've conquered them has put together like a very fine, very successful, very good person here today. Even though we would go back and give ourselves maybe some advice, maybe there's that catch 22 of we're always learning, we're always growing, we're always hungry. I think you share that drive, passion, the fuel for all of that. Thank you.

Yeah, that's, that's completely right. There's, it's a gray area. There's no easy way to say when you should take this leap of faith. And I think, you know, I've worked actually for very young founders, 18 and 19 year olds who've been CEOs.

And I think that takes a special type of personality to be able to do that. But of course you make a lot of mistakes when you're that young because you haven't been in the workforce for that long. So there's a benefit to doing it that way. And there's a benefit to doing it maybe the way that I've done and folks that are even older, right?

There's so many successful entrepreneurs who didn't start their first company until their forties or fifties. And maybe the chances of success are higher when you do that because you've just seen so much more. We all make mistakes regardless the age. It's just the matter of when do you start learning from mistakes?

And acknowledging them. I think that's most important. It's impossible to build everything. There are so many different aspects and subdomains of cybersecurity and compliance.

They do intersect. At the moment, they are fairly fragmented. If you were to start a company today, where would you explore? We have a lot of listeners that might be inspired by what we are about to discuss.

Yeah, so this is a very fortunate position that we find ourselves in having this great horizontal view of the industry, right? We work with so many different types of companies. We've spoken to over 100 founders easily just in the last year. Some that are starting GRC companies.

Some that are starting availability prioritization companies. Identities, security solutions. So many different spaces. So I think from our purview, cloud security, there's still a lot of aspects of it that are unsolved, even though you have behemoths like Wiz in the space.

It's a very intimidating thing to try to start a company in a space where Wiz operates. And I've heard this from a lot of folks operating there. But I think there are a lot of unsolved problems there. I'm not an expert at it, so I can't go into the details of that.

But we have met quite a few folks that are trying to tackle more nuanced problems within that space than maybe a more comprehensive solution. But I would say that when Apple started in a garage, the IBM already existed and they owned a lot of real estate in the Silicon Valley. That's right. That is correct.

Yeah, absolutely. So yeah, maybe it shouldn't be an intimidating thing. But I think just based on looking at attack vectors, there's so many different ways that enterprises can get hacked and these security events can occur. But if you look at the primary attack vectors, a lot of them are still happening at a very basic level.

Pitching emails, credentials, being exposed. So I think identity security is also a very important area where we have personally seen a lot of budding entrepreneurs look at that space and try to explore. Problems there. And then I would say probably a third area that's still very interesting, even though there are a lot of companies operating there, is compliance.

Because it's never going to go away. The number of frameworks that companies have to do is only going to continue to increase. There are a lot of these automated GRC companies out there that have built excellent products around making compliance easier to understand and process for your average company. But there are still gaps.

I would say particularly within really large enterprises where we found that a lot of the security teams actually have to build some type of bespoke solution because the point solutions are not always able to deal with their customer requirements. Yeah. So maybe there's something there. To the lack of data or lack of integration.

In order to build a fully immersive compliance or GRC platform, ideally it needs to be driven by the data itself. So I saw maps to a very specific technical details. But if you are not capable of pulling and understanding the data of the technical implementation, it's pretty hard to make the GRC platform fully automated. It certainly can elevate some of the day-to-day friction points, but maybe not make it fully automated.

What's the next big thing for Lean and the team? Yeah. So we've touched on this a little bit. I think we're right at the beginning of 2025.

It's the end of the year or the beginning of the year. It's typically a time for anyone to reflect, definitely for founders as well. So we've been thinking about the big rocks that we want to tackle in 2025. And one of the biggest things that we're going to be focused on is creating value for these enterprise security teams, right?

We have moderate success as an early stage company within the security vendor segment. They need to scale their innovations. We're still continuing to have conversations with dozens of other founders and CEOs in that space. But we know this problem exists for these enterprise security teams operating at scale as well.

A lot of our focus now is on understanding what is a specific problem? What is that wedge use case that we can help them with? And from there, we can expand into being more of a platform that these teams can use to build bespoke security tools to connect their points and issues, to build better reporting, to build better compliance workflows, spec ops, automations. There are a variety of use cases we can go into, but as any platform needs to do, initially, you have to find that wedge use case.

So a lot of our energy is being dedicated to that at the moment. That's an excellent approach. Just connecting the dots, making sure whenever we build a product, it's important to keep the focus on what the market is asking for and creating a solution for it. At the end of the day, it's that simple.

It's not a rocket science. Kabir, it's been an amazing show. Thank you so much for joining the podcast. We look forward to all of the developments with Lean and with the team.

We wish you great success. Thank you so much. It's been a blast. Thanks for having me.

And thank you to all of our listeners for tuning in to another episode of the security podcast of Silicon Valley. Join today with our special guest, Kabir, CEO and co-founder of Lean. It's great to have you, Kabir. Amazing.

Amazing. Thank you. All right. All right.