Welcome folks! 👋

This edition of The Product-Led Geek will take 8 minutes to read and you’ll learn about the early days of growth at GitHub:

• The importance of finding abandoned lands - neglected but important product areas where the team could ship wins without political battles

• How Thibault built credibility through scrappy execution using contractors and borrowed resources rather than waiting for perfect team structure

• How the growth team earned their way to core product access by becoming everyone's helper function and proving impact with transparent data

Let’s go!

GEEK LINKS

GEEK OUT

Building A Growth Team From Scratch At GitHub

If you’ve ever wondered what it really takes to start a growth team inside a big engineering company - especially one like GitHub, where “growth” sounded almost like a dirty word - this is your playbook.

Not the version with tidy frameworks and triumphant decks, but the honest version, full of skepticism, hacks, turf battles, and small wins that quietly changed everything.

This is the first of a three-part series of posts around growth at GitHub, written in collaboration with Thibault Imbert, former VP Growth at GitHub, and now Chief Product and Growth Officer at Creatopy.

Part 1 is the story of how Thibault built GitHub’s growth function from scratch, reawakened the company’s neglected self-serve muscle, and ended up making growth a core part of the business - one “abandoned land” at a time.

The story is useful precisely because it wasn’t a fairy tale: it’s a playbook for anyone trying to build something new in a culture that doesn’t know if it wants you.

Why GitHub Even Needed Growth

The soul of the GitHub product was always open source, developer-first, and allergic to anything that even smelled like marketing.

This was not just a GitHub thing, developer culture in general does not like traditional marketing.

The money, though, was mostly in big, top-down enterprise deals, especially after Microsoft acquired the company for $7.5 billion.

As the sales pipeline grew, self-serve - the engine that helped GitHub become a household name - got left behind.

Enterprise deals became the hero stories inside GitHub.

Self-serve was neglected: not out of malice, just because everyone’s focus drifted toward closing bigger, juicier deals.

Over time, most of the marketing spend and energy in GTM went to sales.

That made sense at first. It’s hard not to double down on what’s working.

But as anyone who’s watched this movie knows, it opens the door to problems.

The business kept growing, but self-serve started to look like a blind spot. It was neglected, underinvested, and quietly being picked apart by competitors who saw the gap.

Some product flows needed attention, onboarding was under staffed, the pricing page was out of date, and key surfaces that once pulled in new users started to feel unloved. GitHub’s own user-generated content was still working hard in the background - 95% of their traffic was still organic - but the company wasn’t capitalising on that traffic the way they once had.

The SEO engine was idling.

Developers were coming in but many did not see the value or understand the reasons to buy a paid plan, and most did not even know GitHub had a paid offering.

Meanwhile, competitors were moving in, targeting the same audiences with cleaner self-serve flows and better messaging.

For a growth leader, this is both a problem and an opening.

When an important piece of the business is neglected but not yet dead, you get a shot to rebuild it from the ground up - if you can get anyone to care.

Starting with Skepticism (and Not Much Else)

There had been attempts at building a growth function at GitHub in the past, but it lacked continuous support and focus under one leader. 

But for many, historically, growth meant spammy emails, sketchy notifications, or dark patterns that trick users into clicking buttons.

The engineers - who had built GitHub’s culture from the beginning - were skeptical of the user value that the growth team could bring.

The attitude was: our job is to build the best tool for developers, not to nudge them into buying something they don’t want.

This meant Thibault’s new “growth team'“ was really just two PMs, zero engineers, and an ocean of skepticism.

There wasn’t an established charter or roadmap.

No one rolled out the red carpet.

In fact, a lot of people were probably waiting for and expecting the growth team to fall flat on their face.

The challenge wasn’t about scaling a team or choosing the right tool. It was, “Will anyone even let us try?”

And the internal politics weren’t imaginary. At GitHub, product and engineering teams owned the core surfaces, and they weren’t eager to let outsiders in.

If the growth team wanted to ship something, they’d have to work at the edges - on things nobody else cared about, or where the pain of neglect was obvious but the political risk was low. They had to build trust, one step at a time.

Step 1: Find The Abandoned Lands

If you want to build credibility in a company like GitHub, you can’t kick down the front door. 

Trust is earned not given.

The smart play is to find what Thibault called the “abandoned lands” - parts of the product or site that matter to users but have been overlooked for years. Stuff that’s embarrassing, or obviously broken, but doesn’t have anyone’s name on it.

This isn’t as easy as it sounds.

In every company, there’s a long tail of neglected things - old landing pages, broken flows, outdated documentation, dead-end onboarding steps, pricing tables that haven’t changed since 2016.

The key is to find ones that still matter to users but aren’t owned by any powerful team.

If you can improve something like that, nobody will block you.

You get a clean win, and no turf war.

It’s almost a law of big companies: neglected, high-leverage opportunities pile up wherever everyone’s too busy to notice.

And because nobody’s career is riding on those surfaces, the politics are simple - do something good, and everyone’s grateful.

At worst, nobody notices; at best, you become the team that quietly fixes what others have ignored.

Step 2: Ship With What You Have (Even if It’s Not Much)

You’d think a company with $1B+ in ARR could spin up an engineering team for growth overnight.

Not even close.

Growth was unproven and nobody wanted to take resources away from core product for what looked like a risky side bet.

No engineers? Don’t wait. Get scrappy.

Thibault pulled in contractors from Brazil and Nigeria.

Why Brazil and Nigeria?

Because these folks were talented, fast, and most importantly, didn’t bring the same institutional baggage.

They just wanted to build.

Working with contractors outside the US had a double effect: it let the team move quickly, and it injected a sense of hustle.

There were fewer internal politics, less navel-gazing, and more bias toward action.

People from outside often see the product more like real users do, without years of legacy assumptions.

If you wait for perfect resources or permission, nothing gets done.

Scrappiness is a feature, not a bug.

The lesson: the longer you wait for the org to “bless” your team with headcount or authority, the more credibility you lose.

Ship something first. Authority follows.

Step 3: Score a Quick Win on the Edges

During his company onboarding, Thibault took a walk with Nat Friedman, CEO at the time. Nat told Thibault: 

This was great air cover to just ship to learn and go from there. When Thibault asked Nat about his thoughts to redesign the pricing page as a place to start, Nat responded: Love it. Just do it. 

So, the first big move: fix the pricing page.

This is classic abandoned land.

High visibility, high impact, but nobody in core engineering cared about it, and there was little risk of political blowback.

The page hadn’t been updated in years; it was cluttered, confusing, and did a bad job of communicating value. 

In a discussion with the Sales team, Thibault and the team learned that GitHub One was not even a plan we were selling anymore. 

Wait, what?! 

So the growth team tackled it.

They simplified the copy, clarified the difference between free and paid, made the upgrade paths obvious, and A/B tested versions to see what resonated.

They worked directly with design and data (and, when needed, legal) to get it out the door fast.

No grand rebrand or six-month overhaul.

A focused, iterative update, using real user data to guide decisions.

Before:

After:

What happened?

Conversion rates and new trials volume went up.

The sales pipeline wasn’t impacted.

Revenue increased.

More importantly, the win was visible: you didn’t have to “believe in growth”.

You could see, plain as day, that a neglected thing had become a lever for real business impact.

This single win started to shift the conversation.

For the first time, people across the org saw that growth didn’t have to mean “growth hacks” - it could mean improving user experience and delivering actual value to both users and the business. 

The cherry on top?

Many found the pricing page to just look much better. So it did have an impact on the business and gave the growth team pride in shipping beautiful things. 

The Credibility Loop: Data, Not Hype

Engineering-led orgs don’t trust slides, slogans, or bravado.

They trust numbers - if the numbers are clear, honest, and grounded in user reality.

That was the growth team’s next play: make every win transparent and measurable.

Every time the team shipped, they reported back:

• Here’s what we did

• Here’s what changed

• Here’s how it helped users and the business.

No grandstanding. No claiming credit for others’ work.

The focus was on impact.

Monthly Business Review (MBR) reports, dashboards and metrics were public.

The feedback loop was open.

And crucially, the growth team positioned themselves as collaborators, not competitors - inviting other teams into the process rather than threatening their territory.

They asked for input early, didn’t hide drafts, and let stakeholders see the process unfold.

They worked in the open, building trust by making sure everyone could see what was being tested and why.

This was the only thing that changed minds: clear, unambiguous data, delivered humbly.

Here’s what we changed. Here’s the effect.

It sounds simple, but inside a complex org, it’s a superpower.

Cross-Functional Allies: The Helper Function

A growth team on the edge has to become a helper function.

The fastest way to credibility isn’t to demand resources or complain about blockers; it’s to show up and help other teams solve their gnarliest problems.

The growth team at GitHub partnered with marketing (to refresh messaging), with data (to dig for friction and drop-offs), with sales (to improve self-serve leads), and with ops (to route users more intelligently).

By being the team that would volunteer for thankless jobs, growth started to get a reputation as folks who really get things done.

Instead of fighting for core product surfaces, they offered to fix whatever was broken or unloved.

This meant that other teams started to pull growth in, instead of pushing them away.

Executive support turned out to be a game-changer too.

Erica Anderson, SVP of Revenue at the time (today CRO at Notion) saw the upside with self-serve and understood it could work harder to grow the business and sponsored the creation and staffing of this team.

(More on that in a later post in the series).

This kind of sponsorship is what lets you try things that feel “risky” to the old culture.

When leadership saw the early results, they didn’t just approve - they asked for more.

This is something a lot of growth leaders miss: the most important ally isn’t the board or the CEO - it’s whoever feels the business pain of neglect.

Find that person, solve their problem, and you’ll get air cover for bolder experiments.

The Turning Point: "Can We Get More of That?"

After a few visible, low-drama wins, something shifted.

Instead of pushing for projects, the growth team started getting asked for help.

Leaders wanted more quick fixes, more abandoned lands revived.

The inflection point didn’t come from a single huge success.

It came from a pattern of small, uncontroversial wins that made people’s jobs easier.

When product, engineering, and sales all start to say, “Can we get more of that?” - that’s your invitation to move closer to the core.

The team became a utility, not a threat.

They were no longer asking for permission; they were being asked to help.

Scaling Without Losing Your Edge

As credibility grew, so did the team.

More PMs, more engineers, eventually a full-fledged growth org.

But the culture stayed: ship fast, measure impact, don’t ask for permission to help.

Work where you’re needed, and don’t try to “own” any surface before you’ve earned the right to do so.

Scaling up introduced new risks: it’s easy for a fast, scrappy team to turn into a slow, bureaucratic one as headcount rises.

But Thibault’s group kept the early rules alive: start small, move fast, focus on data, and keep working on things nobody else wanted to touch.

When the team got bigger budgets, they invested in data science, analytics, and new tools for experimentation, but never lost the “abandoned lands” instinct.

The result: growth started to drive real pipeline and revenue, not just edge-case wins.

Self-serve was no longer an afterthought - it became a pillar of the business again, with Product Led Sales and self-serve working together instead of competing.

What Can You Steal From This Playbook?

Here’s what matters for anyone trying to build a growth function in a skeptical, engineering-led company:

• Find neglected but important stuff: Don’t fight for the hottest projects. Find things nobody owns, but everyone wishes were better. Start there. Old flows, dead-end pages, friction nobody has time to fix - if it matters to users, it’s fair game.

• Ship scrappy: Don’t wait for the perfect team or budget. Get results with what you have. Outside contractors, borrowed resources, whatever gets the job done. The org will notice execution, not your hiring plan.

• Show your work: Data wins arguments. Share numbers, not hype. Open dashboards, honest impact, visible change. In technical cultures, evidence is everything.

• Be everyone’s helper: Offer to solve problems for other teams. Don’t be a jerk. Build goodwill and allies, not territory. Make yourself useful to the people who have the hardest jobs.

• Earn your way in: Don’t demand core product access. Start on the edges, and let wins open doors. The more trust you build, the more scope you get.

• Protect your culture as you scale: Keep the early playbook alive even as you add headcount. Don’t let new hires bring politics or process bloat. Scrappiness is a virtue.

• Look for the real pain: The exec who feels the pain of neglect is your champion. Help them, and you’ll get permission to take risks.

The Bottom Line

Building a growth team at a company like GitHub wasn’t about clever hacks or frameworks.

It was about fixing things that mattered, proving value in ways nobody could argue with, and being relentlessly useful -over and over - until the company started asking for more.

The real lesson is that growth is built on trust, credibility, and usefulness.

That comes from working on abandoned lands, shipping quick wins, and making life better for the people who need it most.

The big, glamorous stuff comes later - after you’ve earned your seat at the table.

It’s not glamorous, but it works.

If you’re building growth anywhere skeptical, it’s probably the only playbook that does.

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