Building a security startup as an outsider

Good afternoon everyone. I'm Kabir. I'm the CEO and co-founder of Lean. And I have to be honest with you. I'm probably the least qualified person in this room to start a cyber security startup. Or at least I used to be. In fact, I didn't know much about cyber security at all until two years ago. I'd never pentested anything, read any security white papers. knew anything about gardener categories. Yet here I am two years later in one of the most skeptical, jargonheavy technical industries in the world and luckily thriving. That's what I want to talk about today. How did my co-founders and I get here? And more importantly, why did it work? This is a story of building lean as

outsiders. And spoiler alert, not knowing everything turned out to be our biggest advantage. Oops. Let me rewind a little bit. I'm originally from Mumbai, India. I moved to the US in 2005 uh for college and like a lot of people probably in this room, I've been in startups ever since. I spent time in gaming at two adtech startups. I was most recently at a company called Typeform in the Martekch space. I've uh I've worn all sorts of different hats at startups. I've led business development teams, customer success, product partnerships, but here's the thing. I had zero background in security. None. Not a single day. So when people ask me, how did you decide to start a security

startup? I answer we didn't. We sort of stumbled into it. As for what what lean is, we're building a unified API for security data, what we do is we build and maintain integrations with major solutions in the space. We normalize that data into common data schemas because there isn't a common schema that's well adopted in the industry and we offer that to our customers over our unified API so it's easier to uh correlate and action that data. We primarily sell to other security vendors like some of the names you see on the slides like Dr, Security Scorecard, Cydig and about 20 others. And now we're starting to sell directly to enterprise security teams as well.

Before lean, we were building something completely different. We're building an AI co-pilot for the customer success space. This was a few months after chat GPT had just come out and we were so confident this was going to be the next big thing. Why? Because we had either led customer success teams, invested in customer success companies or worked really closely with those teams. We knew the pain points, we knew the workflows and we thought we had product market fit before we ever wrote a single line of code. But then we started pitching investors and pretty much every conversation went like this. This market is too crowded. Isn't this just a wrapper around Chad GPT? Well, that was sort of fair

criticism, but the customers liked it. Sort of. They loved the idea. We'd get on calls and they'd say things like, "Oh, this is amazing. I can see how this will save me so much time. I can see how this will take care of a lot of the menial tasks that I have to do." But when it came time to actually pay and start to discuss budgets, it suddenly became a nice to have rather than a mustave. And pricing, we tried a little bit of everything. Per seat, too expensive. Per task, no one quite understood it. Per um flat rate, didn't really scale. So, we spent about 3 months spinning our wheels trying every iteration of this

idea that we possibly could. And the nose kept getting more frequent and louder. And finally, after 146 rejections, yes, that's the number. We kept count. We had to admit defeat and we had to pivot. Aris dying as a company. Now, pivots aren't a bad thing. We're all familiar with the great companies on this slide and and the pivots that they went through. Netflix started as a DVD rental service. Slack was a gaming company. I actually had the chance to test that game when I was in the gaming industry. YouTube was a video dating site. Now, in retrospect, you look at these success stories and they seem amazing. But when you're in the middle of a pivot, it's

very painful. You question everything. The market, your insights, your ideas, mostly yourself. Are you really cut out for startups? Pivoting definitely wasn't the plan. The plan was the startup dream. Raise some money, hire engineers, find product market fit, make millions in revenue, raise some more money, and eventually exit. But 99% of companies never follow that path, that happy path. Most startups try to survive for long enough to figure out what actually works. So, we pivoted and honestly, it saved us as a company. But here's the thing. We weren't security experts. So, we built this company in a very non-traditional way. Two out of the three of us come from backgrounds that are about as far from

security as you can imagine. My co-founder, Akash, helped incubate India's first food delivery startup and then he moved to the US to invest first in private equity and then as a VC. I already talked a little bit about my background. And I was literally working in Martekch before starting this company. We were the definition of outsiders. So what did we do? We decided to start a a security company. Of course, what the hell? What could go wrong? But it wasn't all random. I don't want to make it seem like we stumbled head first into this industry without a meaningful insight. What is now lean came from an insight from our third co-founder Neil who does

have some security expertise. He spent a few years before starting this company at a fairly large MDR called BlueVoyant that some of you may be familiar with. He was responsible for building their data automation and orchestration platform. BlueVoyant was operating at pretty significant scale. They had about a thousand government and enterprise customers and they had to build security automations for them across a variety of different security tools. They had done all of this on top of a sore which they ripped out for various reasons and they put Neil in charge of the project of essentially building their own internal data and automation platform. It was during this journey that he started to feel the frustration of dealing with all

of these different security APIs, normalizing data, dealing with data pipelines. And his key insight was that security tools are built for the buyers and for non-technical personas, not for the engineers and the developers who have to deal with the output and the maintenance of these tools. He said, "Most teams assume that more tools equals more coverage, but in reality, more tools equals more overhead. Data gets stuck in silos. There's no single source of truth. Security engineers end up acting as data janitors and critical issues slip through the cracks as a result of it. Neither Akash nor I could fully empathize with this problem because we didn't come from the industry, but it seemed really interesting and it seemed

like a problem worth solving. Neil was kind of hesitant though. Having been in security, he saw the industry as being conservative. Sales cycles take forever. People ask for innovation, but then they end up buying the incumbent anyway. But we thought it was worth pursuing because from the outset, our team like gnarly, boring problems, the kind that other people don't want to solve. So we said, okay, let's at least validate it. We'll talk to 50 practitioners. We'll understand if there's something there. If there is, we build it. If there isn't, we'll continue ideulating. So, how did we go about validation? Most people who start a company have a pre-built network of folks they can reach out to um and ask for their

opinion. We didn't have that. Akash and I, as you know, didn't come from the industry. Neil is an engineer, so he didn't have a very deep network of security buyers. So, we did something different. We started cold messaging strangers on LinkedIn. We reached out to about 250 of them. We reached out to CISOs, to VPs of security, to security architects, security engineers, founders of other security companies, product managers at other security companies, people who we really had no business talking to. We ended up talking to 91 practitioners in under three weeks. After validating the idea and getting some conviction that we were on the right path, we joined as many security slack groups as we could find and we

politely reached out to some of the practitioners in these groups and continued that feedback cycle and started asking for these folks's perspective on the solution that we had in mind. Turns out people in security really like talking about their problems, especially when the people reaching out are pretty earnest and and genuinely trying to solve those problems. Amazingly, one of these conversations that was meant to be a discovery conversation ended up resulting in our first check, our first angel check. We we weren't expecting it at all. Multiple other checks followed in the next 7 to 10 days. And suddenly we had some money to solve this really annoying problem for the industry. Then we flew to Black Hat Vegas in 2023.

Uh we did that trip by the way between the three of us on less than $800. Happy to share tips on how we did that later if anyone's interested. Um and we started pitching as many practitioners and VCs as we could at happy hours hosted by other people. It was awkward. It was exhausting, but it worked. By the end of 45 days, we had 91 meetings in under three weeks. We had a quarter of mill million dollars in angel commitments from security practitioners who believed in the idea. And we had over 41 signal rich practitioner conversations that gave us a very clear idea of what we had to build next. We didn't have the credentials, but we

had curiosity and that opened doors for us. And then we became students. We had to learn in the job. Akash and I listened to podcasts like risky business and read newsletters like venture and security. We read every security publication, LinkedIn post, white paper from credible folks in the industry that we could find. We combed through Reddit threads, got no reports, um all sorts of things. We weren't trying to become security expert experts overnight. Not that that's possible to do. What we were trying to do was learn the language. And slowly we started to understand that security is an industry that's not just driven by technical proficiency. It's highly trust based. It's about proving you understand

the problem before people will listen to to your solution. So we kept learning and we still do every week. From an outsers's perspective, we noticed a few things about security. One, security is sold, not bought. Like gym memberships, it's something that people aren't super excited by. You have to prove to them that it's important. Two, everyone's building for the buyer, not necessarily for the user. CISOs signed the check, so vendors focus on making their products as beautiful and demos as they possibly can, but the security engineer who actually has to maintain the tool, they're usually an afterthought. and using the tool is actually pretty painful for them. Three, marketing is usually focused on fear, not clarity. Everyone's either

saying the same thing or not saying much at all. And sorry, and four, um, this is probably familiar to a lot of people in this room. There are endless Gartner categories and people vendors creating their own acronyms all the time. We realized there's a communication problem in security and we certainly didn't want to add to it. Luckily, that came naturally to us because we didn't know anything about gardener categories anyway. So, instead of asking which quadrant do we fit in, we asked what problem can we solve for real people? And it turns out that was the right question to ask. So we made it part of our mission to not only unify security data but to make it

as intuitive as possible. We saw websites and copy plastered on boots at events that said things like security data fabric with MLdriven correlation and zero trust architecture and all sorts of other jargon. We understood in principle what these vendors were trying to say but we didn't really understand what problem they were solving. So we decided to solve or to to say similar things but in plain English. In the early days we could have called ourselves a security data fabric which sounds impressive but instead we described ourselves as Zapier for security or we compared ourselves to plaid or segment for security and that was intuitive to a lot of the people that we were talking to. Our benchmark

was if our non-security friends don't understand it, we should rewrite it. This isn't dumbing things down. It's making security accessible to everyone who needs it. And this philosophy, this outsers mindset shaped what we continue to build after. So during this time as we were thinking about building the company, we consciously decided against building for a long time and then going to market and selling to enterprises. It seemed too risky for us as a team. We didn't come from enterprise security backgrounds anyway. It's what most security startups do. They they focus on enterprise customers because that's where the money is and it's understandable. But that playbook wasn't going to work for us. We wanted quicker iteration

cycles and to give ourselves the ability to generate a meaningful amount of revenue as quickly as possible. We had spoken to enterprise practitioners during our discovery process and we knew that there was a version of our product that we could build for them at their scale. However, it would mean at least 12 months of development, another 6 to 12 months of procurement cycles and legal reviews and multiple stakeholder meetings and ultimately a lack of momentum. Instead, we decided to lean into our startup backgrounds and play to our strengths. During our discovery process, we had realized that there was an integration pain point for security vendors in the market. Building and maintaining integrations with the rest of the ecosystem was time

inensive. It took money and and above all it distracted their product and engineering teams from building core features in their platforms. Most security vendors tend to be startups or scaleups anyway. So it was a segment that fit us as a team really well. We were able to sell directly to sea levels and founders which compressed decision timelines to a couple of weeks and we were able to quickly iterate and start building a real business. We chose speed to market as our core metric during this phase. So how did we execute on this opportunity that was in front of us? We continued to do things that felt natural to us but may not follow security best

practices. We adopted the principle of radical transparency. We openly shared our architecture diagrams with anyone who asked. We made our API documentation public. We even sent out a build-in public newsletter, which we still send out to this day. To allow people to follow along with our build journey. Most security companies guard everything closely. We did everything the opposite way. And you know what? It built trust. It built credibility. And it created a community around us that we could lean on for support when we needed introductions to VCs or to engineers or to to customers. We also experimented with pricing a lot. I I'm not ashamed to admit that we initially copied pricing from similar companies uh operating in different

spaces. We um we we we uh started with standardized tiers, then we added custom pricing, then we went back to standardized steers. We've we've gone through a few iterations there. Today, our pricing uh ranges from standardized tiers to having custom tiers for bigger customers. Our finance team hates us, but it works because we meet customers where they are. We also built our team pretty unconventionally. Akash and I are originally from India, so you would think we'd have a pretty rich talent pool of folks that we could reach out to, but the product we're building, as you can probably tell, is fairly technical. So, we primarily needed engineers to work with us. Problem is, neither Akash nor I had a

very deep pool of engineers that we could tap into. So, we relied on outbound recruiting. We were open about our mission and what we thought this company could become. We expanded our network through content and we hired engineers through the same build and public approach that we also adopted on the product side. The result of that is that today our team is twothirds from outside of security, but they're deeply technical and very well suited to build a product like lean. They bring fresh perspectives and ask the dumb questions that often expose things that insiders miss. So, we've talked about product pricing, hiring, but how do you sell a product when you don't have the credentials that

buyers expect? How do you build authority? In our case, we decided to do it by learning in public. In a world that's increasingly being dominated by AI slop, I'd like to think that our messaging and content came through as being authentic. We shared what we learned on LinkedIn. We hosted conversations with security leaders and published those on YouTube and and on our blog. We built flagship initiatives like inside security, which we still continue to this day, where we feature security practitioners and their stories on our blog. and beyond the noise where we interviewed 25 senior security executives and asked them about the problems unsolved problems in security. We didn't push, we pulled. We didn't chase logos, we chase learning.

Our GTM strategy was listen better than anyone else and share what you've learned out in the open. That built more trust than any outbound campaign ever could have. People are familiar with faking it until you make it. Maybe there was a little bit of that at the very beginning, but I'd like to think that we earned it. We learned it until we earned it. So, if you're a founder or or someone who wants to be a founder thinking about entering security, here's our cheat sheet. Don't fear your ignorance. Weaponize it. Your fresh eyes see what experts miss. Start with people, not products. Talk to at least 50 people that you want to solve a problem for before writing a

single line of code. Understand their world as well as you possibly can. Learn faster than you sell. Prioritize learning velocity and execute in ways that feel natural to you, even if they don't follow best practices. Get comfortable saying, "I don't know. Can you teach me?" When we stopped pretending to know everything, people invited us into deeper conversations. And to the security leaders here, your next great collaborator might not come from this industry. They might come from gaming, retail, or even fintech. So instead of gatekeeping, invite curiosity. The best teams we've worked with translate problems, not jargon. They focus on outcomes, not acronyms. That's how innovation happens at the intersection of expertise and naivity. So if you take one thing from this talk,

let it be this. Curiosity scales better than credentials. And sometimes not being qualified is your biggest advantage. We've learned so much from this community from newsletters, podcasts, white papers, Reddit threads, events like this one. We still learn every week because the truth is being an outsider never ends. It just becomes your edge. Thank you. [applause]

[applause] >> Happy to take questions if there are any. Normalization process. Obviously systems that are not as intuitive data perspective. You said that you may open the schema up to the industry standardization. I remember looking at XML files from management software. [snorts] datage for like standards standards in the security community. >> That's definitely what we're attempting to do there. There have been attempts at this. So there's OCSF which I think is one of those standards that has the most sort of community backing. Uh but it's only meant for certain types of security. So I think it works for logs and events and pushing things into a sim, but there's a whole host of stateful security data that doesn't

necessarily belong in USCSF standard. So because there isn't really a community initiative around it, we're hoping to be a company that can at least standardize some of it, right? We're never going to be able to standardize 100% of security data because there's always going to be things that are very specific to vendors. But even if we get 80 90% of the way there to I'm sorry to cover.

So, uh, so yeah, just curious if like when you got started, did you strategy for development? Yeah. Yeah, we did. We did. I think design partners whether you're an outsider or not because obviously you want to validate what you're doing in real time with people. So um yeah luckily I mean because of the things that I shared people were willing to make a usually understood the problem we had a general ideally

of course.

>> Do you think arguably you got more value out of going to black hat and not versus going into the happy hour and talking to the >> 100%. We still don't do booths at any shows. >> Isn't that interesting? >> It's really interesting and it's the way I've personally done conferences in my in earlier parts of my career as well. I [snorts] think one requires you to do a lot of business development up front. The other is more on the followup side. If you have booth, people will come to you and then you got to follow up with them. the other way around. If you figure out who's going and you set up a bunch of meetings in advance, then the

goal is, okay, I I want 20 meetings over three or four days. You can do that without getting so yeah, that's how we do video shows. Thank you. [applause]