Investment decisions when building developer communities

tl;dr: In choosing where to spend your developer experience and advocacy dollars, investment in content, documentation, and initial developer experience is the most critical because it has the broadest addressable audience. But you also need to make an investment in more active engagements (Discord, Slack, Github, contributor resources) if you want to ensure involvement in your community is substantive and sticky.

Building channels for developers and growing a developer community should take a tiered approach. You should divide your investment between two tiers:

1. Passive community members
2. Active community members

Passive community members

The vast majority of developers only care about quality documentation, helpful content, and the ease of use of your product, APIs, SDKs, and tooling. They want HOWTOs, technical and product-centric blog posts, “follow the bouncing ball” implementation guides, integrations they can easily find and consume, etc. These needs are why high-quality projects have excellent documentation with their engineers, tech writers, and developer advocates focused generating comprehensive, elegant, and usability-centric content. Everyone generally cites the original gold standard here as folks like Stripe, Twilio, and Heroku. It is also why many open source projects and communities put so much effort into documentation.

This content is the top of the funnel for every developer you engage. It’s likely the first point of contact you’re going to have with 99% of your incoming community and is key to driving adoption. Getting this right is crucial. You should treat your community content, from documentation to tooling, as a product and identify the various user journeys you want to enable, instrument those journeys, build funnels, and use the analytics generated to refine the content.

Additionally, this is the point where you set the hook for your continued engagement of passive community members. To do this, you need to ensure updates to the roadmap, product, and release documentation or CHANGELOG are easy to see, understand, consume, and subscribe to. If I get two emails:

1. Marketing-centric product announcement
2. Product-centric release announcement

I am significantly more likely to read 2. than 1. Hell, half of 1. end up in my Spam folder. But even if it is pretty casual, I scan 2. to find out what’s changed and if there’s anything I need to do, or a new thing I might want, or some feature to make my implementation better. This engagement is a critical user journey that you should build a path for and instrument.

It’s also important to note that a segment of the passive community is the top of the funnel for your more active community. They either:

a) See something broken and want to fix it: PR your documentation, report a bug, open a PR, etc., or
b) Need something new and log a feature request or open a PR.

To ensure you grab their attention the user journey from passive to active needs to be frictionless and easy. On a scale of zero to “I can’t get the pricing without registering and dealing with a sales call,” annoyance this is like a 7. If I can’t interact with the community and find, or help contribute to, a solution, it’s often a trigger to find another implementation, project, or product.

Active community members

Active community members are folks who contribute code, write or fix documentation, and help other members of the community in your support channels. They can also be strong advocates for your product, by lending their technical credibility to you publicly and providing validation. This support is often critical for adoption: developers tend to adopt tools they see or sense have buy in from their peers. These active community members also represent a potential talent pool for hiring. To make more active members of the community, you need to ensure the experience as passive members of the community was positive and successful and that they can graduate smoothly into the active tier.

The active community is also internally tiered, here in decreasing order of segment size.

1. Folks who want to get help and who are generally active only once or twice.
2. Folks who are implementing your product or project and who need higher bandwidth communication and help. They may also contribute code and update documentation while engaged in a project for the duration of the implementation.
3. Folks interested in the project who want to be engaged and contribute to it because they either maintain it internally at their organization or view it as an interesting side project. Sometimes the former even migrate to the latter post their involvement for professional reasons. These are often the most active users in your community and do as much support as your own internal resources.

All of these groups primarily come, most often through your content, to scratch the itches I mentioned above. The biggest group is 1., the very transactional: “I found a bug” or “I don’t understand how to make x do y.” The classic scenario is: developer is doing a proof of concept (POC) and finds a bug. They dive into Github, Discord, Twitter, support channels, etc., and are looking for quick, immediate, and high-quality answers. If they have a good experience resolving that bug, it’s a strong contributing factor in your product coming out of the POC as the chosen product. This leads to implementation, and the developer sometimes moves into group 2. From here, a smaller group, I’d say conversion of these members is 10% or less in most OSS communities, move into group 3. But more often, the movement is cyclical and temporary: they might be involved while they are implementing and have a flurry of activity, and then you never hear from them again.

Active community members are the most effort-intensive to engage with given the higher bandwidth sought, desire for responsiveness, and often the deep engineering and product investment required to make them successful. Investment here can rarely be piecemeal and impactful investment likely requires dedicated resources, including some involvement from your Product and Engineering teams.

The danger to watch for here is the “squeaky wheels” in your active community consuming all your effort and resources. It’s exciting when cool folks pop up in your Discord, and you want them to love the product, and you want to help them. However, this is hugely resource-intensive, especially for a smaller organization or community. It can also come at the expense of investment in resources that could answer that user’s question without a required higher level of engagement. Especially given the vast majority of these engagements are singular and transactional. Inside your active community, focus on self-service and fostering a community of folks who can help their peers. Identify common missteps and problems and focus on developing product-based solutions or resources that address them.

Summary

You can see that you need to make investments in both tiers. If, however, I were to weigh investment between tiers, I’d ensure the needs of the passive community received higher investment than those of the active community. The addressable audience of the passive community will generally be much more extensive and the hardest to engage with from a product perspective; you will rarely hear about a missed prospect if they bounce off your content because it didn’t meet their needs. As you gain in usage your active community will grow, and you can make investments there also, but it wll only grow if the content at the top of funnel is open, engaging, and meets the community’s needs.