This post by François Dufour is part of our series on Product-Led Growth and Developer Marketing Playbooks. There, we share insights and advice from leaders who have built successful PLG businesses that target software development teams.
Victor Coisne, VP of Marketing at Strapi, the open-source headless CMS, and former Head of Community Marketing at Docker, knows how to engage a large number of developers. The developer communities he helped build at both Docker and Strapi are a big part of the companies’ Go-To-Market strategy and competitive advantage.
I talked to Victor about his experience building and engaging these communities. He shared a lot of very concrete best practices on:
Victor’s perspective will be helpful to any leader looking to embrace bottom-up adoption with developers and grow their own developer community.
When it comes to cultivating a developer community, Victor recommends that founders stop obsessing over the quantity and quality of leads and start investing in relationships. After all, a community is the sum of relationships people have with one another and, early on, it’s essential that these relationships are nurtured and prioritized.
“Stop thinking in terms of lead scoring and start thinking in terms of relationship building. Early on, you need to invest in relationships.”
Additionally, Victor cautions founders to avoid a traditional marketing mindset. That is, founders should operate in what he calls “you mode,” meaning all of your marketing messaging should be about the developer you’re serving and what they are trying to build. Rather than talking about your company, product, and how amazing your features are, you need to focus on showing developers how they will benefit.
Having this “you mode” mindset lets you change the discussion; instead of being about selling, it becomes about turning someone into a successful user, ambassador, or advocate for your product. And, when people adopt your software successfully, they will naturally recommend it to others developers thus creating virality and word of mouth.
When you want to build a large community, it can be tempting to embark on campaigns or playbooks built for scale. But Victor recommends the opposite. “Do things that don’t scale,” he said. “It’s the best way to figure out if something might work.”
Victor recommends adopting an experimental mindset. Every idea you have for growing your community can likely be tested on a smaller, more manual scale to figure out if it’s viable. For example at Strapi, the team did a few guest blog posts as an experiment. After seeing that this strategy worked, the team programmitized the strategy around the Write for the Community program, knowing that it would pay off.
Not everything you try will be a success. But a small experiment can provide the information you need to decide where to invest your efforts.
A community flourishes when people make connections, which is why you need to find ways to connect members with each other.
At DockerCon, Docker’s annual conference, the team connected community members by offering a “hallway track,” which was essentially a matchmaking program. Matches were made based on use case, tech stack, and expertise level with Docker.
“The hallway track was a big part of the success of DockerCon because it was the ice breaker people needed to make meaningful connections with like-minded people. They left the conference having met 50 new people who were also committed to using Docker.”
Victor also facilitated introductions on a smaller scale as well, simply by introducing people he knew that he thought would have something in common.
Those seeking mentorship also benefited: at the conference, Docker Captains would hold 15-minute informal sessions in a given area so that Docker users who wanted to meet them or learn from them would have the opportunity to have a conversation around a specific pre-announced topic.
When Docker first started hosting in-person meetups, the team quickly realized that they'd need help from community members in order to scale. This meant accepting losing some control over the product marketing and brand narrative.
This created a bit of conflict internally, as the legal team would see the alteration of the Docker logo in each meetup group as a trademark infringement. But by allowing the community to self-organize and create a local sense of belonging, the Docker community was able to scale substantially.
Victor now recommends accepting this loss of control, as it ultimately leads to a bigger and stronger community around your company and product. A misshapen logo is a small thing when you consider that people are getting together in person to celebrate and discuss your technology.
To build a successful developer community, you need to be able to identify and really get to know your advocates.
Once you have established a real relationship, they can share their ideas on how to improve the platform and the community. You can then bring these community members together by creating an ambassador program.
You need to do more than connect on a superficial level, though. You need to connect personally to figure out what they care about.
In the early days, this means picking up the phone or scheduling a meeting to learn more about how they use your product and their motivations as very active members of the community. Remember, at this stage, it’s all about investing in relationships. It’s only when you have genuine relationships that you’ll be able to build a flourishing community.
“Community members feel so good when they see a founder or team recognizing and supporting them, so be sure to engage with as much as you possibly can.”
To identify power users and potential ambassadors, you can use new tools like Orbit and Common Room, which function as CRMs for your community. These tools can “identity match” across platforms, so you can see someone’s activity on Slack, Discord, or another tool. This gives you the full picture of how your community engages with your company. These tools also provide a “love score,” an indicator of how much these users love you. You can then connect with those who are most engaged.
Not everyone in your community will be the same. They’re individuals with different goals, interests, and skills. That’s why it’s important to offer different “swim lanes”, i.e. a channel or option for a community member to contribute. Each of these lanes has benefits to community members, but also to your company as well.
To determine what swim lanes to create, look at your company’s objectives and ask: what are the most important challenges or north star metrics and how can the community help in that process? From there, you can begin to develop the appropriate swim lanes for your audience, creating the feeling within your community that you’re solving and building together.
Here are some of the “swim lanes” offered to community members at both Strapi and Docker:
When it comes to motivating your community, cultivating intrinsic motivation is a more surefire path to success than motivating with money or gamification. Victor believes that recognition, especially when unexpected, has the best shot at developing relationships and encouraging community members.
At DockerCon, the CEO highlighted and recognized some of the most engaged community members during the keynote. Their work was shared in front of an audience of 5,000+ attendees, giving them a lot of prime-time attention. This was a surprise to these members. You can imagine how flattered and special they felt.
“We send out a lot of handwritten cards and swag, as well, but when it comes to swag, you want to make it a surprise. You don’t want to create a gamification program where someone jumps through hoops to get swag as a reward because this kills intrinsic motivation.”
Victor’s arrived at this point of view because he’s seen gamification programs go sideways. A friend of his started a gamification program that rewarded community members with swag when they reached certain milestones. Not only did members join and engage just to get the swag, but the company had many international members, so shipping out the swag became logistically difficult and expensive.
Even though engaged community members might be willing to help for free, it’s important to compensate financially anyone who’s making a “heavy lift.” Victor defines a heavy lift as any task that typically takes longer than two hours, such as writing an article or creating an in-depth video.
In order to truly motivate your ambassadors, you’ll want to treat members as an extension of your team. And, this culture of treating community members like team members begins internally.
““You’ll want to teach your internal teams to leverage the power of community, as they can really benefit from community members who provide feedback.””
Products can be improved through a product feedback loop that includes community members. Support documentation can be improved based on how valuable it is to community members.
But this doesn’t happen automatically: you’ll need to keep community members and their potential contributions top of mind. For example, at Strapi, community members can upvote new features on the product roadmap, which helps the product team prioritize what to build next.
Community members can also jump in as team members in a more literal way. At Strapi, the user success team fields a ton of questions from users. The Strapi team better supports these users by allowing community members to be moderators.
If community members are seen as a crucial part of every new product release, update, or marketing campaign, then community members will not only be an extension of the team but hugely grateful and more likely to share their positive experiences with others.
One of the most successful community programs at Docker was a global Meetup program led by Victor and his team. When the groups started, the goal was to educate audiences about Docker and the industry as a whole, as well as to grow a local ecosystem and connect users with each other.
At one time, the group had nearly 200 user groups across 60 countries with a community of 300,000 Meetup members. So many Meetups were happening that there was almost one Meetup every other day.
As the program grew, the team switched from using MeetUp to using Bevy (an event management system used by Atlassian and Duolingo) in an attempt to mutualize efforts across the groups worldwide. This also allowed the Docker team to keep better track of the number of events and RSVPs. Ultimately, it gave a consolidated view of the entire Meetup program.
They also used Open Collective, which is a way to collect and spend money transparently. It did not work out as well as expected, but the idea was to connect local sponsors with local meetup organizers and enable them to better manage the budget for their distributed community events.
It’s notoriously tricky to measure the impact and ROI of a community, as so many pieces are intangible and difficult to tie back to revenue. But Victor mentioned a few proxy metrics to measure specific community initiatives:
He also looks not only at the number of messages posted, but also the resulting engagement. If a message receives no responses, that’s a bad sign. You want healthy threads of information. In fact, looking at threads is a really good indicator.
As much as you can, you’ll want to measure the links between users and understand how many people are talking to each other. Tools like Orbit and Common Room can help you quantify the health of your community, as well.
Thanks so much, Victor, for sharing all these great tips, tools, and techniques, and congratulations on building such wonderful and engaged developer communities!