How Snyk built a product-led growth juggernaut | Ben Williams (VP of Product at Snyk)

[00:00] Being able to identify the various micro and macro loops, how they're all connected, being able to document them in a qualitative model to communicate a shared understanding of how you grow. It's really powerful. Augmenting that then with. [00:15] the quantitative side of things that helps guide quarter to quarter focus. [00:20] and ensure you can be intentional about where you're investing, that becomes a big enabler. [00:24] You know, you're never going to have. [00:26] a shortage of ideas in a high performing growth team. So knowing where to focus amidst that kind of sea of ideas is a really important role of the strategy. [00:40] Welcome to Lenny's podcast. I'm Lenny and my goal here is to help you get better at the craft of building and growing products. I interview world class product leaders and growth experts to learn from their hard-won experiences, building and scaling today's most successful companies. Today, my guest is Ben Williams. [00:56] Ben is a VP of product at Sneak, [00:58] which is likely one of the biggest and most interesting companies that you've never heard of. Sneak makes it easy for developers to catch security issues in their code, and there's a lot to learn from how Sneak got started. It started through product-led growth, evolved into product-led sales, was very community-driven, and was also laser-focused on developers, which has become one of the most lucrative markets to go after. In our conversation, we cover how the founders of Sneak got their first 100 users, what they got wrong when they tried to monetize early on, [01:28] people, how they structured and grew their growth and product teams, what they figured out about what should go into freemium and what shouldn't, and so much more. As you'll soon hear, Ben is British, and so the episode is automatically going to sound more sophisticated, and I can't wait for you to hear it. With that, I bring you Ben Williams.

[01:47] This episode is brought to you by Coda. Coda is an all-in-one doc that combines the best of documents, spreadsheets, and apps in one place. I actually use Coda every single day. It's my home base for organizing my newsletter writing. It's where I plan my content calendar, capture my research, and write the first drafts of each and every post. It's also where I curate my private knowledge repository for paid newsletter subscribers. And it's also how I manage the workflow for this very podcast. [02:17] from being a tool that makes teams more productive to one that also helps bring the best practices across the tech industry to life with an incredibly rich collection of templates and guides in the Coda doc gallery, including resources for many guests on this podcast, including Shreyas, Gokul, and Shashir, the CEO of Coda. Some of the best teams out there like Pinterest, Spotify, Square, and Uber use Coda to run effectively and have published their templates for anyone to use. [02:47] If you're ping-ponging between lots of documents and spreadsheets, make your life better and start using Coda. You can take advantage of a special, limited-time offer just for startups. Head over to coda.io slash Lenny to sign up and get a $1,000 credit on your first statement. That's coda.io slash Lenny to sign up and get $1,000 in credit on your account.

[03:17] greens. I've been hearing about AG1 on basically every podcast that I listen to, like Tim Ferriss and Lex Friedman, and so I finally gave it a shot earlier this year, and it has quickly become a core part of my morning routine, especially on days that I need to go deep on writing or record a podcast like this. Here's three things that I love about AG1. One, with a small scoop that dissolves in water, you're absorbing 75 vitamins, minerals, probiotics, and adaptogens. I kind of like to think [03:47] safety net for my nutrition in case I've missed something in my diet. Two, they treat AG1 like a software product. Apparently they're on their 50-second iteration and they're constantly evolving it based on the latest science, research studies, and internal testing that they do. And three, it's just one easy thing that I can do every single day to take care of myself. Right now, it's time to reclaim your health and arm your immune system with convenient daily nutrition. It's just one scoop and a cup of [04:17] And that's it. There's no need for a million different pills and supplements to look out for your health. To make it easy, Athletic Greens is going to give you a free one-year supply of immune-supporting vitamin D and five free travel packs for your first purchase. All you have to do is visit athleticgreens.com slash Lenny. Again, that's athleticgreens.com slash Lenny to take ownership over your health and pick up the ultimate daily nutritional insurance.

[04:44] Ben, welcome to the podcast. [04:47] Thank you very much, Lenny. Thanks, first of all, for inviting me. It's a pleasure to finally meet you. I've got to say that kind of what you're creating with the newsletter and now the podcast, which is such awesome resources for the product growth and wider tech communities. So it's a real honor to be invited onto the show. And, you know, I hope there's a few useful things that people can take away. [05:06] Awesome, man. I really appreciate that. I have no doubt there will be many useful things people will be able to take away. I'm really excited to chat about Snyk and the things that you're building there. I feel like Snyk is this very under-talked-about company and also super... [05:20] fascinating company, especially in terms of how it got started, how it's scaled. And it's also at the center of so many [05:26] Trends, product-led growth, community-led growth, focusing on developers to grow, and also just security in general is really interesting. And so I'm really looking forward to our chat. [05:36] Me too. Before we get into all of that, I'd love to spend just a minute on your background. So you're currently VPR product at Snyk, and I'm curious how you got to that role and just some of the other wonderful things you've done in your career along the way there. [05:51] I'll try to keep it reasonably short. My education is in computer science. [05:55] Graduated from the University of Manchester back in the late 90s. I'd already landed as a job as a developer, but ended up having a bunch of other interesting offers. One of which was to join a small startup building requirements management tooling for product and engineering folks. This was all pre-agile, but that whole space of developer tooling, engineering tooling,

[06:16] It was something I just felt naturally drawn to, and it's where I've really specialized through my whole career. I actually joined that company as a solutions engineer, so lots of demos and so on. I was really close to the product team, but also speaking with customers every day, which [06:30] as is quite common, I think, was my path into products there. [06:33] Several years and a few acquisitions later, I find myself in IBM with the Rational Software Developer Tooling Group. I was leading parts of the product strategy there and a bunch of initiatives. I actually learned a ton of useful stuff there, but also that I had a strong preference for working in smaller, fast-growing orgs versus 350,000 people be a month's. [06:56] After an interesting unexpected interlude leading a DevOps transformation at a fintech and some consulting and advising, [07:02] I then joined CloudBees. They're a DevOps startup with an open core model. I was leading product design and growth there. I stayed with them for three years through several raises and a period of really fast growth, before finally joining Snyk to build out a growth organization. [07:18] and lead our developer experience initiatives. I have a broader remit at Sneak now than just the growth org, but yeah, that's how it started. Awesome. To give folks a sense of just how successful and big Sneak has gotten, one is just what does Sneak do? We haven't even talked about it. And then two... [07:35] Just some stats about the scale of the company and the business at this point. [07:40] the developer security company. We make it ridiculously easy for developers and their teams to improve their security posture while still moving fast. So Snyk can find and automatically fix vulnerabilities in code,

[07:52] open source dependencies, containers, infrastructure and cloud configurations, [07:57] and all underpinned by [07:59] the best security intelligence data in the market with a laser focus on developer experiences, which is [08:05] why we're really different. It's also an amazingly fast-growing business with some stellar PLG-focused investors and board members from the likes of Ed Sim at Boldstart to Tamar Yehoshua, Slack's CPO. We were founded in 2015. [08:21] Last valuation after our Series F was at 8.6 billion. [08:25] We're securing the software of millions of developers now. [08:28] well over 2,000 paying customers. [08:31] Now around 1,300 people, of which around 500 in R&D with nearly 70 folks in our product org. And the people here just create this amazing culture. And all in all, it's just a really exciting place to be. [08:44] Okay. Did you have any sense it would get to this scale when you joined early on? [08:49] Yes, I think, because I wasn't looking for a new role when I ended up joining Sneak when I was first approached by them. But everyone I spoke with along the interview process just became more and more impressed with not only the caliber of people here, but the vision, the mission for the company and all those things you mentioned in terms of PLG, community-led growth, focus on developers, the security space. [09:17] These were all kind of all things that if you create a Venn diagram of all the things that I'm really interested in professionally, super interesting, super exciting to me, then kind of sneak ended up in the middle of it. So it's pretty cool.

[09:29] Awesome. So that's a good segue to where I wanted to start is how Snyk started and how Snyk got their first 100 users. And I know you weren't there necessarily for that, but I'm curious what you can share about [09:40] how the founders found their first, say, 100 users. How did they get to their initial developers and get people excited? [09:46] I think it's a really fun story. So if you don't mind, I'll just take a moment because I think it's important to set the stage by looking back. [09:53] just look back at the market in general. So PLG or bottom up and security, [09:59] These were never words that were kind of known to have been spoken together in a single sentence, right? So security has always been a centralized function. Security programs were historically [10:10] more about audit and policing and enforcement, [10:13] versus developer enablement or empowerment. [10:16] The sales motion you saw, it was always top-down, it was seen as immovable. CISOs, other AppSec leaders were the buyers. Security tooling that was out there at the time, they all catered to this dynamic. And these were tools that slowed developers down. They created a lot of frustration, they were met with a lot of resistance, [10:34] Not the ideal recipe really for consistent adoption and strong engagement and retention. [10:40] And ultimately, app security programs based around those kind of solutions just weren't effective as they really needed to be. [10:46] So it was... [10:48] a realization around this, timed with adjacent market shifts happening with DevOps that spark the ideas behind Snyk. So, [10:56] The founders, Guy, Danny and Asaf, they saw a real opportunity just to do things differently.

[11:01] They believed that the most effective way to improve application security posture was a developer-first approach. [11:07] They knew that the developers were increasingly caring about the security of their code in the same way that they cared about performance and functional quality of their code. But they also knew that to empower developers to own that security, they needed just much better tools with way less friction than they ever had before. [11:25] And their approach was, I think, looking back super smart, focus on a community. It wasn't the full extent of what we'd think of as community-led growth now, but it was close. They started with a really narrow early focus. It was a single persona, single context, single use case. And what that meant for Snyk was developers building applications using Node.js, who wanted to ensure that the open source dependencies they were pulling into their apps were secure. [11:53] Now, open source software, it's a huge accelerant in building modern software. The average software application today is at least 75% of open source libraries and components. So this was increasingly becoming a primary attack vector for malicious actors. [12:10] who could find a single vulnerability in an open source component, [12:15] and then find it and exploit it in every single application that was using that component. [12:20] And at the same time, at least back then, open source software was much less tested for security vulnerabilities, and the maintainers of open source libraries were often less security aware. So you get that context, and then at the same time, Node.js as a runtime was gaining traction. So there was this increasing adoption in the enterprise, more and more dedicated conferences and the like, but the community was still small enough that Snyk could meaningfully influence.

[12:47] And Guy and the others just went all out on being deeply involved in that community. They were presenting at dev conferences, meetups, they were building online content and so on. [12:58] And the question that they repeatedly posed to the community was, "Do you have known vulnerabilities in your apps?" [13:05] And Sink was there to help them answer that question. [13:09] Fun kind of facts on the side, if you search for SNEAK in the Urban Dictionary, you'll see it's an acronym for So Now You Know. But all of this kind of... [13:18] I think really only worked because of the parallel product-led approach. So while the answer to the question about how does your product monetize users was much less clear cut in the early days for Snyk, the answer to the questions how does your product acquire and retain users has always been product-led. [13:36] And the initial version of Snyk, it was a command line tool. It was a tool for developers. It could be run locally or easily integrated into CI, CD pipelines for early feedback. [13:47] It allowed devs to assume more responsibility for the security of their apps. And that was just very different from the typical incumbent technologies that were run by security teams late in the dev process, long feedback loops, issues thrown over the walls, inevitably just frustrating developers. [14:06] And all of this was just built on this fundamental belief that the only viable path, and by viable, I really mean sustainably effective, the only sustainably effective path for software-centric organizations to meet the challenge of becoming and staying secure was for them to take this developer-led approach to that challenge. So really kind of complete disruption of the industry. And developer adoption for that reason was always a key priority for us.

[14:36] day one. And the early strategy was always about creating something valuable that was readily available, something that solved the real problem in a uniquely differentiated way, and making it pervasive. So with dev adoption, you know, this core concern, a freemium go-to-market strategy was just the obvious approach. So eventually getting back to your original question, that's all of the context and where they went and how they did it. But the first hundred or so users [15:06] community and the interest that drove. I think we probably had maybe around 5,000 free users before there were any attempts at monetization. [15:14] Awesome. There's a bunch I want to unpack there because what's interesting, the way you describe it maps to the series that I recently wrote about consumer growth strategy and how the first three steps after you have an idea is to come up with your super specific who. [15:28] kind of your target persona, come up with a hook that catches them, gets them excited, and then go find them where they are and pitch them your hook. So the super specific who for Sneak was, you said, open source developers working on Node.js. Is that right? Well, it was Node.js developers, and Node.js developers were building their applications using open source Node components. Got it. Was there any other constraint to that, do you know, [15:58] it. The community was growing for sure. [16:02] It was big enough to have a decent opportunity there, but narrow enough that technology-wise, it didn't mean... It meant that a product could be brought to market in a reasonable time. Yeah, that's great. And then the hook was basically, do you have known vulnerabilities in your code base? Which, if I were an engineer, like, I don't know. Shoot, I don't know. Get off my... I'm scared now. And then, so now you know, right? Yeah, exactly. Okay, cool. And then the where. So you said that they went to open source communities. Do you have any more

[16:29] specifics about what those were. Was it like a specific forum? Was it like GitHub somewhere? Was it Reddit? Do you have any idea where those communities lived? [16:37] Yeah, it was less about a particular place, but more about the community of people. [16:43] developers themselves who focused on on node.js so you know a bunch of kind of early evangelism was really at conferences it was i think the velocity conference in amsterdam where guy and azaf kind of first unveiled sneak to the world and uh kind of yeah it went from there i see interesting so it was in-person events conferences and meetups probably focused on node.js developers yeah okay awesome what happened after that so that was like the first hundred was just roughly the [17:13] for a long time. What was the next stage, roughly? Yeah. [17:16] I think that focus was the really important kind of element there, if I can kind of latch on that. Starting with that narrow focus and building around community engagement, I think it's a well-proven playbook now, particularly in the developer tooling space. Like New Relic did it notably with Ruby Community, for example. But ultimately... [17:39] It was important. [17:40] because of this kind of depth versus breadth approach and that depth [17:45] The first approach that Snyk took was important to be able to effectively validate the solution on the path to product market fit. A JavaScript developer just won't care if you support Golang or Rust, but will absolutely care if a key feature like automated package upgrades just isn't available for their ecosystem. Of course, the bigger problem of vulnerable components in open source across all languages and all ecosystems, that's a very widespread problem. It affects the industry at large.

[18:15] opportunity that was there to be unlocked. But the key for Sneak, I think, was just not to go too wide too early. So, [18:22] They focused on nailing that initial use case for that specific community of Node.js devs, like I say, narrow enough to be able to [18:32] really focus on quickly building a compelling solution to a real problem, but also wide enough to be something viable from a growth perspective. And even back then, the NPM, the Node Package Manager, hosted around 200,000 open source packages. They were downloaded something like two and a half billion times a month by over two million devs. And the typical Node app would have hundreds of dependencies, mostly indirect and so hidden, less immediately visible. But each of those [19:02] Nailing that narrow and deep use case before expanding wider was absolutely critical and generally just sound advice around finding product market fit and building solid momentum before expanding. [19:13] casting a wider net and [19:14] It's difficult to maintain that focus for sure as the lure of that bigger TAM can be really tempting, but ultimately you have to build a service and market well to capture it. Do you have a sense of when that focus expanded to an adjacent group? Like how many years into the growth story that happened or was there some kind of milestone there? Because I know everyone imagines, yeah, we'll expand. [19:39] The question is when and when does it make sense and when is it too early? Do you have any insights into that phase? [19:44] Yeah, for sure. First, I think if we're talking about PLG, the story with Sneak, and I actually like that definition of PLG.

[19:53] product-led acquisition from Julian Shapiro when you spoke with him. And beyond that maniacal focus on finding product market fit for your product, founders really should be thinking about how their product is going to grow. And that's important, of course, as you think about taking that next step. So [20:10] Let's assume in a simplistic definition that you found product market fit as demonstrated by strong retention. And then the real question is, where are the new users for your product going to come from? And founders really should have, I think, strong hypothesis around this. You risk essentially adopting them. If we build it, they will come approach. So if your acquisition strategy is product led, then understanding and being intentional about your early acquisition growth loops, I think, is an essential founder's responsibility. [20:38] Dedicating time there to design those loops into the product is key. And when I say product, I really mean the whole product experience, considering every touchpoint in and out of the core application that your users and customers might have with you. Sneak, for example, believed very early that we could build out powerful content loops via fixed pull requests that we raise on GitHub. New users, they'll sign up for Sneak, they'll connect their GitHub accounts. [21:08] create sneak branded pull requests to fix those vulnerabilities. [21:11] Other devs in the repo will see and interact with those PRs, and some of them will follow links to Snyk, create accounts, and some of them will connect their own repos, and so the loop continues. It's a company-generated, company-distributed content loop.

[21:24] It's actually really powerful for us because it's both an acquisition loop and an engagement loop. Over the course of time, we extended that loop by adding support for other source control systems beyond GitHub. We layered on a bunch of new loops. And I think if founders can be intentional about this as you're developing early product iterations, then you're going to have a bigger advantage when the product clicks with the market. And that was built into Sneak as we went along. So that was kind of ready as we found. [21:53] product market fit but [21:55] I think to talk about specifically how Sneak took that next stage, it was kind of a function of when we were chatting before this, talked a little bit about some of the failed. [22:07] experiences spinning up a self-serve revenue channel. Actually, before we get there, which I definitely want to get into all that, I love this story you just shared. I hadn't heard of this growth. [22:17] tactic of basically they connect their GitHub account, you find all the vulnerabilities, push a fix, people see that Snyk did this for them and it just provides all its value. And you're saying that was really effective. It's an example, something that worked very well. First of all, that integration. [22:34] in terms of connecting your code with security scanning like that, was a first-of-a-kind integration. Like, no one had done that before. But the key was that we ultimately controlled the contents. And not only was the fixed pull request doing something useful in terms of the code, but all of the description of the pull request was explaining about the vulnerability educating users. And it was all sneak branded and saying, if you find this useful, click here, come and learn more about the vulnerability, sign up for an account if you don't have one.

[23:04] It kept existing users coming back and it brings new users, a lot of new users, in fact. You'd be in there all like, do you have known vulnerabilities in your code base? Click here to find out. So is that responsible for much of the early growth, that loop? [23:18] I think that was one of the loops. We also have a couple of... [23:24] from fairly early on as well, other content loops that are more kind of programmatic SEO assets that have both been pretty instrumental in terms of new user growth here. It'd be cool to hear about those if they're relatively straightforward to explain, and then we can get to the thing that didn't work, the self-serve monetization piece you were going to get to. [23:42] We have a bunch of loops, actually, at this point. Lucky you do. [23:45] Yeah, I'm a big loop pest, funnily enough. But yeah, we have a bunch of loops. [23:52] Company generated company distributed content loops have actually worked really well for us. We have a sidecar product called Sneak Advisor. Sneak Advisor is basically a service that developers use to search and find open source packages when they're considering integrating some within their software applications. The unique thing about it is it indexes all of the package managers. It learns about those packages. It augments them. [24:21] the data about them with a bunch of metadata, including, of course, sneak security scans. But we also find out how actively maintained the software is on the source repo on GitHub or wherever. And so we build this kind of package health score. So anyone searching on Google for a package that does XYZ or a specific package by name, sneak advisor will be right up there in terms of the search results. They'll land on there. They'll get a good idea about that package. They can look at

[24:51] website and we have CTAs to say, you know, if you want to [24:54] secure your application on a perpetual basis, then just come and join us. So that's a great loop. And that's all kind of a programmatic asset. So there are hundreds of thousands of these package pages, but they're just automatically being generated continuously. [25:09] Got it. So it's programmatically generated better indexing of open source libraries that you can integrate with. That is so smart. It's programmatic because you can... [25:19] inform on the security vulnerabilities and then the maintenance and activity. Interesting. Yeah, that makes sense. That's all data you could just gather. That's awesome. Okay, so there's that. Is there anything else that's worked really well for you guys to help you grow self-serve? One of the recent ones that's really interesting is security education. We think of Snyk as a change agent in helping DevSecOps transformations, and it's fine kind of having this capability, [25:49] understand and can be better placed to prevent security vulnerabilities being injected into their code. [25:56] And so one of the things that is, again, something that's pretty different from the industry from an incumbent perspective is that we believe it's really important to democratize security education. And so we have been building this bunch of really high quality, but bite sized lessons about developer security, focus on developers about security issues and vulnerabilities. And we surface them again. They're out there in the public domain. There's no paywall to get access to those.

[26:26] solutions you need to sign up, you need to pay to get access beyond more than a couple, but these were just, they're all out there in the public domain. So, [26:34] That works really well for us from a company-generated, company-distributed loop as well. So cool. So SEO and then integrating to GitHub in that interesting way. I imagine there's also a lot of intra-company virality when someone uses Sneak at a company and they spread it to their colleagues. Yeah, I mean, I didn't talk about those. I think those are pretty well understood. We have both referral loops and invite loops as well. Okay, awesome. Coming back to what didn't work, and I think you mentioned that there was a monetization attempt. [27:04] that was self-service oriented and that [27:05] had some challenges. Can you talk about that? [27:08] At the time, a few things were in place. Valuable product, check. Strong developer user growth, check. Strong retention, check. But the first self-serve monetization efforts... [27:20] only really saw traction with individual developers paying $100 a month. Or purchases in larger companies, they just didn't happen as everyone had hoped. [27:31] There was a really... [27:32] Critical part of Snyk's history. At the time, a bunch of investors didn't lean in, perhaps shying away from early conviction with the founders on building contracts. [27:41] strong usage without a proven path to monetization at that point. [27:45] Ed at Ballstar, who I mentioned previously, he was one of the first kind of true believers and was, I think, really key in helping with providing runway during that time. But it was clear that there was a lot of work still to do.

[27:56] The team dived in. [27:59] They really figured out what the constraints were and through that process really learned about the importance of catering for the broader governance needs of the enterprise buyer. [28:08] And that meant a couple of things. First, there was a need to build out table stakes features around governance at scale, just things that companies of a certain scale and size expected, reporting, robust user management, and so on. [28:22] And second, [28:24] that it was time to move beyond that depth-first approach, right? So that depth-first approach was absolutely critical in getting to that point, but it wasn't good enough to take the next step. If you think about it, there's a point in a company scale where you start to see diversification of tech stacks, and all of those tech stacks need securing. It's obvious in retrospect that, [28:45] only supporting developers using a narrow slice of those tech stacks, [28:49] wasn't going to meet the needs of the security teams who were ultimately [28:53] the people who are held accountable for the security of their entire application estate. So the teams worked hard over the next few months, starting to build support for additional languages and ecosystems, and adding those table stakes features. [29:06] I think back then, [29:08] Sneak were... [29:09] simply ahead of this inevitable curve of developer-first security. [29:15] At the time. [29:16] The only buyers were security teams, and DevFirst security, for the most part, wasn't something that CISOs and AppSec leaders were driving. [29:25] But if you look at Sneak through that lens of, as I mentioned, being a change agent, being a key piece of the transformational journey of our customers' DevSecOps journeys, you realize how important it was for us to start to build relationships with those security leaders. So it was that time also that it was the right time to build.

[29:46] bring in the first sales and engineering hires as well. [29:50] So you basically found it couldn't work, self-serve, independent of sales being involved in convincing the folks at the top, which makes sense. Like, how do you trust a company with your security if the people... [30:02] at the top responsible for security aren't bought in. Makes sense. Today, it's less like that. There are organizations where the buying center is still very much AppSec, but there are also many organizations where kind of technical leaders own the buying decision around security investments. What was always true, though, even back then, was the influencing power of developers, regardless [30:32] to convince people like, "Oh yeah, look at all these other logos using this. It's probably going to be A-OK." So just to understand, in your experience with Snyk, it never really worked self-serve monetization. It worked as a way to get into a company and then developers started using it in small scale. But... [30:48] You needed sales and marketing to really grow monetization. Is that what you found? I think back then, yes. Now it's a very different story. We have a lot of self-serve only customers scaling pretty large. [31:01] Got it. That's so interesting. I rarely hear that you start out with sales being important and then becomes less important. Or I imagine it's still very important, but there's like a segment that has emerged that can self-serve. Fascinating. Yeah, I think it is important to acknowledge that the product has always played a really key part in the sales process for sure. That touches on something I wanted to ask. So Ed Sims, you've mentioned him a couple of times. He's got this awesome newsletter. He talks about you guys all the time.

[31:31] the progress of Sneak. And he talks a lot about that for developers, you got to win hearts and minds of developers to build something that works. Any lessons or pieces of advice for folks that are targeting developers to win hearts and minds and get engineers, developers excited about what you're building? [31:49] I think there's two things, right? So... [31:52] First of all, fundamentally, [31:54] For someone to get excited about using [31:58] a product they've got a [31:59] care enough, right? They've got to have a problem that you're solving. So I think there's two things. One, there is a shift that is happening and still happening. I think there's still a long way to go. [32:10] for developers to really [32:12] care about security as an integral part of their job in the same way they think about functional quality or performance. You know, I think that we're still... [32:24] We're making strong progress there. It's changing all the time, but there's still a long way to go there. But the reality is that I think in most companies, [32:32] developers have to care about security because their companies need to be secure. So the key then is how do I make the job of being secure for these developers as painless as it absolutely needs to be? And that means really meeting them where they are, integrating with their tools, finding ways to take security to them instead of trying to [32:56] pull them out of their workflows. You know, flow is just this incredibly important concept for developers and you want to strive to keep them in that flow for as long as possible. So the GitHub kind of pull requests are a great example of that. Someone can sign up for Snyk and

[33:13] they could theoretically be the only user of Snyk and connect their repos. All of a sudden, with protecting, securing those repos, a hundred, a thousand developers could be working in GitHub with that code or benefiting from Snyk without necessarily needing to sign up. That's that example of kind of taking the product to users without pulling them out of their workflows, and I think that's absolutely critical. [33:43] It's a product that magically helps you avoid security issues. Very little work. Does a lot of the work for you. It's hard to imagine it not working looking at it now. And I'm curious what it was about the early days that just felt like maybe [33:58] that people didn't believe in this working? Is it just there was doubt that it would be smart enough? [34:03] to find your security vulnerability issues? Was it the timing wasn't right? People weren't ready? We're like concerned about security enough. What do you think it was that created challenges early on? Because looking back, it's like, of course, this is going to work. How could it not? It sounds just like a magical all win product. First of all, I don't think the challenges were there in terms of the developer adoption. So, [34:25] Even when those first kind of forays into self-serve were struggling in terms of breaking into some of the larger customers, the developer adoption, the free user base was still growing at a really good pace. That momentum was just constantly building and it's that momentum that has ultimately fueled the sales-led business as we've gone through the years.

[34:55] when those first sales and marketing hires did join us and we started having conversations and we also tweaked some of the things in the product to meet some, you know, add some breadth, add some additional languages, ecosystems, build in those table stakes features. Then it kind of really unlocked and [35:14] That was kind of rocket ship time from then. [35:16] Got it. So sounds like the biggest issue is monetization. Can we make money doing this? Developers love it. They're using it like crazy, but will people be convinced to scale this inside an organization and pay us a bunch of money for it? Exactly, yeah. Okay, got it. So I want to dive a little bit deeper into your growth team and product team and how you think about it. [35:33] organizing teams like that in a product-led growth sales org. So the first question just, how did the growth team start at Snyk? What was kind of the early days and then what does it look like today? [35:46] There were some ad hoc efforts happening in various places. We had a small growth marketing function, we had DevRel, [35:54] We also had some ownership of key growth surfaces in R&D. There was a team that owned the new user onboarding flows, for example. But it wasn't until I joined that we really formalized the notion of a growth team. It was very kind of ad hoc before then. When I joined, we created what we call the developer growth group now. [36:15] Before then, [36:16] There maybe wasn't a strong understanding about what a growth team needs to look like, how they might need to work differently to the core product teams. [36:23] And I'd say overall it was much later than you typically expect to see and at a bigger scale. You normally are going to start growth teams, one or two people, three or four maybe, and scale out from there. But we started much bigger than that. But at the same time, this bottom-up, developer-first approach, it was baked into the company DNA in terms of how teams think and operate. So...

[36:47] Yeah, we were growing fast even before we spun up the growth group. [36:50] I think the significant change that happened there was it was a transition from a simple freemium approach to a holistic and well-coordinated PLG strategy. It's much more common to start earlier. [37:03] much more common to start at a smaller scale that we did at SYNC. But it worked for us because of this kind of perfect storm of, [37:10] where we had a product with that bottom-up growth built in from the beginning. We had founders with a deep appreciation for how the product could grow. And there was strongly exec alignment and sponsorship for scaling the motion. [37:22] The problem when starting the growth group, it was really for the most part more oriented to how we can get the flywheel spinning faster as opposed to getting it moving in the first place. So where did you initially focus that team? Which part of the flywheel? Right now, we have... [37:38] dedicated teams focused on acquisition, activation, and monetization, along with a supporting team who own our growth platform, including all of our data and experimentation stack. But the macro structure, it's changed over time to enable us to focus on the biggest constraints in our growth model. So at the beginning... [37:56] We just focused on acquisition and activation, intentionally deferring any investment into specific monetization initiatives around the self-serve revenue channel until we felt confident that, A, we'd built the necessary growth muscles to scale. [38:11] and B, we'd figured out some of the more pressing issues that were present earlier in the user journey.

[38:17] So it was important that we felt really confident about our ability to effectively connect developers to Snyk's value in such a way that introducing and optimizing a self-serve revenue channel would make sense. I also really wanted to avoid one of the common failure modes I've seen around cross-functional collaboration and growth. [38:34] When I joined, there was an inherent tension built into the system. It was [38:39] particularly noticeable between R&D and the growth marketing team. We had amazing people in both teams, a ton of really great ideas, but many of them were just not being executed on. And it was leading to a lot of friction, a lot of frustration, ultimately caused by misaligned incentives between the different functions. So, [38:57] when creating the growth group. [38:59] We resolved this by ensuring that each of the growth teams were truly cross-functional in nature with [39:05] Everyone in each team aligned around common objectives and KPIs, [39:09] Every team has engineers, an engineering manager, a product manager, a designer, a growth marketer, decision science support, and a basic shape of the growth teams that will be familiar to most. But I spoke to a bunch of people over the last couple of years, and I've actually learned to my surprise that inclusion of growth marketers in the product teams is not all that common. And I personally think there's... [39:31] Just a lot of opportunity being missed there, and I expect that to start to become the norm rather than the exception over time. [39:38] Okay, I want to talk about that. But before we get there, you said there's a decision science person on the team. What is that about? That's cool. That's right. So it started off from a fundamental BI platform.

[39:48] data analyst perspective. But over time, we wanted to [39:54] apply a much deeper level of analysis on the data such that we could start to build in predictive models that could help us make better decisions and can ultimately be [40:06] fuel and power some of the in-product experiences. So yeah, we spun up a decision science function, and yeah, those folks are very smart. Is that similar to data science, or is that a separate? It's cool that you call them decision science people versus data science, because that's so much more actionable. Yeah, I think so. Wow, that's cool. All right, I hadn't heard that before. It makes me think of Annie Duke and all the [40:37] stuff about how to make better decisions. Is this something anyone else does or is this something you [40:42] came up with calling. I'm not sure. I don't necessarily think what we're doing is revolutionary there, but maybe the name, I'm not sure. Yeah, the name is cool. I haven't heard that before. It implies a bias towards action versus just we're going to do a bunch of cool stuff with data. Interesting. Okay, and then you said that there's [41:02] a growth marketer embedded on each team. So maybe just broadly, what makes up these teams, which you touched on briefly, and then what have you learned is the value of having a growth marketer embedded within each team? It's important to have balanced teams with strong diversity across multiple vectors.

[41:20] Focusing on functional diversity at the moment, which is kind of what you're asking about with having growth marketers on the team, one of the big benefits you get, [41:28] is a broader palette of ideas. [41:31] but also a bigger toolbox when it comes to execution, which generally translates in an ability in a growth team, [41:37] for them to test and learn faster with more parallel yet at the same time aligned threads. Perhaps I can give a recent example there. So having a growth marketer in an acquisition focused team led us to some lightweight experimentation on the website in [41:53] creating an SEO optimized page. It was something that was really high performing, both from the perspective of traffic and conversion, but it didn't require any engineering resources to create. So the growth marketer and the team, and they decided together this was something worth pursuing, but the growth marketer was able to kind of execute that independently while engineers were working on other things. But then based on the success of that, the team went on to build out a functional sidecar product that [42:18] allowed users to basically try sneak without needing to sign up by simply pasting their code in for us to scan and giving them some results there and then. That's cool. So, you know, we saw... [42:29] Really great results with that. Visitor traffic saw a significant increase. Sign-up rate dropped a little bit, as we'd expect it would, but overall new users had a big bump, and those users had much higher intent, which we saw play out with increased activation rates. [42:43] Awesome. Okay. And so there's essentially four teams under the growth umbrella. There's acquisition, activation, monetization, and then this kind of experimentation platform team. Is that right?

[42:53] Yeah, that's right. And that team is also responsible for making that data available elsewhere in the organization as well. Product-led sales is a [43:02] a really important motion. [43:04] for us and so [43:06] taking the knowledge we have, the insight we have around behavior with users and their teams and their companies within the product and making that available to the GTM teams outside in smart ways, allowing them to focus on the things that are most important to focus on. That's a really important part of what that team does. It's interesting. You guys are the epitome of product led sales. That's this new trend of from PLG to PLS for sales. It's obvious that they're a big [43:36] The fact that monetization happens almost all through sales [43:39] It's interesting. So that's interesting. Cool. Okay. That's not a question, just a thought. I'm talking out loud. One other... [43:45] Thought I had is, so you talked about SEO being a really important part of your growth. What is the person team like to do the SEO piece, the right content? I imagine they're on the acquisition team. There's maybe a content person that lives within that team. [44:01] We have actually one of the smartest... [44:05] SEO people I've ever met within our group. What's their name? Let's give them a shout out, if you want. Anna. Cool. Go Anna. Well, she's part of growth marketing, but she works extremely closely with the growth teams. And she's got a few people in her organization, and we bring them into specific SEO-focused initiatives when we're looking to build loops around that. Yeah. Incredibly important to have someone like that who understands that at a far deeper level than I could ever

[44:35] and particularly in terms of keeping on top of some of the things that Google are constantly doing in terms of their algorithm changes. And does she actually do the writing for editorially, for I guess even the programmatically pages or there's someone she... [44:49] But what she does do a great job of is providing the kind of continuously updated guidelines on how content should be structured to lead us to good results. And then it's just engineers and PMs that end up writing the things. Wow, cool. That's exactly right. [45:10] This episode is brought to you by Vanta, helping you streamline your security compliance to accelerate growth. [45:19] in the cloud, then you've likely been asked, or you're gonna be asked about your SOC [redacted address] to prove your company's taking proper security measures to protect customer data, and builds trust with customers and partners, especially those with serious security requirements. Also, if you wanna sell to the enterprise, [45:37] Proving security is essential. SOC 2 can either open the door for bigger and better deals, or it can put your business on hold. If you don't have a SOC 2, there's a good chance you won't even get a seat at the table. But getting a SOC 2 report can be a huge burden, especially for startups. It's time-consuming, tedious, and expensive. Enter Vanta. Over 3,000 fast-growing companies use Vanta to automate up to 90% of the work involved with SOC 2.

[46:07] it's in weeks instead of months, less than a third of the time that it usually takes. For a limited time, Lenny's podcast listeners get $1,000 off Vanta. Just go to vanta.com slash Lenny. That's V-A-N-T-A dot com slash Lenny to learn more and to claim your discount. Get started today. [46:28] What advice do you have for folks building [46:31] growth teams in maybe a similar space or just B2B, PLS-oriented businesses in general? What have you learned about what is important to get right? This is a big topic. I have a lot of thoughts here based on what I've seen work well and also not so well. I think I can broadly bucket things here into maybe three main topics. The first would be people and process. The second would be strategy. [46:57] and the third would be data. Now they're all related. [47:00] And they all have to be working well to be effective in growth. [47:04] Starting with people. [47:06] I've maybe touched the first element there in terms of balance teams. Now you've got to have those balance teams with, [47:13] diversity and ability to create great ideas, but also ability to execute. That's the first thing. But still on the topic of people, I have this kind of mental model that potential at its core is unbounded. [47:26] but that a bunch of things situationally prevent people from fulfilling their potential. You know, it might be how they're thinking about something. It might be organizational. It might be in relationships with coworkers or in broader team dynamics. It might be in them not even being in the right role even. So fundamentally, I think it's the role of managers and leaders to help them identify those things and work with them to find ways to thrive and grow.

[47:50] I've seen this have particular significance in a growth org where people are just naturally less good fit. [47:57] Now, that doesn't mean that they're not amazing, talented humans. It just means they aren't going to do their best work in a growth context. [48:06] When you're starting a growth team, you'll often be doing so with internal moves. So this can be something that's maybe a little bit easier to miss than with external candidates, where you're likely testing for those things explicitly during the hiring process. I'll share an example with developers. [48:22] So, [48:23] The devs that really thrive in a growth context are the ones that are motivated by moving quickly, [48:30] iterating to create measurable impact. They're not attached to their work. They embrace imperfection as part of the process. They happily discard their code. [48:38] their ideas even. You know, they're curious and they're always looking for ways to be closer to their users. Now, those are the folks that generally make [48:46] great growth engineers. I've also known incredible engineers that are most motivated when they're working on [48:53] really deep technical challenges and love the process as much as the outcome. [48:59] and they've struggled in growth. Of course, it's never that simple. [49:03] In reality, there's nobody who's really at either extremity of that spectrum. But it's really important to try to answer the question, can this person do their best work in this environment? [49:13] I think that's a really key part of it. And... [49:17] You need to also make sure they're well equipped from this kind of skills and knowledge perspective as well. So.

[49:23] They need the right skills and knowledge to be able to do their best work in the context of your growth process. So, [49:28] The ideal state is that every growth team member has common vocabulary, they're comfortable with the growth process, they can work well with data and experimentation platform, they understand the data, they have the right skills and mindset. Education, I think, plays a big part here. So, [49:44] We're big fans of Reforge, but we've also developed a bunch of internal programs to align and up level the teams. Something we learned recently. [49:52] I think... [49:53] as an example, is the importance of starting simple and going deeper as the Teams build experience. So, for example, when it comes to experimentation, [50:02] Don't try at the beginning to introduce multivariate testing or concepts like sequential sampling as an alternative evaluation approach. Teams are still trying to just dip their toes in this water. It's kind of a recipe for a lot of mistakes. [50:18] Yeah, that would be some advice there. But people also need to be well aligned. [50:23] I've talked about this actually on another podcast that I did recently. But what I mean by that is their execution needs to be aligned with an evolving growth strategy. The growth strategy needs to be aligned with and at the same time influence where the company's going. The growth strategy needs hooks into the product strategy. And ideally, there's some overlap and alignment of KPIs so the growth teams and the core product teams are swimming in the same direction. The skills and experience in the team need to be aligned with the strategy.

[50:53] focus on activation and acquisition, then someone who's, you know, a plans and pricing expert probably isn't the right set of skills at that point in time. [51:03] But also, leaders need to plan to ensure those skills are available, as focus of the growth team inevitably shifts over time. At the end of the day... [51:13] I think everyone needs to be able to easily answer the question why they're there, why the work they're doing is important. I don't know if it's... [51:21] too far off track here, but I have a vision and mission framework that I like to use that leads to, I think, great simple statements of an imagined better future state and your role in getting there. So I can talk about that a little bit if it's... Yeah, let's do it. That sounds too good to pass up. [51:36] Cool. So the vision. [51:39] is the nirvana state that you aim to enable for your users and customers in 5 to 10 years. [51:45] It's something that could equally be enabled by your competitors if you don't execute effectively or efficiently or quickly enough. [51:52] You can always prefix a vision statement with a, [51:55] in the future... [51:58] Now, it's something that should be bound to your target market, so not too wide and not too narrow. [52:03] And critically, it should not mention your company. [52:06] your product or anything solution related at all completely agnostic of those things [52:11] And then the mission, that's the thing that you're going to relentlessly iterate on to take you incrementally closer to the Nirvana state described in the vision. It should answer how you'll realize the vision. [52:22] by describing what your fundamental approach will be. In other words, what you will do and how you'll do it. It should ideally aim to encode any unique differentiating advantage you have. So if I think about Sneak at large,

[52:35] When it comes to Advantage, we might mention our unequaled security intelligence and knowledge of application context. And one of the neat things about this framework is if you find utility in doing so, you can apply it at every level from the company level all the way down to individual team. It doesn't mean the process is not difficult and you need to spend a lot of time, but it gives you this set of kind of a framework, a set of bounds that help you really come out with well-crafted statements that kind of stand the test of time. [53:05] Is there an example you could share of the mission vision, whether it's sneak or something else? Yeah. [53:10] Yeah, I'll give you one for the growth group at Snyk. So the vision, every developer securely unleashes their creativity. And the mission is to connect every developer and their organizations to the value of the Snyk platform with frictionless self-serve adoption and expansion. Interesting how the vision is so big beyond Snyk's current focus. And to your point, this kind of trickled down, right? There's a company vision and mission, and this is the growth team's mission vision. Awesome. [53:40] I wanna shift a bit and talk about your product org. So we've talked a lot about the growth org. I'm curious what the broader product org looks like. How many teams do you have? How do you structure it? [53:50] product focused, user focused, outcome focused, and then just how does that team work with the growth team. [53:58] Happy to go into a bunch of that stuff. I know I'd mentioned earlier kind of three areas of building a growth team. I don't know if you want me to cover those other two because we talked about. Oh, yeah. OK, let's do that. So let's finish that thread. Cool. So people in process was the first and we'll cover process really quickly. I think on the process side.

[54:16] At a minimum, you need well understood documented growth processes, practices, working cadences. Teams in growth need to work differently in some ways from R&D teams working on core product, assuming otherwise, and just giving growth responsibility to an existing team without working with them to implement appropriate ways of working. I think it's a common trap. Ideally, you get to a point there where the growth process is something that's continually refined and iterated on, trying to build in more predictability. [54:46] most singularly most important in a growth process is facilitating a rapid learning cadence and providing the means to socialize those learnings surfacing them in the right place at the right time so they can be leveraged in other contexts and if you think about experimentation it's not about delivering outcomes it's about generating learnings that the organization can leverage effectively to deliver outcomes might not be now might not be tomorrow or some point in the future [55:16] that without good process, learnings easily end up unused and gathering dust. And you have to ask them, what was the point? So that's people in process. And you know, [55:26] You know when that's on the right track, when you start to see enthusiastic sharing of learnings, when you see regular contribution of ideas coming from everyone in the form of well-crafted hypotheses that are based on data and learnings. And when you see a wide variety of folks just assuming end-to-end ownership of managing and running experiments instead of delegating that to the product manager or an engineer and tech lead.

[55:50] So, yeah, that's that's people in process and strategy. Let me throw in a question real quick before we get to the last piece. Sure. So learnings, just to kind of touch on that. I've heard more and more pushback on the idea of learnings being an outcome because a lot of [56:05] As a leader, you're not going to be like, "Cool, we learned so many things, but nothing really got done." How do you think about the tension between learnings? We want to learn. We also want to move metrics, grow the business, and learnings are a way to inform decisions more than even just [56:19] learn. How do you think about that kind of balance? Ultimately, you're there to create impact, right? There's no getting away from that. But learnings is the means. [56:28] It's the same as there's a quote that I love from Farid Masawa around focus on the user's path to value, not on monetization, because if you focus on the former, the latter will follow. And that's the same thing with learnings and impact. If you try and focus on the impact itself, you might struggle. If you focus on the things you need in terms of learnings to take you step by step, that will pave the path to creating impact. [56:58] as an output and the input is. [57:00] Let's learn a bunch of stuff about what works and doesn't work and use that to inform what we're going to double down on. [57:05] Exactly. You've got to focus on [57:09] When you build a strategic opportunity, [57:12] You're thinking about the outcomes, but you don't just go right to the end state. You've got to think about what's the quickest way we can test this hypothesis. And from there, what do we learn from that? And what do we take into the next set of experiments? And it kind of you're paving this path along the way. You know, kind of that rough destination, how you get there.

[57:32] You don't know at the start. And that's the path that the learnings take you on. Cool. Okay. And then strategy you were talking about. Strategy, yeah. So strategy... [57:43] It's a good one. At a very basic level, [57:46] You need to be able to answer it. [57:48] Questions? [57:49] How do you acquire users? How do you retain users? How do you monetize them? I know you talked with Elena on that in more depth, but from there you need [57:59] You need more detail that's going to guide the growth teams and where they look for strategic opportunity, how they approach that. The best way I've found to articulate a growth strategy that fulfills the promise of usefully guiding the team's execution, it's the loop-based model we forge as a team. [58:16] specific kind of documentation that I think is great around that. [58:21] Being able to identify the various micro and macro loops, how they're all connected, being able to document them in a qualitative model to communicate a shared understanding of how you grow. It's really powerful. Augmenting that then with. [58:36] You know, the quantitative side of things that helps guide quarter to quarter focus. [58:41] and ensure you can be intentional about where you're investing, that becomes a big enabler. [58:45] You know, you're never going to have. [58:47] a shortage of ideas in a high-performing growth team. So knowing where to focus amidst that kind of sea of ideas is a really important role of the strategy. And early on, you know, you'll probably have one or two core loops, but inevitably you'll need to layer on and connect new ones over time. And having a framework for doing that,

[59:09] and having a framework for regularly revisiting that in the context of growth team learnings, changes in broader company strategy, evolution of the product, new features being added and so on, market shifts. [59:21] that becomes a big up-leveler for teams to be able to create timely impacts. So, [59:25] The model you create there is what enables you to know it. [59:29] any time where the biggest constraints to your growth are and allows you to balance your growth investments accordingly. [59:35] At Sneak, for sure, we've had times where we've focused on a broad set of constraints and opportunities. [59:40] And other times where we've had a much narrower focus, for example, on driving improvement to activation and engagement, even more narrow, like doing that through empty states, for example. [59:50] I want to unpack the strategy piece real quick. How do you operationalize this idea of you have this growth model, growth loop you figured out, here's the ways we're growing? [59:58] How do you tactically connect that to a strategy? Is it, here's how we're growing, here's where we're going to focus this quarter, optimize this part of the loop? Or is there some other way you write it down, basically? [1:00:11] Very simply, it's first of all alignment on how you grow, [1:00:16] the different loops, how they work, the roles of different teams, and the roles that they play in fueling those loops and getting them to spin faster. [1:00:26] I think that's the first thing, having that common vocabulary and understanding. [1:00:30] Second is understanding the... [1:00:34] the way they work in terms of, [1:00:37] What is constraining them? What are the inputs to them?

[1:00:40] What are the opportunities for making those loops spin faster? How can multiple loops work together in a macro context? And particularly, [1:00:50] using the data there. [1:00:52] to be able to identify and understand and get alignment around [1:00:57] where are the biggest constraints in your growth model overall? And therefore, where are the things that we need to focus on as a team? [1:01:06] over the next quarter, two quarters, and so on. And it's constantly changing. As I mentioned, there's a bunch of stuff that needs to feed back into that model in terms of growth through performance, all the learnings you're making, and so on. That means it's changing and you're constantly reevaluating and it's guiding quarter to quarter planning. Cool. So just to make it even more concrete for folks that are listening, one of your loops is [1:01:36] at some point, somebody clicking that link to becoming a user is too high friction, too many people are falling out. So one strategy for one of the activation team could be, we're going to optimize this part of the funnel. So I'm clicking from GitHub to sign up as a user and get them to a point where they found value, right? Yeah, exactly that sort of thing or [1:01:57] Earlier on, for example, it might have been with taking that same example of that same loop, and this is sufficiently far in the past that it's easy for me to talk about. But we start with GitHub. We want to now expand the scope of that loop. We've seen success with it. We see the performance of that loop growing. But we think there's opportunity in saying let's expand that by adding support for Bitbucket. And now all of a sudden we spin up that same loop with Bitbucket and then GitLab and so on.

[1:02:27] Awesome. Okay, we could go a whole hour on just that piece. So we'll move on. And we'll save that for V2. Data was the last thing. And the growth team just can't function without data. Even with early stage products, before you have the needed volume of traffic to be able to run formal tests in reasonable timeframes, you still need to have signals that help you learn and inform your decisions, both quant and of course, qual through speaking with users. [1:02:58] invest early. The infrastructure, the tooling, and at a given scale, the dedicated people as well, they're going to be core to building out the growth team and they'll enable data to ultimately pretty much inform all critical decisions. So it was interesting that we didn't have a problem of not having enough data. In fact, there was an abundance of data, like too much. We collected absolutely everything. And the problem I identified very early was that [1:03:23] We didn't have enough behavioral specific data, and we weren't intentional enough about the data that we were collecting and how we were collecting it, which made the data hard to trust. [1:03:32] and that becomes a big problem. So we invested in tooling and processes for building out event tracking plans, and now we test conformance to schema of the instrumented code in our CI processes, so we have absolute confidence in the data. [1:03:47] So that was, you know, getting to a point of trustworthy behavioral data was absolutely key. But the reason I say invest early here is that to remember that it also takes time to accrue enough data that you can learn about and make some key decisions around retention, for example, or so that you have enough data to...

[1:04:05] to run regressions on, be able to inform definition of your activation metrics or engagement states and so on. So the earlier you can start collecting, the better. So, yeah, people in process, strategy and data. And you absolutely need all of those things to build and run an effective growth team when you get, [1:04:24] all of those things working. It's like rocket fuel for focus creativity, but at the same time, [1:04:29] you know, slowing down to put the maturity in place as an org scales at the pace sneak has, it's pretty much impossible. You still have to get stuff done while you're kind of building all that stuff out, right? You have to accept that you're going to make a bunch of mistakes along the way. You have to be [1:04:45] 100% comfortable with that. [1:04:47] And you have to treat those mistakes as learning opportunities that provide levers for improvement. And it's also useful to, you know, you asked about KPIs and what the team are responsible for. And that is one way in which a growth team absolutely understands. [1:05:01] needs to make impact and it's the way that primarily they're going to be held accountable. But it's also, I think, useful to think about the efficacy of the Growth Org, not just in terms of the impact they drive via experiments and new product experiences and on core growth KPIs, [1:05:16] but also how they enable and up-level the rest of the org. So, [1:05:20] For example, our entire product-led sales process. It's powered by an evolving model that describes our understanding of users, teams, accounts, the usage and adoption patterns and signals that best inform where and how our GTM team's focused. You know, insights from growth teams often have utility far beyond growth, but people can't know if something is useful to them if you haven't shared it with them. So the learnings made in the growth teams, even those for mistakes or failures, we socialize them widely and visibly.

[1:05:50] We want every R&D team to be leveraging experimentation where appropriate to learn, to create business impact. So one of the things we did here is creating a paved road for adoption of behavioral analytics and experimentation stack. Coach teams on getting started to make it as easy as possible for anyone to start to reap the benefits of the platform. Built out internal education programs on data-driven development, on experimentation. Built internal tools to help with metrics design and so on. [1:06:18] And then, [1:06:19] building core platform services as well that are useful for people outside of growth. So [1:06:24] We built services that power contextual onboarding. And originally that was the intent, but now those same services can be used anywhere in the product to give contextual experiences. I know that was a bit of a ramble, but hopefully there's one or two useful things in there. Yeah, there's two things I wanted to quickly follow up and then we can talk about the product team. You said you socialize learnings and experiment results. Is there anything you could share there about tips to do that? Do you have a tool you use that for? Is there someone posts stuff in Slack? Is it an email that goes out? [1:06:54] How do you actually socialize learning such that, say, a salesperson can do something with it? [1:07:00] Yes. So first of all, there's a bunch of Slack channels like Sync runs on Slack, basically. So there's a bunch of Slack channels. Even when we're planning experiments, those are kind of wide and in the open and we invite collaboration on those. [1:07:13] But from a ceremony perspective, we try hard to institutionalize ways to generate and leverage learnings. It's something I feel pretty strongly about. So we have these team level impact and learnings reviews loosely modeled from a blog years back down. I know six years, I want to say that Brian Balfour wrote about a similar ceremony from his HubSpot days.

[1:07:35] Now, if I had to pick one meeting that is the most important in the growth team, it would be this. The teams continuously document any learnings from data exploration, from experimentation, from user research, and so on. They document that in their weekly impact and learnings document. [1:07:52] you [1:07:52] Some teams find it better to pair up in advance into dedicated learning sessions to deep dive on specific relevant topics. But however it comes together, it's all kind of put into that document. When it comes to the meeting itself, it's usually run by the PM. [1:08:06] Most of it is spent discussing learnings that have been documented, their implications, how they can be leveraged in follow up work. [1:08:13] where they might have relevance to other teams and so on. A relatively smaller part of the meeting is also spent looking at key metrics. Some teams have actually split that out entirely into a separate meeting. And then no time at all is spent reviewing what the team have actually been doing. It's more on kind of the outcomes and the learning. So that's at the team level. But then we run that same meeting at the group level on a monthly basis. So that's run by the product engineering or marketing director for the growth group. And that's where all of the growth teams come together. They share some key learnings. [1:08:43] Can't share everything, of course. What they're doing is picking specific learnings that have potential relevance and utility across the other teams. So also as a standing agenda item for our user research team to share what we call developer insights. That's one of my personal favorite meetings to attend. It's always recorded and socialized with the rest of the company afterwards and everything. [1:09:03] Yeah, I'd say that's really important, but there's a bunch of different ways in which we're fanning out that information constantly.

[1:09:09] So cool. And this is a meeting that anyone can come to, like a sales person comes to to see what interesting stuff the product team has learned recently from experiments. [1:09:18] How cool. Would you be able to share a template of that document that you put together that we could include in the show notes? [1:09:23] Yeah, for sure. Sweet. And then the meeting, you said it's run by product, basically, like some of the product functions and ideas to share things they've learned in recent experiments, say, in the past month. [1:09:34] typically the team level ceremony. [1:09:37] It's PM-led. That's more from a facilitation perspective. The learnings are all brought forward by the various folks in the team, and each one of them who's contributed a learning will talk about that learning with the group, and facilitate the discussion from there. And then at the group level, [1:09:54] Those are read by the directors for the growth group and each team. It might be an engineering lead. It might be a tech lead. It might be a designer. It might be the product manager. We'll talk about some key learnings from that month. Makes sense. If there's nothing PMs are good at, it's facilitating meetings. So that makes sense. Okay. And so that's a good segue to just chatting a bit about the product org. I'm curious just like how you structure the product team and then how that works with the growth team. That's good. Yeah. So the product org, what do you want to know? [1:10:24] Just like how many teams do you have? Do you align it across by outcome? Or is it by surface area of a product? [1:10:33] Is the growth team adjacent to this product org? Is it like a unit within the product org? Or is it integrated, but I don't think it is? So yeah, just how do you-- what does that look like org chart-wise?

[1:10:44] Yeah, I think we've got a fairly common pattern for how we structure our product and wider R&D org. So most of the org is functional ownership based. There are a lot of really complex domains in the core products. So having that localized knowledge is important to be able to kind of own and run the code that teams ship. The growth teams on the other hand are structured by outcomes. We talked about that already, owning areas like acquisition, activation, engagement, monetization. [1:11:14] These outcomes and team remits change over time, as we talked about, but the teams here are often working on [1:11:21] Areas of the product where they don't own the code, which I think is the key difference between how we structure our growth teams and product teams, with some exceptions. One of the growth teams actually owns the onboarding flows and so on. So that does require a lot of trust. It requires very transparent communication mechanisms built into how we work. One of the meetings that we have regularly is experiment plan reviews. They're kind of ad hoc meetings. They're led by the experiment lead. [1:11:51] PM, could be anyone else in the team. But the important thing is a bunch of people will be invited there, especially stakeholders from other teams where [1:11:59] we might be experimenting on their surfaces. And that won't be the first time they've learned about this. We'd like to try and actually include them in co-designing the experiment plan, so they're kind of fully on board with it, but absolutely kind of inviting them into those experiment and views really key.

[1:12:15] If we're going to run an experiment on that surface, we need to make sure that everything in that experiment plan is watertight, especially from a scheduling perspective, because the last thing we want is a week and a half into an experiment for some change to happen within that surface from the product team unaware that an experiment's happening and completely invalidate the experiment. Cool. And then in terms of just org-wise, do you have a lieutenant that is responsible for just, say, the product? [1:12:42] team and then someone responsible for the growth team or the directors report up to you and you have a bunch of reports how do you how's that structure oh so so our cpo on the exec team manaj he runs the entire product organization he has four i want to say vps that own different areas so there's a couple of vps that own different areas of the product so first of all the our application [1:13:07] security products. Secondly, our cloud security products. Third is our [1:13:14] platform. [1:13:15] And fourth is what we call developer journeys, which is the area I own, which has a few groups within there, one of which being the growth group. [1:13:22] Got it. Okay, makes sense. Okay, there's just a couple more questions I want to ask that are like very tactical specific before we get to a very exciting lightning round to close this out. One is with a freemium product, there's always this question of what to put into free and what to put into the paid plans. Is there anything you've learned about how to think about that? What should be in free and what should be behind a paywall? Was it on your...

[1:13:46] on your show with Elena that she talked about kind of things that promote your growth model being good to land in free and things that add friction. Yeah. So I really liked that guidance. Um, [1:13:58] I'll add that for many businesses, there might be some cost of service element to consider as well. You know, providing a feature to free users is cost prohibitive due to the volume, then that's obviously something you're going to. [1:14:11] want to reserve for paid. I mean, ultimately, that was the whole reason cited behind Heroku recently removing their free button entirely. [1:14:18] I think your plans from free to the top, they should have well-defined understanding of the target customer, the use cases. They should map out or you should map out the motivations for motion between each. You're really clear about what are the drivers for someone to take a step from one plan to the next. For Sneak, the real drivers to move from free to a paid plan, for example, is when you want to secure business critical code and you start having needs around governance and compliance. [1:14:48] I think the other... [1:14:49] The other interesting dimension is how you approach trials. Like with most things, I think [1:14:54] We're still figuring that out at Sneak. I don't know that there's ever a perfect answer or even a correct answer here. Certainly different from product to product. We have a self-serve trial to support time-boxed evaluation of some of the capabilities that are reserved for our paid plans. But we're intentional in revisiting the model periodically. It's important, I think, to regularly challenge yourselves to ensure you don't fall into the trap of simply assuming what was best fit in the past is best fit now and in the future.

[1:15:22] What if the trial duration was limited by some dimension of usage instead of time? Or what if we didn't have a trial at all, but put more into the free plan with appropriate limits? How might [1:15:33] making those changes impact our growth model? It's not always easy to answer those questions, but I think there are some ways that you can help test there. For example, you might cohort trial users and teams who have low engagement and don't convert during the trial. And then when the trial ends, drop them back into a new enhanced free plan and monitor engagement there. So there's some [1:16:03] evaluating whether the model, the specific delineations between the plans and how you support evaluation and the motion between those plans. I think it's really important to do that. And also when it comes to PLG and sales, we talked about. [1:16:19] The self-serve motion, obviously it's big and important for sneak, but the sales-led motion, critically large as well and significantly impactful. [1:16:30] You need to think about the plan design and those motions across both aspects of PLG and the sales-led motion. When you have... [1:16:40] When you have a strong PLG foundation that is inclusive of a product-led sales motion, you're going to be in a really powerful position from the perspective of having a significant volume of highly qualified leads that are coming from the product. We actually track a metric that we call product-driven revenue, which basically accounts for all revenue in customers where we saw meaningful value-based activity in the product before there was any sales contact.

[1:17:10] interesting story about the PLG efficiency of your company across all revenue channels, self-serve and sales-led. And what's fascinating there is that the product-driven cohort contribute a relatively greater amount to net retention. So when you think about packaging, you really need to think about and understand that macro level contribution of the freemium motion and know what you're trying to optimize for, kind of balancing revenue today versus potential future revenue. [1:17:37] Is that increase in net revenue retention from product-led leads mostly because they start at a cheaper price, do you think? Or is it more that they just end up being better customers? It's a great question. I'm not sure I have a good answer to that now. [1:17:55] No problem. I'm still trying to figure that out. It's a good problem to have people adding more customers and seats. [1:18:07] and things like that. Is there anything that just has surprised you, something you've [1:18:11] from iterating on that comes to mind? I wouldn't say surprised me. [1:18:17] per se [1:18:18] but it's something that I think has... [1:18:21] It's perhaps obvious in retrospect, and that is that companies of different sizes, of different complexities, of different industries, from those that are very highly regulated to the other end of the spectrum, they're going to take advantage. [1:18:35] different lengths of time to need to evaluate. [1:18:40] properly. So being able to cater for those

[1:18:43] In some way, whether it might be dynamic trial lengths or whether it be trial lengths that are based on usage, things like that. I think that's it becomes really important. That's something to be thinking about for sure. Awesome. That's a great learning. I know Elena talks a lot about how trials often screw you because you don't give people enough time to really evaluate at a company. So that makes sense. [1:19:07] Last tactical question that I wanted to touch on is around activation and activation milestones. [1:19:13] doing a survey right now with Yuri that I think will come out before this episode airs. But anyway, in real time, I'm curious how you think about setting what the activation milestone is for a new Snyk user. So maybe just [1:19:28] Share briefly how you think about what is an activation milestone? Why is that important and then how you? I [1:19:33] define that for sneak like what is the milestone of a user is activated for your product [1:19:38] First of all, what is activation? So for us, activation is [1:19:43] is indicative of the team [1:19:47] forming a habit around the usage of sneak. And when I say the usage, I actually mean deriving core value, which is ultimately fixing vulnerabilities. It's not just logging in, right? It's not even just finding vulnerabilities. It's fixing vulnerabilities. So [1:20:02] Building a habit around that. [1:20:03] And the reason I say team instead of user is, and we actually base most of our definitions of activation engagement around teams, [1:20:12] It's really important because ultimately security is a team sport. That team might be one person, which case a user is equivalent to team, but often a team is multiple people. And we actually expect different people to fulfill different parts of the team activation journey. We also want to enumerate

[1:20:28] aggregate level activity around fix that sometimes happens off platform where we can't explicitly measure it at the user level. So in the activation process, we have setup moments, aha moments and habit moments. And our habit moment, [1:20:44] that we define as a team being activated, it's related to fixing vulnerabilities within 30 days of team creation. And the reason that is chosen, it's because there is a significant correlation with downstream and in that case with activation, three-month retention and retention again, based on, again, not just coming back and logging in, but still fixing. So teams that fix a [1:21:14] much more likely to still be fixing three months later. [1:21:18] That's really interesting. Yeah, I love that. How did you come up with that number? Was there a decision scientist that looked at some kind of inflection of like at 30 days? And it's probably not exactly 30 in real life, but it's like a nice round number. That's close enough, right? [1:21:34] Yeah, that's it. So there absolutely was a decision scientist involved, thankfully. We had to collect a lot of baseline data first. So after we built out the data platform, we needed actually to wait a bit to build a good data set. [1:21:47] We did a huge amount of quant analysis, a lot of spelunking of the data, applying ML models, along with a bunch of supporting call research as well. But we started really with...

[1:21:59] identifying the corpus owners and their use cases, different roles of different users within the team-based activation journey. [1:22:07] defining our retention metric, which is still fixing, it's whether a team is fixed, along with natural usage behavior and expected natural usage frequency. [1:22:18] And then we found the habit moment that ultimately most strongly correlated with improved long-term retention and [1:22:24] Most of kind of the numbers side of things came out of our MLOps platform. But after that, we then worked back to figure out that's the habit moment. That's what we see is activation, but there's a set of steps that, [1:22:36] Teams need to get there, so what's the aha moment? [1:22:39] Before that, what's the setup moment? And what are the individual steps that the team needs to go through to reach that setup moment? So, yeah, that's the overall process. And ultimately, it's a really strong model that allows us then to feed in the set of user level behaviors that we know can influence those different steps on that path to activation. Awesome. I'm excited to get this post out. And that's a really good anecdote of how a company comes up with it and what they said. I also just thought of another question. [1:23:09] I know I keep saying we're going to wrap this up, but here's a question. If it doesn't work, we'll get rid of it. [1:23:15] You mentioned a bunch of tools that you use, and I'm curious, if you have to think of what are the five most [1:23:22] important/valuable SaaS products to your organization, other than the obvious ones like Salesforce.

[1:23:29] What comes to mind? [1:23:31] When you say organization, do you mean sneak at large or do you mean the growth? Let's say let's start with growth and surrogate. Okay. So I'm going to say amplitude. [1:23:41] First of all, [1:23:43] Uh... [1:23:44] segment. [1:23:45] as a means to be able to get our data from the products to Amplitude and to everywhere else that cares about it, whether that be our kind of downstream BI system, Snugflake and Looker on top of that, or system marketing automation systems like Marketo and stuff like that. So I'd say Amplitude. I will next say Full Story. [1:24:12] which is, you know, absolutely fantastic for kind of session replays, of course, and, [1:24:18] Kind of it bridges that gap between qual and quant, right? I would say userinterviews.com. [1:24:26] which is comparable to usertesting.com, both of them amazing services in terms of getting fast, curated access to individuals to participate in user research. Sprig, [1:24:41] Here's another one. So Sprig is a fantastic kind of in-app survey. [1:24:47] platform which is what we primarily use it for but it also does a bunch of other cool stuff in terms of being able to test uh ux designs as well in app how many have i said i think four if there's anything else you could add a fifth okay if not we can move on that's awesome this is a really interesting list yeah i'll stick it at four okay is there anything for the wider product team that also comes to mind that you guys find really useful

[1:25:11] Airtable. In fact, Airtable for growth and product is just so flexible. You can do anything. In fact, if we think about growth, I should have mentioned that first because that's where we keep most of our experiment plans and knowledge base and our user research base. Okay, I like this question. I'm going to start asking it. This is great. Okay, that was a precursor to our very exciting lightning round. I'm just going to ask you a bunch of rapid fire questions. Okay. [1:25:36] Just answer whatever comes to mind. We'll keep it short and quick. [1:25:40] Question one: What are two or three books that you recommend most to other people? [1:25:44] I have been dreading this question as there are too many. So I'm just going to... [1:25:49] I'm going to pick a couple that I've enjoyed reading in recent months. [1:25:53] For product and growth geeks like me, or in fact anyone with more than a passing interest in data, I'll recommend How to Measure Anything by Douglas Hubbard. Second up, you had Marty Kagan on. [1:26:05] And he mentioned the book Sprint by Jake Knapp and John Zeratsky. And I love that book. But personally, their Make Time book, it was something that [1:26:15] radically change my relationship with information. And I recommend that to all TimeStar product people out there. And for number three, I'm going to say, This is How They Tell Me the World Ends by Nicole Perlroth, which gives an amazing view into the world of digital espionage. Oh, I read that book. Tim Ferriss recommended that at one point. That is a wild ass book. Very beautiful. [1:26:38] Cool. I love these recommendations. All right. That's it. Cool. Great choices. Okay, great. Favorite podcast other than the podcast you're currently on?

[1:26:46] maybe acquired with Ben Gilbert and David Rosenthal. I just wish I had enough time to listen to them all. Yeah, they're very long. I was just at an event where they interviewed someone live as like a live podcast. That was very cool. Those guys are pros. [1:27:00] What's a favorite recent movie or TV show? So a movie turning red on Disney Plus, which we love watching with our kids. It was just fun. TV show, the most recent Curb season, had me in tears as usual. They haven't had a new one in a while, right? So that's a little bit out there. Yeah, it's a little bit. Cool. I'm ready. The new one's coming. Oh, it is. Season 12. Yeah, they're ready. I don't love watching that show. My wife loves it. Cringe-ish. [1:27:26] painful but anyway watch it anyway and my wife's actually the same she can't watch it because she cringes too much okay we're reverse i love the awkwardness it's good for a product leader to have that enjoyment favorite interview question that you like to ask candidates give a couple here if it's not cheating too much first is one i like to ask when hiring for for anyone actually really um it's fast forward three years what's different about you then a lot of people will [1:27:56] where they aspire to be in terms of role or title. But what I'm really looking for is signals of humility, of self-awareness around areas of personal and professional growth. So [1:28:07] You know, people who can be open [1:28:10] about. [1:28:11] where they think they need to work on to grow themselves as people. I love that. Also,

[1:28:19] Just generally throughout interviews, I'm looking for curiosity. [1:28:22] So, [1:28:23] Day to day, good PMs will be asking why as much as my six year old son does, which is a lot. So I'll try and discern that through the course of the conversation. It's not really a question, but something I'm looking for. And then maybe I want to flip it because building on something that. [1:28:42] that Adam Fishman was saying, his theme of evaluating the people dimension of folks you're potentially going to work with when you're interviewing with a company. And this was a question I got asked myself recently by a candidate, which I just thought was brilliant. And that was, tell me about the diversity, equity, inclusion, and belonging initiatives that you've recently personally been involved with. And that, it just felt like a really great way for them to be able to test alignment of their personal values with those of someone they'd be working with [1:29:12] callbacks to other episodes you're making. You're definitely a power adopter of the podcast, and I really appreciate that. There we go. Last question. Who else in the industry do you most respect as a thought leader, as a leader in general? [1:29:26] So maybe I'll cheat on this one a bit too and [1:29:29] I'm not going to combine it to the industry, I think security industry, but I'm going to look at the product domain and specifically product operations. And in my mind, there's not many people who know more in this area than Christine Itwaru at Pendo. [1:29:43] So if you ever get a chance to talk with her, I know that would be a fun conversation. Many gems would be dropped, I think. Wow, I will get her on this podcast. That is my new goal. I had not heard of her, and that's awesome. Thank you for the suggestion.

[1:29:57] Ben, this has been awesome. So many nuggets and stories and insights. I so appreciate you being here. Two last questions. Where can folks find you online if they want to reach out or learn more or maybe come work at Sneak? And then how can listeners be useful to you? [1:30:13] Firstly, I just want to say a big thanks for having me on, Lenny. I love talking about all this stuff and really appreciate you being willing to let me bend your ear a little bit. It's been my pleasure. Thanks. As to finding me, I'm a bit of a twit when it comes to Twitter. I generally spend a bit more time over at LinkedIn, but you can find me on both of those platforms at semanticben.com. [1:30:35] And in terms of how people can be useful to me, I'm starting to take on some additional clients in advisory capacity. So feel free to get in touch if you think I could help. I can't not ask about Symantec, Ben, and what the story is there before we let you go. Actually, when I was at IBM, it was a focus that I had on linked data. [1:30:59] Yeah. It became semantic, Ben. All right. I love it. It's stuck. Awesome. All right, Ben, thank you so much for being here and thanks for listening. Thanks, Lenny. Take care. Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app. Also, please consider giving us a rating or leaving a review as that really helps other listeners find the podcast. You can find all

[1:31:29] See you in the next episode.