When you search “developer relations” on Linkedin, you get less than 1000 open positions. Do the same for “product manager,” and you’re looking at a 10 times bigger number. Do the same for “software developer,” and the number skyrockets to over 150 thousand.
Needless to say, developer relations is a very niche skill set, but as a PM it’s important that you know what it is, especially if you work with software developers. This article covers developer relations, including what it does, what its strategy looks like, and how to measure its success.
What is developer relations?
Developer relations isn’t about building bridges with your organization’s engineering team. It’s also not a different name for product owner or scrum master. A developer relations specialist — also called DevRel — is a cross-section between a community manager and a product marketing manager. Their goal is to drive product growth by fostering and engaging a healthy community of promoters and enthusiasts around your product.
The reason why this position is so niche is because it’s very, very focused on products that are either made for developers, or that have developers as strong stakeholders — think of cloud businesses, DevOps tools, AI & ML products, coding languages and frameworks, web security, and telemetry solutions.
What does developer relations do?
If your product either directly or indirectly targets the developer cohort, you could benefit from either a developer relations specialist or strategy. The first is probably out of your hands — unless you are a decision maker, in which case I suggest you hire one — so let’s focus more on the strategy, which is something that you can actually pitch and pursue.
A developer relations strategy orbits around four things:
Promote
Your main goal should be to raise awareness of why your product is amazing and how much value developers can take out of it. Coders aren’t particularly fond of catchphrases and inspirational messages, so get ready to get your hands dirty with prototyping, demos, use cases, comparisons, and blogging. More than getting your word out, you have to prove the value of your product in practice.
Be present
The person responsible for the developer relations role must be a face for the community. You need to do 1:1 in events, present keynotes, host events, be active on social media and relevant forums, draw attention to your product by drawing attention to yourself. Founders are usually the most passionate developer relations specialists.
Provide support
Everything breaks. That’s why you must be the first line of defense against frustration with your target audience. People usually are more vocal when they have bad or sub-par experiences, and that’s an amazing opportunity to turn the audience’s perception around by offering a solution, a worthy alternative, or simply a reassurance that the team will fix it.
Educate
Even if you succeed in all the previous attributions, one lingering question remains: how can I use this amazing solution? It’s your job to optimize how developers will read and understand the documentation that’s necessary to extract value from your product. Engaging with an HTML wizard is significantly different from doing the same with a Javascript beginner, and both are still under the front-end scope. Knowing how to tailor the learning curve of your product to the right audience is a big responsibility of DevRel.
What does a DevRel strategy look like?
There’s no one-size-fits-all, rigid framework you can use to build your strategy. Your product’s unique ecosystem will dictate a lot of what your priorities will be when allocating time and resources. While specifics may vary, an effective strategy typically encompasses these key pillars:
Community building
Create forums, Discord channels, Slack workspaces, Reddit communities; places where developers can connect, share insights, and collaboratively problem-solve. Your product should naturally become the nexus of these interactions, and therefore a top-of-mind and heart for those users.
You also need to listen to what people say about your product to anticipate problems, trends, and provide near real-time feedback for developers. Successful examples of community building can be found everywhere, from Midjourney’s Discord channel to Azure’s community support portal.
Documentation/content creation
Develop technical content to aid developers to use your tech, as well as to provide insights on use-cases and inspiration. This could range from in-depth blog posts and video tutorials to comprehensive documentation. The goal is to provide value even to those not yet using your product.
It’s pretty commonplace for engineers and technical product managers to assess how adherent a solution is to their needs based on reading publicly available API documentation and GitHub repositories. For developer-first products, your documentation is a better lead tool than any landing page could ever be.
Community presence
Creating your own community is powerful, but there’s an entire ecosystem out there that exists regardless of your presence. Immerse yourself in the developer world through hackathons, conferences, and meetups. Don’t just sponsor — actively participate. Run workshops, give talks, and demonstrate your product’s real-world applications for the potential users that haven’t seen your marketing, community, or public documentation.
Another way you can build credibility with the overall development community is by maintaining your own open source project, or contributing to existing ones that align with your product’s area. Meta is a silent front-runner in the AI race not because its models are the best, but because it offers the best *truly *open source models available.
A strategy centered around those pillars not only promotes your product, but genuinely enriches the developer ecosystem around it. This approach builds lasting relationships with users and scales your growth cycle, ensuring that users promote your product even more than your own marketing efforts.
How to measure the success of a developer relations strategy?
Instead of a non-exhaustive list that would just scratch the surface, I highly recommend you read this blog post from Kim Maida, DevRel expert, on how to measure your performance pipeline, from brand exposition to lead conversion.
She dives super deep into the subject but a high level summary is that measuring the ROI of a developer relations strategy isn’t that different from measuring the success of a branding strategy:
- Measure views, reads, likes, mentions, the amount and the frequency of online interactions you receive
- If you promote or go to events, measure attendance, invite conversion, speaker interest, booth traffic, everything that shows that developers are interested in knowing more
- Track the amount of webhits in your online documentation, how many SDKs have been downloaded, and how many commits your GitHub project has
All of those are just to assess if you’re making a real buzz or not. In order to actually show results, track these:
- From leads that come through the sales team, ask how they got to know you
- From events, take note of all the companies that interacted with your brand and later became a sale
- Have UTM trackers in several different landing pages, blog posts and social media links to identify where conversions in your website originated from
- Map your user journey and conversion funnels from documentation or blog websites up until the “buy” button or the “talk with us”
Conclusion
Developer relations is a very niche segment of growth that won’t be applicable in the majority of cases, but for those that see themselves in this context, it’s a must-use lever to promote your product.
Python, Microsoft, Grafana, Cloudflare, and almost all of the ubiquitous software engineering related brands today, got to this position thanks to a killing DevRel strategy that was both effective and consistent.
Payback doesn’t have a short turn-around time, and it’ll take a lot of spending before you start actually making money with developer relations. Be consistent, and once you build up a strong base, it’ll start to take care of itself.
Featured image source: IconScout