back to work

A free leaked-secrets report that turned silent risk into GitHub's top product-led growth motion

A free report that showed developers the secrets leaking in their own code, and turned that into GitHub's most successful product-led growth motion to date.

Problem

GitHub had ambitious growth goals for Secret Protection in 2025, but most developers and security teams had no easy way to see how exposed their code actually was. We were asking them to trust us that they had a problem they couldn't see.

My role

Design lead. I drove the PLG strategy that started this project, then co-designed the MVP scope and the end-to-end experience with a second designer, in close partnership with product and engineering.

Solution

A free, self-serve report that scans your codebase and lists the secrets currently leaking across your repos. Instead of telling people they had a problem, we showed them their own.

Outcome

20% conversion at launch, with the assessment quickly becoming GitHub's top product-led growth motion for Secret Protection. A year in, conversion is still holding at 12%.

Productizing what already worked manually

I got the idea from the field team, who talked to customers all day. Their most effective move was running a private leak report for a prospect, which almost always surfaced more exposure than the customer expected. I turned that into a self-serve report anyone could run on their own code, without ever talking to sales.

The bet: if developers and security leads could see their own leaked secrets in their own repos, the paid product would feel necessary on its own.

Holding scope under pressure

This was the highest-pressure project I had ever been handed in my career, with a big part of the department's ambitious targets depending on it. As visibility grew, stakeholders wanted to use the surface to sell more, surface more information about the product, and pull in adjacent features.

Early on my design partner and I tried to please everyone, and we got stuck in endless iteration cycles. I had to step back and reset our approach.

  • I realized that trying to design for everyone meant designing for no one.

I kept the team focused on one thing: showing customers the single piece of information that would make the paid product feel necessary. Anything that didn't support that, we cut. When the debates got bigger than I could resolve on my own, I brought in design leadership to back the direction. Escalating at the right moment, instead of trying to win every debate myself, kept the project moving.

Outcome

Three months after launch, the assessment had become the most successful PLG motion GitHub had shipped to date for Secret Protection. A year later, the conversion rate was still holding.

  • 20%
    conversion at launch
  • 50k+
    SRA runs to date
  • 1k+
    orgs running it weekly
  • 12%
    conversion a year later
  • 5.8k
    new-customer seats

The assessment now runs through roughly a thousand organizations a week, with more than 50,000 runs to date and a 12% conversion rate. The motion has since been copied by competitors and adopted by other teams inside GitHub.

Takeaways

  • Productize what already works manually. The best PLG ideas often come from how sales or support already close deals by hand. We just made it self-serve.
  • Trust your instincts sooner. Pleasing every voice is a trap. I had a clear direction earlier than I acted like I did. Once I named the one problem and held the team to it, alignment came faster.
  • Escalate when you need to. Bringing in leadership at the right moment is part of getting to the outcome, not a failure to handle it yourself.

On the GitHub blog