The clever Snyk growth loop using GitHub Pull Requests

A CGCD loop, but not as you know it

A few weeks ago, I wrote a post about Snyk’s biggest growth loop.

I recommend you check out that post first to get the background on Snyk, what they do, and an overview of how they grow. If you’re time-crunched, the TL;DR is that Snyk is a developer-first security platform - valued at ~$8B - that can find and automatically fix vulnerabilities in source code, open source dependencies, containers, infrastructure and cloud configurations.

Snyk makes very effective use of a number of growth loops that work together in a larger growth model.

Before becoming a full-time advisor with PLGeek, I was VP of Product at Snyk for two years, where I led PLG, developer experience and developer education.

In this post, I will analyse another one of the micro loops in the overall growth model - the pull request loop.

The pull request workflow

To set the scene, it’s important to understand how modern development teams collaborate to make changes to their codebase.

The Pull Request (PR) workflow is a common approach dev teams use to manage code changes. It involves creating a branch for a specific feature or bug fix, making changes to the code, and then submitting a pull request to merge those changes back into the main codebase.

Once a pull request is submitted, other team members can review the changes and provide feedback. This can include suggestions for improvement, identifying potential bugs or conflicts, or simply giving approval for the changes to be merged. The pull request can also trigger automated tests to ensure the changes do not introduce new issues.

Once the changes have been reviewed and approved, they can be merged into the main codebase. This can be done manually or automatically, depending on the team's preferences and the level of confidence in the changes. Teams using a pull request workflow collaborate more effectively, ensuring code quality and maintaining codebase consistency.

Note: Some source code management (SCM) systems have a different name for pull requests.

• GitHub, BitBucket: Pull Requests

• GitLab: Merge Requests

For the purposes of this article, pull requests can refer to any of these.

How Snyk supports the pull request workflow

Snyk has a number of workflows that support developers in their day-to-day tasks, and one of them plugs into the core development workflow with pull requests.

When dev teams connect their SCM to Snyk and select repositories to import, Snyk will scan those repositories and detect vulnerabilities, then display them:

Snyk knows how to fix many different types of vulnerability by making changes to source code, and as we’ve just learned, the way to do that is via pull requests.

If a developer clicks the ‘Fix this vulnerability’ CTA, upon confirmation Snyk will generate a pull request for the fix, which the team can review and merge to fix the issue.

In your SCM, pull requests will be prefixed with [Snyk] to make them easily recognisable - supporting simpler recognition by dev teams and important in the growth context, as you’ll see later.

Snyk also has the capability to automatically create pull requests to fix vulnerabilities. A set of smart defaults are implemented to prevent dev teams from being overwhelmed with hundreds of historical pull requests and ensure a manageable number of PRs are created each day.

In actively developed repositories, code is changing rapidly, and Snyk is continuously scanning code, finding new vulnerabilities, and creating PRs to fix them.

The Snyk Pull Request loop

So how does the Snyk Pull Request loop work?

Similar to some other loops that Snyk uses to great effect, it’s a Company Generated - Company Distributed (CGCD) content loop":

Credit to Reforge for the definition of a Company Generated Company Distributed content loop. Check out their Advanced Growth Strategy program created by Casey Winters and Kevin Kwok for a detailed breakdown of loop-based growth strategy.

The three steps of the Pull Request CGCD loop are:

1. Import a project and create a pull request

Developers import projects from supported PR-based SCMs, scan their repos and create fix/upgrade Pull Requests (or auto-created) to remediate discovered vulnerabilities.

WHAT: Uses Snyk to create fix PR

WHO: Developers (or Snyk, automated)

WHY: To reduce their risk and automate a manual task

2. View or interact with a pull request

Developers see the Pull Requests, learn about Snyk and click a link to bring them to the product.

WHAT: Views Snyk fix PR and clicks a link in the PR to learn more

WHO: Developers

WHY: Learn more about how Snyk can help them

3. New or returning users

Viewed Pull Requests drive developers to sign up or return to Snyk

WHAT: Signs up or returns

WHO: New or returning developer user

WHY: To proactively understand and fix vulnerabilities in their projects, with reduced effort

The pull requests themselves are designed to be both

• informative and effective in supporting developer tasks (e.g. quick evaluation of what the PR contains, what it fixes) and

• effective in bringing developers into Snyk

Why I love this loop

There are three things that I find fascinating about this loop.

1. It was a first-of-a-kind (FOAK) integration

Until Snyk introduced this capability there was nothing that natively integrated security remediation work into the native development workflow.

2. It’s simultaneously an acquisition loop and an engagement loop

The same mechanism works incredibly well in acquiring new users and bringing existing users back into the product.

3. It uses something other than Google as the distribution platform

Almost every example of content loops you’ll see is centred around distributing content through Google.

This loop is brilliant in finding an alternative distribution platform, with the added bonus that the audience is all in the target persona.

Yes, you can potentially reach a much bigger audience with Google search, but you’ll also be catching people that aren’t an ideal fit. Nevertheless, Snyk has incredibly effective CGCD loops built around SEO.

Snyk also has control over the PR surface area to dictate the format of the content - something obviously extremely limited with search results.

Not just new user acquisition within companies

This loop has been most effective at bringing in additional new developer users within an existing company using Snyk and driving engagement by making it easy for existing developer users to return.

That’s because most commercial company source code repos are private and only accessible to other devs in that team/company.

But the loop also has applicability and success more broadly.

When Snyk is integrated into open-source software (OSS) projects (a common use case for the Snyk Free plan which removes limits when used on OSS), this loop effectively creates awareness of Snyk and brings developers from new companies into Snyk. Initially, that might be to use on their personal dev projects, but inevitably some then graduate to use it on their work projects and introduce Snyk to their companies.

Extending the PR loop horizon

Just as with the Snyk Advisor loop, the PR loop was extended to create further headroom for growth.

GitHub was the first SCM that Snyk integrated this functionality with.

Later, support for Bitbucket and GitLab was added.

These changes were primarily driven by market expansion by making Snyk a more valuable offering for dev teams using those SCM platforms, but in doing so, the horizon of this growth loop further expanded.

Summary

Snyk pull requests were a groundbreaking innovation that fundamentally changed (simplified) how dev teams approached fixing vulnerabilities in their software.

Snyk’s philosophy has always focused on empowering developers to build software more securely without getting in their way, something encapsulated in this capability.

At the same time, it also created an effective dual purpose acquisition and engagement growth loop that is one of the more unique that I’ve seen.

If you have a really interesting example of a successful and non-obvious growth loop you’ve worked on or been involved with. I’d love to hear from you and potentially feature you in a future Product-Led Geek newsletter post. Just drop me a line at ben@plgeek.com.

Todays listen:

Product-Led Growth Benchmarks with Sam Richard on the Long Game Podcast

3 interesting reads:

1. Ellen Chisa on Where your VC can’t help

2. Michael Yaroshefsky with Zach DeWitt on the decision-free sales process

3. Kyle Poyar with the guide to SaaS metrics 2.0