DevRel Explained for Product Managers

DevRel – or developer relations – describes the act of proactively engaging with and considering the needs of engineers whilst building your product in an attempt to develop and maintain a strong relationship with the developer community.

Developers are, and always will be, a critical part of product development. Not just because engineers are the ones actually building the products we use, but also because getting the engineering community on board as evangelists for your product can make or break your success.

In some sectors, product execs are fawning over the engineering community because they know what a boon it is for some products to have the engineering community on board.

But engineers can also be fickle and unpredictable, so cultivating a long lasting relationship with them is difficult.

In this post, we’ll explore why DevRel is important, what it means for your product strategy and how you might develop your own developer relations.

Why should I care about DevRel?

Web3, crypto and the rise of communities

Over the past couple of years, community engagement with engineers has been central to the success of products – including major Web3 projects. It is common for Web3 products to seek out not just investors, but engineers to support their blockchain.

The ill-fated $LUNA token, which recently lost pretty much its entire $40 billion market cap, is now seeking to reinvent itself with a new token. And part of the reason it’s able to attempt to pull off such an audacious move is because of the engineering community it cultivated before its descent into chaos.

With thousands of developers already bought into the Terra / Luna ecosystem, sunken cost kicked in and the engineers who built stuff on top of the original blockchain – many of whom are also investors – still want to see it succeed.

$LUNA founder Do Kwon made this clear in his string of tweets following the collapse of the token:

But I know what you’re thinking… that’s crypto. Can we talk about real products until so-called Web3 figures out what the hell it actually is?

OK, sure.

Outside of Web3, products and companies who develop a strong relationship with the engineering community could be setting themselves up for success for a number of reasons. And cultivating that relationship can have a major impact on your product strategy – and the decisions you make.

How? Let’s have a look.

How DevRel and product strategy are intertwined

For some companies, the non-technical consumer is their strategic focus. That’s not to say engineers are completely ignored, it’s just that the core focus is on building value for non-technical consumers.

Example – WordPress

WordPress powers around 40% of the entire web. That’s mind blowing. But what’s equally mind blowing is that if you speak to an engineer, many of them hate it. Whenever I’ve had conversations about building a blog to support a product, 99% of engineers will say ‘anything but WordPress please’.

WordPress has a bad reputation within the developer community, but that hasn’t hampered their growth efforts since they’ve placed a huge amount of emphasis on the end user: in this case, non-technical marketing folks and bloggers who want a quick solution for creating content.

That’s not to say WordPress does nothing for the developer community. Plenty of developers build plugins for it and the ecosystem is massive, but it’s absolutely not the go-to product for most product engineering teams.

For WordPress, DevRel is secondary to its core users: the marketers, bloggers and content writers who don’t want to learn HTML, CSS and JS to publish their content. But what about companies where DevRel is important to product strategy?

Developing strong relationships with the developer community is important in 3 broad instances:

1. Growth – the product’s growth is tied to engineering adoption. If engineers love and evangelise your product, it’s likely your product will grow. If your product contains a bunch of APIs, SDK or other tools that once adopted make it likely your product will grow, investing heavily in DevRel could be critical for your product strategy.
2. Utility – the product itself is targeted to, and used by engineers. Think Github, Gitlab or headless CMS solutions like Strapi or Storyblok. In these cases, engineers are your users – which means fostering a strong relationship with them is essential. If you craft a strong relationship with the engineering community, often they’ll appreciate this and live with the fact that some features are missing since they are reassured that the company is actively engaging with the community and cares about developers.
3. New technologies – your product is a brand new technology and you need engineers to love and adopt it for it to succeed. MongoDB, GraphQL, React etc all need engineers to adopt it for it to become ubiquitous and successful.

These aren’t the only instances where DevRel matters, but they give you an insight into some examples of where DevRel is important.

Let’s explore some real world examples to understand how each of these instances play out in the real world.

Monzo bank (growth)

For those of you not familiar with Monzo, it’s a major London-based challenger bank that has raised hundreds of millions and funding and saw its growth explode a few years back. It’s now a firmly established fintech player and was voted the UK’s most recommended bank.

In an article outlining how Monzo bank grew, the company’s co-founder and former CEO Tom Blomfield explains the things that worked to grow the company and the things that didn’t. Here’s something that didn’t work:

We spent more time on a second idea – hackathons and developer relations. A lot of the early team (including me) were software developers and we were really excited about the idea of a bank account with an API. We ran 3 or 4 hackathons early on (even before we had live prepaid cards) and folks came up with a handful of interesting ideas, but we realised pretty quickly that this wasn’t going to be a big growth mechanic. We only got 300 extra users, but it definitely helped hire several early engineers.

In Monzo’s experience, focusing heavily on DevRel didn’t do much to shift the needle in real user acquisition terms, but what it did do was open up opportunities to hire strong engineering candidates.

This is something to consider for your own product’s strategy. Even if there is no obvious way you believe cultivating DevRel will drive growth, consider the other benefits – in this case, hiring talent.

FourSquare (growth)

When FourSquare’s new CEO joined the company, the product was a struggling, B2C focused venture where users checked in to various locations on a mobile app.

The new CEO quickly realised that alongside the traditional B2C consumer route, another major opportunity was open to the company: an API-first product strategy that focused on the needs of developers to include information about places in their applications.

This led to the release of a bunch of new developer-centric products including the Places API. FourSquare used DevRel to propel its growth to new highs.

AWS, Azure, Google Cloud (utility)

AWS and the cloud computing space are clear examples of products whose utility is solely focused on the engineering community.

And it’s no surprise then, that these sectors are some of the most aggressive in their tactics for pursuing developer relations.

AWS hosts its Global Summit each year, where AWS leaders share the latest ways to use the cloud computing platform, alongside demos from developers in an attempt to persuade attendees to adopt the technology in their own products.

Azure and Google hold similar events with similar intentions, too.

These are some of the ways companies use their clout to try to woo developers and bring them on board to adopt their products. But how else can you improve your own DevRel for your product?

Let’s take a look.

Practical ways to improve developer relations

Any product company can make a decision to improve its relationship with developers and as we’ve just outlined, for some products, this will be fundamental to their product strategy. For others it might not be as critical.

If you’re weighing up whether to double down your efforts to focus on DevRel, here’s some questions to ask yourself:

Build internal teams dedicated to DevRel

Some companies will take DevRel so seriously that they’ll build internal teams dedicated to DevRel.

In this example, you can see FourSquare is hiring for a role it dubs ‘Developer Advocate’ whose responsibilities include:

• Fostering online community presence on key platforms
• Facilitating developer events
• Advocate for the developer community internally to influence product roadmap decisions

Deciding to foster a relationship with the engineering community is rarely enough; instead, you’ll need to dedicate resources to it and hiring folks specifically focused on this is certainly one way to do it.

Use niche channels and communities

Developers are unlikely to be using Facebook to discover the latest tools and technologies. If you’re serious about doubling down your efforts in DevRel you’ll probably need someone who understands where engineers are hanging out online so that you can influence opinions and behaviours.

Channels and communities like Reddit, Twitch and Discord are likely to be a good bet for influencing and shaping opinion, along with any influencers but these channels are constantly evolving so you’ll need to keep your finger on the pulse to understand where and when to engage with influential developers.

Of course, the product manager isn’t the best person to do this. You’re likely to need to leave this to those who know where to find engineers, instead.

Engage with the community

Finding out where engineers hang out is one thing, but actively engaging with them in meaningful ways is another. Some giants like Microsoft, Apple, AWS and Google have the resources to be able to hold massive events but most smaller companies don’t.

In this case, smaller companies can still engage with the community through online events, dedicated Discord channels, forums and other platforms.

If you have a beta version of your product available for testing or if your roadmap has been made publicly available, invite engineers along for the ride to collect feedback and develop a closer relationship. Always be mindful though, that engineers are super tech savvy, so unless your product is designed to be used by developers, their feedback is likely to be far more tech-centric than non-technical users.

Keep products and docs up to date

Outreach and engagement isn’t really worth your efforts unless you take the time to keep the engineering community happy in basic but essential ways. What do we mean by basic but essential ways?

Well, let’s say your API docs are out of date, or your response codes are meaningless. These little things will irk developers so much that no matter how many fancy webinars you run for them, they’ll quickly realise that you actually don’t care too much about their needs in reality.

Bringing it all together

Dedicating time and resources towards fostering developer relations is nothing new. But the emergence of DevRel as a potential lever for gaining a strategic advantage over your competitors is.

As a product manager, you don’t need to be the person spearheading your DevRel efforts in your company, but if your product strategy suggests that forging closer relations with the developer community means you’re more likely to succeed, or that you’ll fail without it, then it could be time to consider improving your DevRel-specific efforts.

On the flip side, if your product isn’t geared towards engineers and is unlikely to benefit from tactics designed to bring engineers on board then perhaps it’s best to just focus on the non-technical end users of your product instead. Focusing on non-technical end users doesn’t mean you’re doomed to fail, it just means you’ve made it clear which users are a priority – just ask WordPress.