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.
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.
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:
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.
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.
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.
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.
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:
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.
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.
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.
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:
All of those are just to assess if you’re making a real buzz or not. In order to actually show results, track these:
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
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Gaurav Nukala shares his passion for both the healthcare and public sectors and how he’s working to influence technology and AI them both.
Hina Kharbey talks about how the roles of a mentor versus a coach differ, as well as the situations that work best for having each one.
The core premise of contingency theory is that there’s no universally correct way to lead a team or make decisions. Instead, it advocates for a strategy that’s flexible and adaptable to the situation at hand.
The most common application of correlation and regression is predictive analytics, which you can use to make day-to-day decisions.
Learn more →
