Ben Williams
VP of Product at Snyk
Where to hear and read about Ben Williams1 episode or test
Lenny's PodcastHow Snyk built a product-led growth juggernaut | Ben Williams (VP of Product at Snyk)Ben Williams is VP of Product at Snyk, where he built the growth organization and now leads developer journeys, after a career in developer tooling at startups and IBM. The most useful lesson from him is to treat experiments as a way to generate shared learnings, and to build growth around product loops that keep users coming in and coming back.
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.
How Snyk built a product-led growth juggernaut | Ben Williams (VP of Product at Snyk)
Ben Williams: the story and the lessons
1Ben Williams's path from solutions engineer to Snyk
Williams reached product through customer-facing work in developer tooling. He graduated in computer science from Manchester in the late 90s with a developer job lined up, but chose a small startup building requirements management tools.
As a solutions engineer he ran demos and spoke to customers daily, close to the product team. He felt naturally drawn to engineering tooling.
After several acquisitions he ended up leading product strategy at IBM Rational. He landed in IBM's Rational developer tooling group and led parts of product strategy there.
IBM taught him a lot, but he did not want to work in an organization of 350,000 people.
He led product, design and growth at CloudBees before joining Snyk. At CloudBees, an open core devops startup, he spent three years leading product, design and growth. The company went through several funding raises and fast growth in that time.
Earlier he led a devops transformation at a fintech and did some consulting.
Williams joined Snyk because it sat where his interests overlap. He was not looking for a new role when Snyk approached him. His interests were product-led growth, community-led growth, developers and security.
He joined to build the growth organization and lead developer experience. His remit is now broader than growth: he owns developer journeys, one of four VP areas under the CPO, alongside application security, cloud security and platform.
Snyk is a developer-first security platform of about 1,300 people. Founded in 2015, it covers code, open source dependencies, containers, infrastructure and cloud configurations. It has well over 2,000 paying customers, around 500 people in R&D and nearly 70 in product.
2How Snyk won its first users with one narrow niche
Snyk broke from top-down security by building for developers. Security was a centralized function of audits and enforcement, with CSOs and appsec leaders as buyers. The founders, Guy, Danny and Assaf, saw developers caring about security the way they care about performance.
Existing tools slowed developers down, which meant poor adoption, engagement and retention.
Williams says to start with one narrow persona, context and use case. Snyk began with Node.js developers securing the open source dependencies in their apps. The community was big enough to be viable but small enough to influence, and the product could reach market quickly.
"Nailing that narrow and deep use case before expanding wider was absolutely critical." Going deep first validated the product on the path to product-market fit.
The founders found the first hundred users by working Node.js conferences. Early evangelism was in person, mostly at conferences rather than one online forum. Snyk was first unveiled at the Velocity Conference in Amsterdam, and about 5,000 free users existed before any monetization attempt.
The first product was a command line tool run locally or in CI/CD. Acquisition and retention were product-led from the start, even though monetization was unclear.
Depth gave Snyk a clear definition of what to build. A JavaScript developer does not care about Go or Rust support, but does care if automated package upgrades are missing for npm.
Williams notes that New Relic ran the same playbook with the Ruby community. The large market is tempting, but you have to build a service that earns it.
3The growth loops Williams helped build into Snyk
Williams argues founders should design acquisition loops before product-market fit. Once retention shows fit, the question is where new users come from, and assuming that if we build it they will come is the risk. Snyk had its loops built in, so they were ready when fit arrived.
Loops should cover every touchpoint, in and out of the core app.
Snyk-branded fix pull requests became both an acquisition and engagement loop. Snyk scans a connected GitHub repo, finds vulnerabilities and opens fix pull requests. The description explains the vulnerability and links to Snyk, so other developers in the repo see it and some sign up.
It was a first-of-its-kind integration. Because Snyk controls the content, the loop also brings existing users back. It was later extended to Bitbucket, then GitLab.
Snyk Advisor turned data Snyk already had into search traffic. Advisor indexes open source packages across package managers and adds metadata such as security scans and a package health score based on how actively maintained the project is. Hundreds of thousands of pages are generated automatically.
Pages rank for package names and functions, carry calls to action to secure your own app, and let visitors compare similar packages.
Snyk publishes security lessons with no signup or paywall. Bite-sized developer security lessons sit in the public domain, unlike traditional vendors that require payment beyond a couple of lessons.
It is another company-generated, company-distributed loop and supports making developers care about security. Referral and invite loops also exist, which Williams calls well understood.
Williams says to take security to developers instead of pulling them out of flow. Developers must care about security because their companies need to be secure, but flow is incredibly important to them. One person connecting their repos can protect code that a thousand developers work in, without those developers signing up.
He says caring about security as much as performance or functional quality still has a long way to go.
4Snyk's failed self-serve monetization and the fix
Usage was strong but self-serve revenue stalled. Early self-serve revenue came mostly from individual developers paying about $100 a month. Larger companies did not buy the way everyone had hoped.
Many investors held back because there was usage but no proven path to money. Aired at Bolster, one of the first true believers, helped provide runway.
Security teams needed breadth and governance that the narrow product lacked. They are accountable for the whole tech stack, so Snyk spent months adding languages, ecosystems and table-stakes governance features such as reporting and robust user management.
"It was time to move beyond that depth first approach." At the time, security leaders were the only buyers, and developer-first security was not something CISOs were driving.
Sales and marketing hires plus a broader product unlocked growth. Developer adoption was never the problem, and the free user base kept growing during the enterprise struggle. Once the first sales and marketing hires arrived and the product gained breadth, it became rocket ship time.
That free momentum ultimately fueled the sales-led business. Today self-serve also works, and Snyk has self-serve-only customers that have scaled quite large.
5How Williams structures growth teams
Williams formalized growth late and large, because PLG was already in Snyk's DNA. Growth was ad hoc until he joined and created the developer growth group. Teams usually start with one to four people, but Snyk started much bigger, shifting from simple freemium to a coordinated PLG strategy.
Execs were aligned and sponsoring the motion. The goal was to spin the flywheel faster, not to start it.
Teams are sequenced by the biggest constraint, with monetization deferred. The group first focused on acquisition and activation, deliberately holding off on monetization work until it had built growth muscles. Today there are acquisition, activation and monetization teams plus a platform team that owns data and experimentation.
The structure changes over time to target the biggest constraint.
Each growth team has a growth marketer embedded to fix R&D friction. Teams have engineers, an engineering manager, a PM, a designer, a growth marketer and decision science support, all on common objectives and KPIs. Misaligned incentives between R&D and growth marketing had left great ideas unexecuted.
A marketer built a high-performing SEO page with no engineering, which led to a paste-your-code scan. Traffic and new users rose, sign-up rate dipped a little, and activation rates rose.
Decision science at Snyk is about action, not reporting. The function grew out of business intelligence analysts and builds predictive models that improve decisions and power in-product experiences.
Williams does not call it revolutionary. He says the name implies a bias toward action over data for its own sake.
A deep SEO specialist writes the rules while engineers and PMs write pages. The SEO lead sits in growth marketing, tracks Google algorithm changes and gives continuously updated guidelines on how content should be structured.
She understands SEO far more deeply than Williams could.
Growth teams must agree experiment plans with the owners of what they test. Core R&D is organized by functional ownership, while growth teams own outcomes on surfaces they do not own. Williams has them hold plan reviews and invite stakeholders to co-design the plan.
This avoids a product change mid-test that would "completely invalidate the experiment".
6Williams on hiring and training for growth
Williams checks fit for growth, not just talent. Strong growth engineers like moving fast, are not attached to their code, and want to be near users. Excellent engineers who love deep technical challenges and the process itself often struggle in growth.
Internal moves make misfit easy to miss, so he asks whether each person can do their best work in this environment.
He teaches experimentation skills simply first and goes deeper later. Snyk uses Reforge and internal programs to build a common vocabulary. Introducing multivariate testing or sequential sampling too early is a recipe for mistakes.
He also lines up team execution, growth strategy and product strategy, with overlapping KPIs so growth and core product teams swim the same way.
He hires for self-awareness and curiosity. He asks candidates what will be different about them in three years, listening for personal and professional growth rather than a target title. Good PMs ask why as often as his six-year-old son.
One candidate asked about his recent diversity, equity, inclusion and belonging work, which he saw as a way to test value alignment with future colleagues.
7How Williams runs experimentation and shares learnings
Williams treats experiments as a source of learnings, not outcomes. Goals still target metric movement, but you know the rough destination and not the route. For a strategic opportunity he asks for the quickest test, what it taught and what the next experiments are.
He borrows a line from Fareed Mosavat: focus on the user's path to value, not on monetization, and the latter follows. Without a process to share them, learnings gather dust.
Growth teams need their own ways of working, not R&D's. Handing growth to an existing team without new ways of working is a common trap. The process needs documented practices and cadences, refined over time, with a rapid learning cadence as its main job.
Three signs it works: people share learnings with enthusiasm, everyone contributes data-grounded hypotheses, and many people own experiments end to end.
A weekly learnings meeting is the most important one on his teams. Teams document learnings in a weekly impact and learnings doc. The PM runs a meeting spent mostly on learnings and implications, little on metrics and none on activity.
Loosely modeled on a Brian Balfour post from his HubSpot days. "If I had to pick one meeting that as the most important in the growth team it would be this."
A monthly group meeting passes on only learnings other teams can use. A director from product, engineering or marketing runs it, and each team picks its most relevant learnings. User research shares developer insights as a standing item, recorded for the whole company.
Anyone, including salespeople, can attend. Experiment planning itself happens in open Slack channels.
8Williams on growth strategy, data and activation
Williams documents growth as connected loops, then adds the numbers. A qualitative model of micro and macro loops gives everyone a shared picture of how the product grows. Quantitative data then shows the biggest constraint and sets each quarter's focus.
"You're never gonna have a shortage of ideas in a high performing growth team," so the model decides which to pursue. If too many users drop between the GitHub fix PR and sign-up, an activation team optimizes that step.
Snyk's data problem was trust, so Williams invested in behavioral tracking. Snyk collected everything but lacked intentional behavioral data. It built event tracking plans and now tests conformance to schema of instrumented code in CI.
Starting early matters because retention analysis and the regressions that define activation need accrued data. Before there is traffic, qualitative conversations still give signals.
Snyk defines activation as a team fixing a vulnerability in 30 days. A decision scientist found that teams fixing a vulnerability in their first 30 days are much more likely to still be fixing three months later. Retention was defined as still fixing, not just logging in.
They worked backward from this habit moment to the aha moment, the setup moment and the steps to reach each. Definitions rest on teams because security is a team sport.
Growth teams lift the rest of the company and should accept mistakes. At Snyk's pace, pausing to build maturity is impossible, so mistakes become learning opportunities. Growth built the model of users, teams and accounts that product-led sales runs on.
A paved road helps any R&D team adopt behavioral analytics and experimentation. The tool stack includes Segment, Amplitude, FullStory, UserInterviews, Sprig and Airtable for plans and knowledge.
9Williams on free plans, trials and measuring PLG
Williams maps plan design to the motivations for upgrading. Features that feed the growth model go free, and features that add friction or cost to serve can be paid. For Snyk, paying starts when users secure business-critical code and need governance and compliance.
Heroku cited cost of service for dropping its free plan.
He says trial design has no perfect answer, so keep testing it. Snyk has a time-boxed self-serve trial and revisits it periodically. One test is moving unconverted, low-engagement trial users into an enhanced free plan and watching engagement.
Companies of different sizes and industries need different evaluation lengths, so dynamic or usage-based trials help.
Snyk tracks product-driven revenue to measure how well PLG works. It counts revenue from customers who showed meaningful value in the product before any sales contact. That cohort contributes relatively more to net retention.
Williams says he does not know why. A strong PLG foundation with product-led sales gives a high volume of qualified leads.
How Snyk built a product-led growth juggernaut | Ben Williams (VP of Product at Snyk)
Ben Williams explains how Snyk grew from a narrow node.js community play into a product-led growth and product-led sales business, and how its growth, product and data teams are set up. He also covers the early self-serve monetization attempt that failed, and Snyk reached an $8.5 billion valuation with over 2,000 paying customers.
Williams reached product through customer-facing work in developer tooling. He graduated in computer science from Manchester in the late 90s with a developer job lined up, but chose a small startup building requirements management tools.
As a solutions engineer he ran demos and spoke to customers daily, close to the product team. He felt naturally drawn to engineering tooling.
After several acquisitions he ended up leading product strategy at IBM Rational. He landed in IBM's Rational developer tooling group and led parts of product strategy there.
IBM taught him a lot, but he did not want to work in an organization of 350,000 people.
He led product, design and growth at CloudBees before joining Snyk. At CloudBees, an open core devops startup, he spent three years leading product, design and growth. The company went through several funding raises and fast growth in that time.
Earlier he led a devops transformation at a fintech and did some consulting.
Williams joined Snyk because it sat where his interests overlap. He was not looking for a new role when Snyk approached him. His interests were product-led growth, community-led growth, developers and security.
He joined to build the growth organization and lead developer experience. His remit is now broader than growth: he owns developer journeys, one of four VP areas under the CPO, alongside application security, cloud security and platform.
Snyk is a developer-first security platform of about 1,300 people. Founded in 2015, it covers code, open source dependencies, containers, infrastructure and cloud configurations. It has well over 2,000 paying customers, around 500 people in R&D and nearly 70 in product.
Snyk broke from top-down security by building for developers. Security was a centralized function of audits and enforcement, with CSOs and appsec leaders as buyers. The founders, Guy, Danny and Assaf, saw developers caring about security the way they care about performance.
Existing tools slowed developers down, which meant poor adoption, engagement and retention.
Williams says to start with one narrow persona, context and use case. Snyk began with Node.js developers securing the open source dependencies in their apps. The community was big enough to be viable but small enough to influence, and the product could reach market quickly.
"Nailing that narrow and deep use case before expanding wider was absolutely critical." Going deep first validated the product on the path to product-market fit.
The founders found the first hundred users by working Node.js conferences. Early evangelism was in person, mostly at conferences rather than one online forum. Snyk was first unveiled at the Velocity Conference in Amsterdam, and about 5,000 free users existed before any monetization attempt.
The first product was a command line tool run locally or in CI/CD. Acquisition and retention were product-led from the start, even though monetization was unclear.
Depth gave Snyk a clear definition of what to build. A JavaScript developer does not care about Go or Rust support, but does care if automated package upgrades are missing for npm.
Williams notes that New Relic ran the same playbook with the Ruby community. The large market is tempting, but you have to build a service that earns it.
Williams argues founders should design acquisition loops before product-market fit. Once retention shows fit, the question is where new users come from, and assuming that if we build it they will come is the risk. Snyk had its loops built in, so they were ready when fit arrived.
Loops should cover every touchpoint, in and out of the core app.
Snyk-branded fix pull requests became both an acquisition and engagement loop. Snyk scans a connected GitHub repo, finds vulnerabilities and opens fix pull requests. The description explains the vulnerability and links to Snyk, so other developers in the repo see it and some sign up.
It was a first-of-its-kind integration. Because Snyk controls the content, the loop also brings existing users back. It was later extended to Bitbucket, then GitLab.
Snyk Advisor turned data Snyk already had into search traffic. Advisor indexes open source packages across package managers and adds metadata such as security scans and a package health score based on how actively maintained the project is. Hundreds of thousands of pages are generated automatically.
Pages rank for package names and functions, carry calls to action to secure your own app, and let visitors compare similar packages.
Snyk publishes security lessons with no signup or paywall. Bite-sized developer security lessons sit in the public domain, unlike traditional vendors that require payment beyond a couple of lessons.
It is another company-generated, company-distributed loop and supports making developers care about security. Referral and invite loops also exist, which Williams calls well understood.
Williams says to take security to developers instead of pulling them out of flow. Developers must care about security because their companies need to be secure, but flow is incredibly important to them. One person connecting their repos can protect code that a thousand developers work in, without those developers signing up.
He says caring about security as much as performance or functional quality still has a long way to go.
Usage was strong but self-serve revenue stalled. Early self-serve revenue came mostly from individual developers paying about $100 a month. Larger companies did not buy the way everyone had hoped.
Many investors held back because there was usage but no proven path to money. Aired at Bolster, one of the first true believers, helped provide runway.
Security teams needed breadth and governance that the narrow product lacked. They are accountable for the whole tech stack, so Snyk spent months adding languages, ecosystems and table-stakes governance features such as reporting and robust user management.
"It was time to move beyond that depth first approach." At the time, security leaders were the only buyers, and developer-first security was not something CISOs were driving.
Sales and marketing hires plus a broader product unlocked growth. Developer adoption was never the problem, and the free user base kept growing during the enterprise struggle. Once the first sales and marketing hires arrived and the product gained breadth, it became rocket ship time.
That free momentum ultimately fueled the sales-led business. Today self-serve also works, and Snyk has self-serve-only customers that have scaled quite large.
Williams formalized growth late and large, because PLG was already in Snyk's DNA. Growth was ad hoc until he joined and created the developer growth group. Teams usually start with one to four people, but Snyk started much bigger, shifting from simple freemium to a coordinated PLG strategy.
Execs were aligned and sponsoring the motion. The goal was to spin the flywheel faster, not to start it.
Teams are sequenced by the biggest constraint, with monetization deferred. The group first focused on acquisition and activation, deliberately holding off on monetization work until it had built growth muscles. Today there are acquisition, activation and monetization teams plus a platform team that owns data and experimentation.
The structure changes over time to target the biggest constraint.
Each growth team has a growth marketer embedded to fix R&D friction. Teams have engineers, an engineering manager, a PM, a designer, a growth marketer and decision science support, all on common objectives and KPIs. Misaligned incentives between R&D and growth marketing had left great ideas unexecuted.
A marketer built a high-performing SEO page with no engineering, which led to a paste-your-code scan. Traffic and new users rose, sign-up rate dipped a little, and activation rates rose.
Decision science at Snyk is about action, not reporting. The function grew out of business intelligence analysts and builds predictive models that improve decisions and power in-product experiences.
Williams does not call it revolutionary. He says the name implies a bias toward action over data for its own sake.
A deep SEO specialist writes the rules while engineers and PMs write pages. The SEO lead sits in growth marketing, tracks Google algorithm changes and gives continuously updated guidelines on how content should be structured.
She understands SEO far more deeply than Williams could.
Growth teams must agree experiment plans with the owners of what they test. Core R&D is organized by functional ownership, while growth teams own outcomes on surfaces they do not own. Williams has them hold plan reviews and invite stakeholders to co-design the plan.
This avoids a product change mid-test that would "completely invalidate the experiment".
Williams checks fit for growth, not just talent. Strong growth engineers like moving fast, are not attached to their code, and want to be near users. Excellent engineers who love deep technical challenges and the process itself often struggle in growth.
Internal moves make misfit easy to miss, so he asks whether each person can do their best work in this environment.
He teaches experimentation skills simply first and goes deeper later. Snyk uses Reforge and internal programs to build a common vocabulary. Introducing multivariate testing or sequential sampling too early is a recipe for mistakes.
He also lines up team execution, growth strategy and product strategy, with overlapping KPIs so growth and core product teams swim the same way.
He hires for self-awareness and curiosity. He asks candidates what will be different about them in three years, listening for personal and professional growth rather than a target title. Good PMs ask why as often as his six-year-old son.
One candidate asked about his recent diversity, equity, inclusion and belonging work, which he saw as a way to test value alignment with future colleagues.
Williams treats experiments as a source of learnings, not outcomes. Goals still target metric movement, but you know the rough destination and not the route. For a strategic opportunity he asks for the quickest test, what it taught and what the next experiments are.
He borrows a line from Fareed Mosavat: focus on the user's path to value, not on monetization, and the latter follows. Without a process to share them, learnings gather dust.
Growth teams need their own ways of working, not R&D's. Handing growth to an existing team without new ways of working is a common trap. The process needs documented practices and cadences, refined over time, with a rapid learning cadence as its main job.
Three signs it works: people share learnings with enthusiasm, everyone contributes data-grounded hypotheses, and many people own experiments end to end.
A weekly learnings meeting is the most important one on his teams. Teams document learnings in a weekly impact and learnings doc. The PM runs a meeting spent mostly on learnings and implications, little on metrics and none on activity.
Loosely modeled on a Brian Balfour post from his HubSpot days. "If I had to pick one meeting that as the most important in the growth team it would be this."
A monthly group meeting passes on only learnings other teams can use. A director from product, engineering or marketing runs it, and each team picks its most relevant learnings. User research shares developer insights as a standing item, recorded for the whole company.
Anyone, including salespeople, can attend. Experiment planning itself happens in open Slack channels.
Williams documents growth as connected loops, then adds the numbers. A qualitative model of micro and macro loops gives everyone a shared picture of how the product grows. Quantitative data then shows the biggest constraint and sets each quarter's focus.
"You're never gonna have a shortage of ideas in a high performing growth team," so the model decides which to pursue. If too many users drop between the GitHub fix PR and sign-up, an activation team optimizes that step.
Snyk's data problem was trust, so Williams invested in behavioral tracking. Snyk collected everything but lacked intentional behavioral data. It built event tracking plans and now tests conformance to schema of instrumented code in CI.
Starting early matters because retention analysis and the regressions that define activation need accrued data. Before there is traffic, qualitative conversations still give signals.
Snyk defines activation as a team fixing a vulnerability in 30 days. A decision scientist found that teams fixing a vulnerability in their first 30 days are much more likely to still be fixing three months later. Retention was defined as still fixing, not just logging in.
They worked backward from this habit moment to the aha moment, the setup moment and the steps to reach each. Definitions rest on teams because security is a team sport.
Growth teams lift the rest of the company and should accept mistakes. At Snyk's pace, pausing to build maturity is impossible, so mistakes become learning opportunities. Growth built the model of users, teams and accounts that product-led sales runs on.
A paved road helps any R&D team adopt behavioral analytics and experimentation. The tool stack includes Segment, Amplitude, FullStory, UserInterviews, Sprig and Airtable for plans and knowledge.
Williams maps plan design to the motivations for upgrading. Features that feed the growth model go free, and features that add friction or cost to serve can be paid. For Snyk, paying starts when users secure business-critical code and need governance and compliance.
Heroku cited cost of service for dropping its free plan.
He says trial design has no perfect answer, so keep testing it. Snyk has a time-boxed self-serve trial and revisits it periodically. One test is moving unconverted, low-engagement trial users into an enhanced free plan and watching engagement.
Companies of different sizes and industries need different evaluation lengths, so dynamic or usage-based trials help.
Snyk tracks product-driven revenue to measure how well PLG works. It counts revenue from customers who showed meaningful value in the product before any sales contact. That cohort contributes relatively more to net retention.
Williams says he does not know why. A strong PLG foundation with product-led sales gives a high volume of qualified leads.