What's the difference between Developer Relations and Developer Marketing? How do you work together?

Great question. We actually have a third unit – Developer Experience.

I'm sure it differs at other organizations, but at dbt Labs...

Developer Relations is focused on growing the community (measured by Slack members and weekly active projects in the open source product), building lasting relationships with members, enforcing community guidelines, elevating diverse and marginalized voices, and highlighting the contributing work of members around the world. They build trust.

Developer Experience is focused on creating content for developers that aid in their day-to-day work. Think playbooks, best practices, technical how-to guides etc. They create value by authoring self-serve educational materials, and encouraging developers to create and share their own. They accelerate engagement.

Developer Product Marketing both underpins and feeds off of the above work. DevPMM shapes messaging and overarching narrative, informs product roadmap, and even sets pricing and packaging for paid products. DevPMM works with the above two groups by ensuring the way we talk about product use and value is consistent with core messaging, and focuses on extending conversations on core topics in the form of blogs, interviews, and even long-form guides. We also learn a great deal more about our core personas from DevEx and DevRel. We build narrative consistency.

I tend to look at DevRel as a pretty unique role that's part CSM, part Marketing and part Pre-Sales. Developer Marketing is full-stack marketing around a technical product. To sum it up quickly, DevRel tends to have a great pulse on the developer community and how your current developer audience will feel about your launches or features. Dev Marketing tends to have a pulse on positioning, bill of materials, product management alignment, etc. So I tend to look for Dev Marketing to influence roadmap, build a product narrative / comms plan and execute GTM vs DevRel to engage the developer community, surface back real-time feedback and help developers that are building an integration to actually get it live. Think of it as DevRel is a little closer to the customer and a little later in the funnel than where Dev Marketing sits. 

I'd say Developer Marketing + Developer Relations = Developer GTM. You'll want to pair these two functions as much as possible, and the way I've always thought about it is that Dev Marketing structures and provides the overall air cover (awareness, channel and content strategy, program management, measurement) and Dev Rel parachutes in for the high-touch stuff: enablement, evangelization, content production. 

Dev Rel are the true subject matter experts, the most authentic voices behind your product who can speak and directly enable a developer and with whom she can relate. Ideally you reserve Dev Rel for high-touch engagements whether it's 1:1 clinics, meetups, or sessions where they present to your audience at conferences. 

Dev Marketing is then the orchestration layer. You figure out what the goals are with Dev Rel (broader organization too depending on your size) but then prioritize and build activites according to your developer marketing funnel, which is very similar to your typical marketing funnel for ToFU and MoFu but where BoFu is about driving adoption, and not necessarily sales. That last part is actually important. You're not going to be very successful if Dev Rel/Dev Marketing is being goaled on sales vs enablement and reach. That's why it's really critical that Dev Marketing be set up as a dedicated function whose job it is to support Dev Rel. 

I think it's important to discuss the objective of investing in marketing to developers before answering this question directly. At Twilio, the Developer Marketing team described their mission as 'inspiring and equipping today's developers to build the next generation of communications'. Their goal was to make Twilio APIs an integral part of the toolkit of any developers, regardless of whether they had an immediate need from them or not. The thesis (which prove to be spectacularly correct) was that if individual developers know and trust Twilio products and use them in their side projects or during hackathons at work, they would advocate for Twilio when it was time to sign an enterprise contract. Content and community participation was core to this strategy. Twilio was at every single developer event, whether large ones like PyCon and even smaller local events or those focused on upcoming languages and technologies. They churned out a steady stream of developer guides, blog posts and viral Twilio apps like the Santa phone.

With this objective in mind, I think Developer Relations can be thought of as a distinct function under Developer Marketing that focuses more on the community relations side. It involves building relationships with individual developers, especially those with influence in a certain language or technology, as well as managing your presence at relevant developer events. It can also include your social media presence as well as virtual events like Twitch or YouTube livestreams. Dev Rel works with the Developer Education function (responsible for developer guides, reference apps and other content) to distribute content to the right developer audiences. 

In my experience, most companies do not have this level of specialization until they are a lot bigger. It's usually the same people responsible for both Dev Rel and Dev Ed. However explicitly recongizing this distinction can help with specialization down the line.

DevRel and Dev Marketers are 2 sides of the same coin. Developer relations (or tech evangelists) are responsible for the truly technical content with the ultimate goal of building a developer community to market the product. Developer marketers partner with DevRel to distribute their content and drive funnel marketing goals. Examples:

DevRel:

• is go to for message testing and technical BS-ometer
• Distill technical differentiation into positioning statements, messaging, and value propositions that will be leveraged throughout sales and marketing
• Work with product management to distill key functionality and benefits into core product marketing messages, and create technical narratives that differentiate with technical users
• writes the long form SEO content, technical demos, technical talks
• create/execute a content strategy that encompasses strategic partner’s external sites as well as ours (video, technical documentation, use cases)
• co-develop marketing plan with strategic partner - what channels are we missing? what are cool use cases? What placements or integrations should we ask for in product?
• Assist in building partner pitches (with technical knowledge), Plan, produce, and maintain technical competitive intelligence and sales enablement tools and training.
• Provide competitive intelligence and enablement to the field
• Speaks at conferences and/or user groups - more technical use cases and thought leadership
• identifies speaking opportunities we should be in that scale
• Monitors & responds to Atlassian Community, HN, Reddit forums
• Channels customer usability feedback from the external community back to the internal teams to improve our products
• Be the translation layer between product and product marketing for technical concepts.
• Authors design/user guides, technical blog posts, how-to tutorials, builds demos and delivers high-quality training material, webinars, presentations, data sheets, technical white papers, web content, and reference architectures.
• Creates sandboxes and knows products deeply in order to inform technical content

Developer Marketing:

• writes the messaging
• distributes the content
• drives strategic partnerships: report on performance, decide on GTM iniatives
• Creates sales enablement (CIO/CTO/VP decks), battle cards
• creator of customer stories
• creator of landinag pages
• writes feature launch blogs
• driver of press/ analyst relations / conference stories
• demand gen
• PMM counterpart to a product squad
• PR/AR audience launch blog = pmm writes and technical pmm reviews.
• message house to inform landing page, activation emails
• Branding
• Executes on on-boarding strategy
• Onboarding: Develop, test, and implement onboarding programs to activate new users (activation emails)
• funnel optimization
• Pricing and packaging - Ability to use pricing as a strategic lever, ability to build the biz case and ability to sell the organization on the vision.
• Be the expert on all technical buyer personas, understanding their buying agendas and how they evaluate and buy.
• Speaks at conferences and/or user groups - product value presentations
• competitor analysis