The divisive developer database

Emerald A piece from Raoul De Keyser, an artist I recently discovered | What’s with the random art?

Few topics raise tensions in a marketing org like bringing up the developer database. Sales teams need leads to follow up on and marketing needs to hit numbers to satisfy the sales team’s quota. For developer marketing teams, that often times means living outside of the good graces of the broader revenue org. In this post I’m going to talk about a few ways to build an internal understanding of the importance of a dedicated developer database and why protecting the developer database is key.

Before we dive into it, if you don’t understand the developer buying journey, I would encourage you to check out the three-part series that I wrote on the developer buying journey last year. The series covers the developer buying journey, the role of open source and developer communities, and finally developers and BANT/the sales process. If you are new to dev marketing, it’s a great place to start.

Why building a developer database is important

It’s important to understand that enterprise sales is comprised of two main personas, decision makers and end users. When you look at how decision makers interact with a technical sales cycle, they tend to assume a cyclical relationship. They identify a need, they evaluate solutions, they make a purchasing decision, and after a predetermined amount of time they either renew that agreement or reevaluate their options. Developers on the other hand develop a more linear relationship with a product. As they use the product, their knowledge of the product increases, as does their knowledge of how that product or solution integrates with other solutions. For a developer, switching products can cost much more than the price of the product, it means losing major learnings that took time to build.

This is why the role of developer marketing can have such an incredible impact on customer retention and expansion, and why developer marketing teams focus so heavily on establishing programmatic elements vs marketing campaigns. For developer marketers, building a database that is engaged and healthy is the main way to ensure that the end users of your products are continually increasing their knowledge and affinity for your solution. This is in contrast to demand gen, growth, and field marketing objectives where the goal is to push contacts into a buying process. If the contact has already bought your product, they are no longer valuable unless you have another product to sell. To developers, most of the time this type of interaction is not appreciated. Developers evaluate products based on challenges and needs, if they don’t have a need for the product or are facing a challenge that the product can solve, pushing these solutions does more damage than good. Timing this process is almost impossible, that’s why developer marketing programs are so valuable. I find that it’s in the best interest for most companies to view developer marketing as a customer success function and not a demand gen function.

Creating organizational alignment

Developer marketing teams tend to be viewed as an enigma in most companies. They aren’t developers but they are technical and the good ones can code, they aren’t advocates but they behave like them, and they aren’t marketers but they use all of the marketing team’s tools. To make things even more complicated, some of the most successful dev marketing teams report through product teams and in some cases even have products that they manage. These differences are a fast track to organizational misalignments and misunderstanding. Though I’ve never achieved 100% internal alignment, I have found several ways to build a common understanding and appreciation.

The most important thing is to creating alignment, is defining who developers are. This includes job titles, levels, and technologies used. All too often companies group all technical roles into a ‘developer’ segment. The issue with this is that though all developers are technical, not all technical roles are developers. There are technical roles that can meet sales qualification criteria and who actively participate in the buying cycle. You see this a lot with IT roles, which is why tensions can build quickly. Generally, speaking your developer database should not contain contacts that would qualify as a lead in a sales funnel. If it does, it means that your targeting is either too broad or your developer titles might be too senior. The other thing that creates tension is if the targeting criteria is too narrow and developer contacts are being sent to sales and marketing as a qualified lead. Finding the perfect balance takes time, but the effort is well worth the wait. It’s important to meet regularly with sales and marketing to refine your process, and keep an eye on the contacts who are being passed off as a lead. Unsubscribe and click-through-rates are a valuable early indicator of how your segmentation is working.

The second way to create alignment is to educate and advocate internally about the impact that developers play in the buying process. Most people understand that developers don’t have budget to spend or the authority to make a purchasing decision, but they don’t understand the influence that developers have on a sale. It’s important to build an understanding of the impact that poorly targeted or overly aggressive marketing and sales campaigns can have a developer’s affinity towards your company. With so many options on the market, developers can be picky about which solutions they use, and believe me, they are …