Perspectives in Leadership: Github's Thibault Imbert on creating internal product champions

Thibault Imbert understands the power of product champions. Having a large number of individuals at your organization who are fluent in what your products and services do is great but it’s even better to have those same individuals be evangelists. 

Marketing comes in all shapes and sizes both paid and organic but few marketing tools are more powerful than word of mouth conversations that drive and build community building. Internal product champions are powerful seeds that foster community and product-led growth. But how can an organization create those champions?

Recently, Thibault joined Pluralsight’s Perspectives in Leadership podcast to discuss how organizations can create those internal evangelists, bringing product and marketing teams together, and the importance of swag! What follows is a written version of that discussion.

 

Listen to the full Perspectives in Leadership podcast episode

*Answers have been edited for clarity and length*

How can marketing, growth, and development teams work best together from your point of view?

It's a good question. I remember when I was a product manager, I thought we didn't need marketing. Then, and even now, I think the mindset of a developer or engineer is you build an amazing product and then it will just grow. You don't need marketing. With product-led growth (PLG), there’s some truth to the fact that the product can help the product grow by itself, but you still need a good marketing strategy. 

I think the most important thing is the culture; it’s the kinds of people you bring into marketing. It’s so important they understand the product. 

When I was at Adobe, I initially worked as a developer when Adobe acquired Macromedia and flash ruled the web. I coded every day, wrote books, and built demos. I was embedded in and connected to the community every day on Twitter and other channels. If a product marketer came in who didn’t understand the product, it was a problem. The product was so technical, you needed to understand it. I think this is a problem a lot of B2B businesses face when they have more technical products. There’s a difference between platforms like GitHub or Pluralsight and Spotify or YouTube. So I think the most important thing I’ve seen is for there to be trust and respect between the product and engineering teams. And that starts when the marketing team understands the product.

It would drive me crazy to sit in meetings where marketers, who have never used the product, make strategy suggestions. That’s the easiest way for an engineer to shut down and for the teams not to work together well. I don’t think marketers need to code every day, but they need to understand developers, know how to use the basics of the product, and understand the value of the product and the space it occupies. 

 

Most marketers don’t have a software development background. I know when I first started, the product marketers here at Pluralsight would talk about sprint movements and retrospective reports. Not a lot of it made sense to me because I didn’t have that background. But I knew if I was going to be able to tell stories about this product, I needed to watch how people used it and put my hands into it. I knew if I was going to be able to do my job, I was going to have to listen to the developers and listen more than I talk. In your experience, how do you seek out marketers with these diverse backgrounds? What types of traits or people do you look for to understand a product like GitHub?

I don't think there's a perfect playbook, but I will say that the number one managers often think of is a competitor. If you can poach a competitor’s employee, they already have a lot of industry and market knowledge and insights that accelerate their onboarding.

There’s sometimes also a benefit to bringing in people outside your market or industry, but with a product targeting the same audience. They may not have the product skills, but they understand the audience and the personas you’re targeting, so there’s some similarity.

For instance, could we hire at GitHub, someone that's worked on Slack or Asana? I think so. The audience is broader, but if I had someone who worked more in the developer area or with the audience for those specific products, I think that could work. But again, I think it depends on the technicality and product areas. It's important to find someone with an affinity or who understands the product. For platform tools like what we do, you want people who work in similar spaces or on adjacent products, but not necessarily with competitors.

As for what I look for, I usually ask a few standard questions during interviews:

• Who are our competitors?

• What do you think of our product?

• Have you used it?

If an interviewee doesn’t know our competitors and has never tried the product, I count those as red flags. I think someone coming into an interview needs to have that knowledge or at least demonstrated an effort to research.

 

So when you’re onboarding a marketer to create stories and other top of the funnel materials to generate interest in GitHub, how deep do you think their knowledge should be of the product?

I think it depends. I see the product marketing manager (PMM) as the CMO of the product. If you have a product where you've got a platform and four or five products or verticals, I think each PMM needs to be an expert in their respective space. And when I say an expert, I mean that person understands the needs of the customer and has used the product. If the product is targeting enterprise, they should at least have worked in a similar space in the past, understand customer challenges, be able to demo the product,and understand the channels that you want to look into for these products.

But it takes a village. I think at the end of the day, a PMM, the way I think about it, they are the point person, but they work with a team composed of content marketers, PR, growth marketers, and growth PMs. All of that makes a team that we call a squad at GitHub, where these people contribute value.

In this structure, the PMM has a solid understanding of the personas, the audience, the problem, the messaging, the competitive landscape, and the value prop—all the GTM stuff. The rest of the team provides the marketing expertise. So someone on social will think about content for YouTube, TikTok or other social platforms, where content marketers and SEO specialists might bring up specific keywords or topics to target. Growth marketers want to include CTAs on both platforms and will look for ways to get prospects to sign up for trials. Then your growth PMs are thinking about the full customer journey and what needs to happen to convert that trial into a paid customer.

But I think of the PMM as, at the end of the day, the person accountable for setting the strategy, signing off on the campaigns, driving tempo, maintaining the calendar, and being the person anyone can go to with questions.

One of the things I've really enjoyed about the culture at Pluralsight is our people use our products and believe in the importance of them. We also have a team devoted to creating communities and talking about our products. I just think that’s more powerful to hear from someone who uses and likes the product than a paid ad or search result. So I'm curious how GitHub creates or encourages internal product champions? 

I think the product led growth (PLG) movement is exploding right now because companies are realizing that having a product that drives its own acquisition and expansion and retention naturally organically through the product is the way you really accelerate the scale. 

We have a very powerful open source community. The majority of the traffic coming into GitHub is organic, meaning not paid traffic. And mostly from the repositories—the user generated content (UGC) loop that we have that drives the acquisition machine for GitHub. Most people find out about GitHub because they Googled something at some point like downloading YouTube videos or, if you're more technically minded, PDF library for Python and ended up in a GitHub repo with in-depth information written by another user. It becomes a feeding loop when those users who landed on GitHub sign up for the platform. Two years later they’re creating their own library, posting it on their blogs and telling their friends. Now you’ve become a user because you found it through a user and it creates this feeding loop that compounds itself. And that’s amazing.

So I think the way to create these champion is within the product itself. That’s how you grow. Especially today, you can exponentially grow at a very low cost by figuring out how your product and the core features can accelerate its own growth. On top of that, if you have a product people love, you’ve got what I think is the most durable and loyal word-of-mouth lever: your community. That’s one thing we’ve done well. We have 85 million developers using our product. And what do they do? They tell their friends and family what they build on the platform. That’s how virality happens.

 

In a traditional organization layout, you have the people building the products, the people marketing the products and the consumers using the products. And there isn’t a lot of communication between the groups. How do you bring all these teams together to create a feedback loop for the people building the products? 

I think it’s easier for GitHub because our engineers are also our consumers. When I was at Adobe, that wasn’t always the case. But at GitHub, we ask our product core engineers when we’re building features: “What do you folks think?” Because they’re our consumers, they can give us real feedback, so we’re able to to leverage our developers and engineers for customer research.

The GitHub product team is also very close to the community because it’s a very social product. So naturally, our team is plugged into the technology, the space and our developers on Twitter, Reddit and other platforms. So there’s a very deep connection with the community. To enhance that, we have a community team that’s constantly looking at the conversations and forums and fuels our feedback loop. We even created a system where our team can vote on the roadmap, so we’re building features so we can stay super connected with our community.

On the PLG side, I would love to say we have a playbook to engineer the product in a way that’s product led. But at the end of the day, customer value is what drives our efforts. Thomas Domke, our CEO, was speaking at a developer conference in Berlin not long ago and I love what he said. He said, at the end of the day, we want to make developers happy. That’s what we’re after; that’s our goal. And so that’s what drives us. We’re always asking how can we build the best developer experience or the ultimate developer experience. On the marketing and growth side, we take it even a step further and always have an eye on the areas where we think there’s opportunities to make the product accelerate our growth. So when the product team comes in with a feature request or improvement, we often ask if there’s a way to make it freely available so our consumers can get the value easier and faster. We’re trying to make the elements of the product frictionless, or more easily accessible to everyone. 

 

I think one thing that both of our organizations share is customer empathy. Like you mentioned with GitHub, we hear at Pluralist that people discovered us because they taught themselves something on our platform or learned something from one of our courses. Can you talk about the importance of customer empathy at GitHub and how you use that to continue to grow your products and communities?

The most important thing that you can do as a product owner or marketer is to spend time talking to customers. So that’s something we do a ton on the marketing side and the product side. For marketing, we have a “Customer Ask Me Anything” monthly meeting where we in bring customers, which we made a KR in FY 23. We said, we wanna talk to customers as a marketing team, all of us once a month. We're spending a few hours with a group of people and we rotate and we just talk to customers.

So that's one thing we do to be centered on the voice of the customer. We then also do surveys within the product experience. So if you're spending time on GitHub, you might see these little polls or surveys. They're not 15 page surveys where you're like: “Oh gosh, no. Please give me a gift card.” They’re very micro surveys to ask if a feature is useful or not useful and get feedback. I spend every morning looking at the results and the new feedback that's coming in. I keep telling my team the quantitative is the what, but the qualitative is the why.

It helps us understand things like why our conversion from free to paid is not doing that great this quarter. That’s why we spend time looking at the data; it could be a bug, a campaign, or something that changed in the product. For me personally, the aha moment often comes from a survey or conversation rather than a query. 

And then everything we do online, has an owner. Our DevRel team and developer advocates are completely immersed in different channels, taking feedback, looking at trends, and reporting their findings to the team. That feedback makes its way up the chain to our VP of Communities. That person is focused on the core part of GitHub where we have millions of very happy, free customers. Their job is solely focused on developer advocacy and developer relations.

I had a really interesting conversation with Joe Pulizzi, founder of Content Marketing Institute, where he said he’s not concerned with being everywhere. He wants to be on one or two platforms and be exceptional at it. He has over 150,000 followers on Twitter and over a million newsletter subscribers. So he’s not concerned about going on TikTok or YouTube. I’m curious for your opinion on whether that’s possible for organizations the size of Pluralsight and GitHub. Is there a tactic or platform that you think best resonates with your community or that you get really excited about when you see your team executing?

There's a few things. Number one, for developers, at the end of the day, it's about understanding the depth of the product, the new features, and what you can do with it. So for us, we’re focused on our blog and getting our customers to collaborate with us on technical articles. For instance, if someone is very technical on the Shopify platform, we want them to contribute to our articles and talk about the methods, libraries, frameworks, and languages they use. We want it to spark a constant debate between developers, including about the technical aspects of our products. 

I think the one thing we currently don’t do enough of is video content on the product experience. I’d love to see more customer stories to showcase how they use our products. Video is amazing for storytelling and we want to use it with our in-depth written content so if a developer doesn’t have time to read a five page, in-depth article about CI, CD, or security, they can also watch a video and be amazed by how a company in the Netherlands is using GitHub to solve big problems with retail. And when it’s a three minute short video, it’s easily shared with CEOs or VP of Engineering that drives awareness.

The other exciting thing we do at GitHub is swag. We joke that we’re a sticker company because everyone has had a GitHub sticker at some point in their lives. Many times, I’ll be talking to developers and they have a branded sticker, water bottle, or sweater. It’s an easy talking point, and many of them even have stories about how they’ve engaged with GitHub online or at one of our conferences. This year, we’re looking to elevate our swag game even more. I think it’s something that delights our communities. Our brand is loved and we want to continue investing in it. So stay tuned for some cool swag coming soon.