Welcome folks! 👋

This edition of The Product-Led Geek will take 8 minutes to read and you’ll learn:

• How GitHub achieved a 35% conversion lift and over $1 million in self-serve ARR uplift through transparent signup flow design.

• Why treating developers with honesty about free versus paid features created both business growth and improved user experience.

• Practical tips for designing signup flows that balance conversion optimisation with authentic user communication.

Let’s go!

GEEK LINKS

GEEK OUT

The Million-Dollar Experiment: How GitHub Boosted Conversions with a Single Flow Change

GitHub's reputation as the heart of open source code sharing came with an unexpected challenge: many users didn't realise it was also a business with premium features.

GitHub was beloved by developers, but its paid features were like a secret menu - easy to miss, hard to explain, and buried away so as to never interfere with the core developer experience.

But behind the scenes, the business reality was shifting.

Enterprise deals were thriving, but self-serve was severely neglected.

There was money left on the table, and the gap was getting wider.

It was a missed revenue opportunity, but it was also a missed chance to help more users get real value from GitHub.

This is the story of how a single, carefully designed change to the signup flow delivered a 35% lift in conversions and more than $1 million in extra ARR.

It’s about the value of being honest with your users, why inspiration can come from unexpected places (hello, Grammarly), and how even at a company as big as GitHub, sometimes all it takes is a clear experiment and a little courage.

This is part 2 in a series of 3 posts in collaboration with Thibault Imbert, former VP Growth at GitHub, and now Chief Product and Growth Officer at Creatopy.

The Problem: Paid Features Hiding in Plain Sight

The confusion wasn’t just among casual users - lots of developers didn’t really understand the difference between free and paid plans.

Even people who paid often didn’t know what extra value they were getting.

This was more than a branding issue.

It was a growth blocker hiding in plain sight.

The core self-serve flows - the pages and experiences that turned curious visitors into paying customers - didn’t do enough to tell the story.

Paid features were tucked away, explained only if you went looking.

The idea was to keep things clean and dev-friendly.

In practice, it meant a lot of people never saw a reason to upgrade at all.

Thibault put it bluntly:

The Spark: Inspiration from an Unexpected Place

Growth at GitHub didn’t start with a perfect roadmap.

But good ideas can come from anywhere - sometimes from outside your industry entirely.

Thibault credits a key moment to an experience with Grammarly, of all things.

Grammarly had built a signup flow that was segmented, transparent, and highly effective at showing users the value of upgrading.

They didn’t just ask users to pay - they oriented them, clearly, around the value they’d get and where the free/paid line was drawn.

Thibault’s thought process:

GitHub’s signup, by contrast, was a bit of a black box.

New users hit a wall of options, often with jargon, and very little guidance on which path was right for them.

Most just picked “free” by default, not out of cheapness but because they had no idea what they might be missing.

So the question became: What if we stopped being coy about value, and started being honest?

What if we made the paid features not just visible, but clear, and helped users self-select into the plan that made the most sense for them?

The Approach: Designing with Developer Empathy

It’s easy to say “just show the value.”

The challenge at GitHub was to do it in a way that felt right for developers - clear, no hard sell, and no dark patterns.

The team went back to basics.

So Thibault’s team decided to redesign the signup flow, inspired by Grammarly’s segmented approach, but with GitHub’s culture in mind. That meant:

• Transparency: Instead of hiding paid features, they made them visible up front. Each plan was laid out with clear, plain-English explanations of what was included.

• Customer insights: They ran a survey and asked the current paid developers across the plans to rank their favourite paid features. They then used these on the upsell screens, in the order they were ranked,

• Segmentation: Each upsell screen was segmented based on the developer profile signing up, being an individual, a team from a startup or an Enterprise. The features they presented and the value prop had to be different.

• Empathy: The copy was rewritten to sound like a developer talking to another developer, not a marketer trying to extract value. No scare tactics or FOMO.

• Self-selection: The flow helped users figure out which plan was right for them based on their actual needs, not just price.

• No Pressure: Crucially, there was no forced upsell. Users could choose free without guilt or friction.

The A/B Test That Needed Double Verification

When the new segmented signup flow was ready, the team ran an A/B test with the old flow as a control.

The experiment tracked not just signups, but actual upgrades to paid plans and downstream usage.

When the experiment concluded and the numbers came in, they looked almost too good to be true: conversion rates were up across the board.

In particular, the percentage of new users opting for paid plans jumped by more than a third!

Thibault recalls:

The results: a 35% lift in paid conversions.

At GitHub’s scale, this was worth over $1 million in new ARR.

All from a single flow change!

Why Transparency Worked (and Why It Usually Does)

A lot of growth teams get nervous about being too honest with users.

What if showing the “catch” (that some features cost money) scares people away?

But in developer tools especially, the opposite is true.

Developers value clarity, straight talk, and the sense that they’re in control.

If you try to conceal anything, you lose trust - and trust is the only real currency in a community like GitHub’s.

By laying out, clearly, what was free and what was paid, GitHub accomplished two things:

1. Set Expectations: Users knew what they were getting and what they weren’t, so there were fewer surprises and less confusion later.

2. Raised the Ceiling: People who might have assumed “free is enough” saw, maybe for the first time, what they were missing - and realised they actually wanted those paid features.

The big surprise wasn’t just the conversion lift, but how positive the feedback was.

The new flow was more effective from a metrics perspective; but users also liked it better. It felt honest, not pushy. And it helped more people get value from the platform, which was the whole point.

Presenting to the CEO: The Litmus Test

When you change something this fundamental - especially at a company where product purity matters - there’s always a final boss.

In GitHub’s case, that was CEO Nat Friedman, who set a famously high bar for design and developer experience.

Thibault remembers the meeting vividly:

This exchange gave the team validation that they were doing the right thing and approaching growth the way it needed to be in GitHub:

Building delightful experiences that fit the company culture and DevEx bar, and at the same time oriented users better on the value of the platform.

Practical Takeaways for Your Own Signup Flows

Here’s what this experiment proves, and how you can use it - even if you’re not GitHub:

• Don’t Hide the Ball: If you have paid features, make them obvious. Users aren’t dumb; what they hate is feeling tricked or misled.

• Segment by Needs, Not Price: Help users figure out what’s right for them. Don’t make them guess or search for what the plans really mean.

• Write Like a Human: Cut the marketing jargon. Talk like a real person, ideally like one user talking to another.

• A/B Test Everything: You don’t have to guess if something will work. Run the test, look at the numbers, and trust the data—even if it surprises you.

• Get Leadership Buy-In: Big changes need champions. Make sure someone with real influence is rooting for your experiment.

• Respect the Culture: Growth doesn’t have to mean betraying your product’s soul. If you do it right, it can reinforce it.

The Balance: Conversion vs. Authenticity

The most interesting part of this story isn’t the revenue.

It’s how the experiment managed to boost conversions without making the experience worse for users.

If anything, it made the product more trustworthy and easier to love.

At a lot of companies, there’s a fight between “growth people” and “product people.”

The secret here was aligning both: show users the value honestly, make it easy to pick what’s right, and you’ll win both more revenue and more loyalty.

The end result?

GitHub not only made more money - they made more developers feel seen and respected. And that’s how you build something that lasts.

The Bottom Line

If you want to drive real growth - especially in a skeptical, engineering-led culture - don’t start with tricks or FOMO.

Start with the truth.

The single most effective thing GitHub did was to show users what was actually on the table, let them decide, and trust that if the value was clear, people would step up.

One experiment, one honest flow, $1 million in ARR, and a lot of lessons for anyone willing to be clear and brave with their users.

THAT’S A WRAP

Before you go, here are 3 ways I can help:

Take the FREE Learning Velocity Index assessment - Discover how your team's ability to learn and leverage learnings stacks up in the product-led world. Takes 2 minutes and you get free advice.

Book a free 1:1 consultation call with me - I keep a handful of slots open each week for founders and product growth leaders to explore working together and get some free advice along the way. Book a call.

Sponsor this newsletter - Reach over 7600 founders, leaders and operators working in product and growth at some of the world’s best tech companies including Paypal, Adobe, Canva, Miro, Amplitude, Google, Meta, Tailscale, Twilio and Salesforce.

That’s all for today,

If there are any product, growth or leadership topics that you’d like me to write about, just hit reply to this email or leave a comment and let me know!

And if you enjoyed this post, consider upgrading to a VIG Membership to get the full Product-Led Geek experience and access to every post in the archive including all guides.

Until next time!

— Ben