 Hi, good afternoon everyone. Thank you so much for taking the time to listen to Guy's wisdom It's an absolute privilege for me to hear it as well Guy founded Sneak a business that was originally the idea was to look for and look and fix Open source vulnerabilities in codebase. He founded in 2015. It's an amazing business. It's grown to over 1,200 people. It's it broke through a hundred million ARR just over a year ago So it's been through many journeys many manifestations guys going to take us on that journey But one of the things we look for when we're working with great founders is what is the founder market fit? Why is this human being? uniquely sort of place to solve this problem and I think Guy and Sneak is an example of that So before we kick off with Sneak's journey, can you just let us know maybe guy like what's the you know What did you do prior to sneak Thanks Tom and thanks everybody for taking the time here. Hopefully there's some useful tidbits here for you to take on So my background I'm born raised in Israel been through the cyber parts of the Israeli army and then found myself as a software developer within The application security space when it was very nascent building the first kind of automated Penetration testers. So this is an Israeli company acquired by a Canadian company acquired by IBM And I moved over and became product manager basically spent a decade in the kind of the creation of the app sex space And we were trying to get developers to embrace like even back in 2002 I was saying shift left on on app sec trying to get developers to To use the products earlier because it's a hundred times cheaper to find a problem early versus versus late in the cycle But we didn't quite succeed with that We sort of got developers to get succeeded financially by sort of selling to security people but not Didn't get developer adoption and then I left and I founded a Web performance company that made websites faster in the DevOps scene And I was a part of the DevOps wave that company got acquired by Akamai where I was CTO for a bunch of years So I sort of spent the next six or so years of my life in the sort of the DevOps space And so and I moved with them to London. So really the two journeys combined a bit in sneak You know trying to bring what I've learned from DevOps into kind of what I've tried and failed To do in there in app sec and and you'd also spent a time actually kind of evangelizing about the space You'd built a bit of a profile and it might be that that also kind of helped you bootstrap the early versions of sneak So maybe we'll jump into that in a moment, but what's the founding story of sneak? What was that sort of moment? Was there an epiphany or was it just all of these things coming together? Yeah, I think a lot of it is very much the combination of my journeys and so I guess from the sort of this stretch of time in DevOps, I've kind of come to appreciate that This need to shift left or sort of run security earlier has gone from a from a nice to have to a need to have The world has split up teams are you know, like we rely on these fast-moving independent teams that build software and Security hasn't gotten the memo hasn't really been adapted to it And so we have to do it we can't fix we can't secure a software from the outside more than ever before And so that was needed and then the DevOps playbook Was the inspiration was to say hey now we have like fine We have this need but also there's a whole horde of great companies that are building amazing tools that Get to developers and so can we build a security company that is modeled after these great developer companies? And and actually succeed and break through in that sort of holy grail of getting developers to embrace security So that's the epiphany like the idea literally came to me in the shower, but the the sort of the path to it was Was really these learnings over the over the different times make sense But I mean that is a big problem that you wanted to solve at the point So you have to make it tractable and you sort of had an early idea of what the minimum viable Solution to test this might be I think you've got your own description for that. Yeah, I think so so the core Notion was we want to get developers to embrace security and that's very hard And we're gonna model after the dev tooling companies of the world in fact We define ourselves as sneak is a developer tooling company the tackle security not a security company So we very much designed everything about the company the conversations We had around the color schemes to sort of make it, you know warm and welcoming like dev tools But when I tell you you have you know a high severity vulnerability I want to I want to scare you just a little bit, you know Like you do need to worry about not fixing that problem and so doing those the logo, you know conversations You know like the guard dog by an animal logo and sort of so a lot of that We built a whole company to be like a developer Tooling company that's designed on that and then modeling after dev tools We we really focused, you know, I guess the best practice We've seen was taking a specific niche or a specific ecosystem and really really focusing on that You see New Relic and Heroku they were built in in Ruby land and they stayed there for years So for us it was no to JS and we said no JS is Is the Ruby of that time, you know, it was big enough and small enough sort of small enough Sort of big enough to matter, you know enough enterprise adoption enough general use But small enough that we can be a force within it. And so we really focused on that and And kind of built build the tools and then subsequently developer security is also massive and so as you mentioned before we picked a specific Space which is open source security basically finding the timely opportunity of you know developers being afraid of dependencies, you know everybody has some horror story about using some library or changing or upgrading and it broke something and so Helping tackle that problem, which was especially kind of finicky and well-known in the npm space in the node JS space And so we focused on that we went very deep. I find myself kind of hustling and you know every meetup of node JS meetup that knows me that that would accept me. I had some reputation from the performance days So I was kind of using those Where I could You know sleeping on air mattresses that friends, you know sort of doing these, you know 3% event there and you know 17% event there Trying to build it and we succeeded like the first phase of it was very much around being being a real Presence that if you're in node JS you would have known about sneak love that and So sort of phase one was very much founder driven sales Staying close to the customer and it wasn't we often talk about a kind of product market fit It sounds much more like a product developer fit at this stage or product user fit. Yeah. Yeah, correct and I think So so a core part so we built this bottom-up motion for in security Which generally is a very top-down motion that we're going to talk about that a lot more The bottom-up really means that you focus on the user and we're saying the whole lens the whole reason for existence for sneak is You know developer first securities if you all if I am a developer and I want to secure the code that I'm building What do I need? Where do I want to find my tools? What's the company? I want to be associated with but then in the product that you ask, you know What is it that I that I need and so we built the whole product from sort of that ethos We built it I believe in iteration and so we we shipped a crappy little product, you know Just a couple of months into the company's existence. We said it's beta We didn't charge anybody for it, you know, and we iterated with the community and we built it up you know as I was going to all these different meet-ups and And what we found was you know, we had a command line interface And we had you know as I've been referring to this this minimum unit of value like our smallest unit of value that we Could provide was help a developer write their code like write secure code And the smallest version of that was a command line interface that they could download and run locally And it was premium because if you know, it's such an easy action such a low friction action But if you introduce the credit card into that you'd lose a lot of people and so We built that you know, we built the CLI and we got good adoption pretty much right away And then that grew and people would download the CLI would and use it They'd run the test they find vulnerabilities They'd tweet positive things about it and they wouldn't put it in the build They wouldn't continue using it and so we We we you know we dug into it and we talked to them and all that and eventually we realized we haven't made it easy enough yet to actually get into the Continuous relationship the continuous security motion and Are our that drove this whole evolution and significant tech innovations that we've had to do But they came from a product lens to integrate into github But really and what we've done in github is you do a next-next-next experience and we figure it out and we connected and we install You know github all off app at the time, you know install it and they just Automatically now integrates into your workflow around collaborating around code editing Love that and the beauty of that what's important to kind of maybe generalize here is that it made the relationship continuous So now we did this next next next. We still had the CLI people could still use The even lower friction kind of installation, but then the people that installed it through github We have this ongoing relationship with them and we can evolve it And it opened up one more path for the long answer here They'd open up one more path around virality And so what also happened with github sneak has always been free for open source so open source developers could use it when they Used it on their command line interface. It was hidden Nobody saw it when the when an open source developer open source maintainer installed sneak as a github app on their Open source repository Suddenly it was very visible to all of those that consume that open source project We would find the vulnerability and one of our claims to fame was we actually fix the problem because the developers job isn't to find problems It's to fix them so we would find a problem We will package up this fixed pull request this set of code changes needed to fix it and we'll open this pull request onto the Repository and then everybody watching all the open source kind of maintainers watching that repository because they're using it They would get an alert and so that really created some virality and it raised awareness not just to the notion Not just the sneak but also to the very concept that this is a security problem We should work about and that worry about and that this is a type of solution you could get I love it So a few few observations just to sort of synthesize that I think are useful for all of us including me as I look at Kind of investment opportunities. The first is guy had a kind of maniacal focus on the right user So in this case a kind of product developer focus we talked about that He was contrarian in the way. He did it because he certainly wasn't out there selling to security Buyers like most others instead. He started with the early adopters I think one of the other things that inspired me in what you described is just remembering that actually Initial adoption is not the same as engagement and engagement is often about taking the friction out of using the product so at this point you had Pretty fantastic kind of you know developer Adoption, I think we started talking together in 2017 and you suddenly hit an inflection point when we were at the point we were investing you went from sort of sue 600,000 ARR up to 2 million ARR in two quarters from memory It suddenly just was an inflection point. What was it that drove that? Yeah, so I think as we built this up We you know, we got this good success with the developer usage and nobody would buy and It's a common pitfall for sort of dev tools And so over time as we've sort of explored that and we learned that we realized that while we built the sort of the Product market fit for the user. We haven't been satisfying the needs of the buyer Which is the security person some of that was features a bunch of different gaps But probably the most interesting is Observation is back to that unit of value So for a developer, you know, they like depth, you know I'm coding in JavaScript and I couldn't care less if you support PHP or not not because I'm never minded But rather because I'm it doesn't affect me. I'm coding in JavaScript for a security person. They need Brett They're gonna tackle this security risk and they can't have every director of engineering Kind of tackle that security risk in their own different ways And so they need Brett they need support for many ecosystems and elements And so their minimum unit of value was much broader and so really fundamentally We we kind of cracked the code on developer usage But then until we've expanded that to multiple platforms, which is a dev tool Typically you care about a lot less, but as a security tool is fundamental We couldn't really get to that But once we cracked that and we did it then then the momentum of the developer Adoption and that sort of tailwind really kind of pushed us up. I love that So sort of depth for the initial adoption you then need breath to get a kind of product buyer fit in this case Do you as you look back? I think this is also the point that you started to think about bringing in sales teams and that profile changed a lot If you'd thrown which a lot of founders do a lot of sales people at this problem at phase one that we just described You probably wouldn't have been able to iterate. So how did you think about building a sales team to actually drive? Yeah, so so if first of all, it's worth noting that we did introduce at the end of that beta when we g8 Self-serve, you know pay this thinking the floodgates will open and the developers will now They've been using the product and now they will happily pay for it and they didn't And we realized that the budget for what we were offering that Organizations budget for keeping itself secure sits with a security person and so we still get a lot of purchases from developers but the majority of the budget comes from from security and So within the security industry the traditional sale is a top-down enterprise sale But within the dev tooling world, you know continuing that motion. It's a much more transactional Path and so the key decision was really I spoke to a lot of different sort of heads of sales Interaction and by the way before that we we hired two salespeople To try and sort of help sell the product without really a big plan and two salespeople is important because if they if you hire One and they don't succeed. You don't know if it's a salesperson or if it's your product. That's problematic So we hired two and two months later We separated from one and and sort of stayed with the other and that was a really good call And then once we knew that you know the decision was really, you know Talked to a bunch of different VP sales some coming more with the enterprise motion that are used to sort of large deals longer engagements, you know sort of top-down and then the other with someone who came more from a transactional background from a dev tools and that really helped our fight that for us We wanted the continuation of it the muscle we wanted to strengthen in the company was the dev tool motion and so we built we prioritized That motion and we hired someone who was really really good at this transactional fast velocity sales And over time as the company grew and our enterprise motion grew We did need the head of sales to be someone that comes from enterprise and make that part to be a division And so that's what we did We sort of got a top similarly at the beginning We then brought another head of sales because this one was a bit more America's biased and the next one was sort of more Global and so each of them was amazing and the right person for the fit We got pretty lucky there But but you have to think about what is the right center of gravity you want to have and again It's an example of you just can't skip to the end here. You have to go progressively through these stages Yeah, you as you kind of thought through the opportunity Back then you brought in some sales, maybe you were creating a hell of a lot of developer demand I mean, I don't know if you can recall the numbers But it was huge Adoption amongst the developers and the first thing that the sales people coming in would think is these are leads I remember getting the business slightly wrong back then thinking, you know All of these github IDs would be genius because you'd be able to point them to specific businesses You'd be able to then sell to that business. It didn't work out like that. I learned from that just observing you So help us understand how you use the sort of freemium Community it wasn't just as easy as picking them off and pointing them at sort of leads How did you think about that and what did you learn? Yeah for sure So we you know we did the first of all, you know We we connect on github and a lot of people use their personal emails on on github And so I'd say about half the users probably even to today get their gmail So it's oftentimes kind of hard to classify them if you use these enrichment tools to know where they come from And you know what we did was we took those users and we try to score them So we called we took everything we knew we started from saying everything we know about this user Okay, like how engaged are they did they invite other people? We did go through the enrichment process Do we sort of know them and we try to get a bunch of these tidbits and give them some score And if they passed a certain threshold they became a product qualified lead a pql And that showed up on some salespersons kind of Q and they decided if to put them on to like an automated sort of email sequence Or if they want to reach out and we work that way and that helped us that fed us for a while One evolution that happened over there was that we learned to flip it around so it's you know This was useful But it was was a bit of a messy signal and we've learned that the better way to do it was actually to start from the Sales process so we defined a user profile and it said when you're trying to assess a sales opportunity What questions do you want to ask and then we looked at the data and we said? How best can we answer that and the key thing for me that was a learning was Not being afraid to ask so for instance because a lot of these users were sort of gmail users But the fact that someone used the gmail user didn't mean that they were assessing the product for personal use versus not At some point we introduced a question to say hey Are you here for your personal projects or you're here for sort of a business to assess a sale and we'll help you We tuned the sort of the downstream Workflow a little bit to sort of make it realistic And and that was a really light-shed moment for us because first of all People didn't run away. I was very afraid of them like you know hitting the funnel and all that was very minuscule And there was a skip option And the second is that suddenly our analytics were very different and we saw very different patterns of behavior And we could optimize the personal users for advocacy and spread the word and such and the business users for conversion And it was very significant and this is an extraordinarily exciting bit of the business because you've kind of taken a vertical approach to appeal to the developers You've gone broad in order to actually be kind of minimum viable for the buyer the security buyer And you've created a sort of product like lead growth engine here So a lot of businesses don't invest that time to create the sort of loop Instead they'll take a linear approach where they say actually we throw more sales people at the problem We have more outbound lead generation, but you created this kind of engine in the business that could really scale Yeah, for sure and I think and that evolved itself into like from the PQLs at the beginning They were always combined with like some form of outbound founded like that first and then with sales Because like when we get in through a developer and they want that depth Sometimes the journey between that developer and the security person that might be sort of signing the check in most larger companies It's just harder to do internally. So the PQL lets you do that internally or maybe it's the security person using it But oftentimes, you know, we'd go outside and engage and our brand and our broad reputation would help and at some point We introduced this notion of product qualified accounts of PQA's in which we track Accounts that have active users in them whether they're using it on company code or on their personal code And then we'd use that in the outbound and today that plays a big role And and so the combination this sort of pincer movement is important because sometimes it's easier to bridge that gap that way And I think today about 70% of the deals that we that we land Have sneak users inside the company That that have been active and so it's sort of it's a big motion that presence Even when we do outbound that sort of bottom-up presence is very significant to to the success And we saw something similar even with our investment in slack this sort of you have such a soft landing When you already have product option inside the organization now look back in 2018 you were signing up these Customers and it was something between six thousand dollars or sixty thousand dollars a cv It's now potentially multi millions on many cases. So there's been a huge expansion Is this kind of does this reflect the third phase maybe where you started to think about customer success Expansion enterprise sales. Yeah, what does this latest phase look like? Absolutely I think it's it's actually the the evolution of both aspects of the company on one hand You know we've gone from From the sort of the single developer or development team That's the minimum unit for the user for the dev user to kind of a single business unit Which was the minimum unit within Security to to secure a business unit and then you know grew to multiple business units and across And we have a lot of these examples in which we won over through outbound or through inbound You know some company and then another another like some business unit another business unit And then we go to the mothership and we go broader Especially by the way Leaning into modern companies that have been acquired by a larger company those have oftentimes been a good lead in So that's kind of win month path and one growth path that's been very significant for us Is that developer account we charge by developers on the other side? We started with opens for security as the product But you know the vision has always been developer security and so over over the years we've added You know the container security and infrastructure as code security and code security and and cloud security now Now we have five products And the expansion is very significant and we're tracking like the growing percentage of customers with two products with three products And so generally that was another growth element to us which is Tackle more threats and I think that's super super important One thing I love about it is the sort of the authenticity of it people expand with you because you are a good solution for them You're a good company for you to work in and so all of the investments in customer success in truly valuable product They pan out they want to do more with you and people reach out to us But also it's important to assess your market opportunity and understand Is the right thing for you to double down for us We believe that the true eventual solution is to help developers write secure code And we don't want to sort of say help developers write you know use open source libraries securely We want to sort of talk about something broader. So there's big opportunity over there I love that one one thing we haven't really touched on through the course of this is just you know Partner ecosystem you touched on github. You went there because that's where your initial user was You took the friction out of for them How do you think about partnerships whether it be channel strategy or anything else? Yeah, I think um, so so it's it's really interesting and as you grow also It's super super important, you know, because you want to get leverage You can't just grow by throwing more bodies at it and the product is viral, but you still you want leverage Channel channel has never been terribly exciting for us. It's a little bit more tricky in uh, like straight up redistribution You know, there's some of that but it's sort of less the focus because it's less It's also in general. It's a little problematic in sass. It's sort of but What has been very insignificant for us is alliances And the difference there is that these are actually When you stop and you think about the problem not from the lens of your product But from the lens of the customer Then sometimes I'm you understand that the customer prefers to consume your product through some broader lens maybe Maybe the customer is outsourcing all of their security kind of practice around product security to some Some other vendor and so unless you really want to displace that you need to fit into how that other vendor provides it Maybe a developer expects to get there So we partner with gsi companies and security mssp companies to do that, you know on on the on the other side Maybe a developer, you know, really you oftentimes they want security capabilities to be built into the tool that they're using If they're using at asian bit bucket or if they're using, you know docker to sort of install containers Snake is built into those and those alliances come in and so those are very important It's important to understand that these are slow burners and you don't control the timeline So you need to have a lot of balls in the air. You don't really know when would they materialize And a lot of them are going to drop to the ground But they're worth investing and I'd also recommend Separating the backlogs. It's very hard. You have some pie in the sky a vision of some massive company embedding your product It may or may not happen But it's very hard to weigh that against some very real functionality You have to kind of build to close a deal And the reality is in that reality that I can set situation the customer needs would almost always win And so what I would what we eventually did and and really work for us is to just separate the backlog Resource isolates, how much do you want to invest within the business side? And then have kind of battle and prioritize between different options there But sort of carve that out of the customer backlog and that really worked well for us and continues to be I love that one of the things that just to sort of re reiterate Something you said I like your framing around alliances because they're actually partnerships that are symbiotic And I think a lot of businesses will build a dependency on a third party Who don't get the synergy in the same way as they do you've done a phenomenal job of two things It's finding alliances where they benefit from the same and they're not in competition And then secondly equally kind of as importantly they're going to celebrate that we have the last minute and a half together final couple of questions for you The business is kind of profoundly different from day one when you first envisaged it What's actually changed the most? What surprised you the most? Yeah, I mean, I think I think I was a bit of a puritan around the relationship between product led growth and and sales Like I think I I kind of saw them as a bit more binary And I think in practice there are a lot more symbiotic and there are a lot of cases even in the case of slack You know in which if you if you really want to think about sales as an assistant as an assistant As something that sort of helps a customer figure out. What is it that they need? Or sometimes helps a champion navigate the organization and close it out And so from an efficiency perspective Like you always want to basically adapt what you are providing to how the customer or the user wants to consume this And If you're a techie if you're sort of a developer and you like your sort of you know your products You know to be sort of just installed and self-serve then you have to provide that for them But if you're engaged with others for a lot of people it is actually quite complimentary There's been like a million learnings say in the context of what we talked about right now That's been a key one. Yeah, incredibly important one. Look, thank you so much for the time I've genuinely learned a lot as always. I hope everyone that joined us this afternoon has so please thank you join me and thank guy Thanks again. Thanks, Tom