Developer Relations Belongs in Product

The role of Developer Relations (DevRel) is still finding where it fits best in an org. DevRel can make a large impact working in multiple departments but this makes goal alignment difficult. While DevRel historically emerged from marketing departments, its true home lies within Product. Many others have said this, this is why I think they are right.

Developer Experience is Product-Centric

A developer has to choose one of many products that technically fit their need. The Developer Experience (DevEx) isn’t just about slick APIs or polished SDKs. It’s the sum of every interaction a developer has with your product above and beyond core features. Onboarding flows, error messages, documentation, and even community support are all direct extensions of the product itself. When DevRel sits within Product, it ensures that the developer’s journey is treated as a core part of the product strategy, not an afterthought.

Product Design Shapes Developer Experience

A well-designed product minimizes friction for developers. For example:

• A confusing API schema forces developers to waste time deciphering endpoints.
• Poorly designed SDKs lead to frustration and abandonment.
• Inconsistent versioning erodes trust.

DevRel teams embedded in Product can advocate for developer-centric design decisions early in the development cycle. They act as the voice of the end-user, ensuring that the product is built with empathy for that developer struggling to get it.

Why Marketing KPIs Conflict with Developer Success

DevRel was born in marketing because developers were seen as a “hard-to-reach” audience. Traditional marketing tactics like lead generation, conversion rates, and click-through metrics don’t directly translate to developer finding success. Developer reaction to marketing can range from apathy to disdain and depending on the measures taken can erode the developers trust that the product has their needs in mind.

DevRel’s primary mission is to build trust and empower developers which is fundamentally misaligned with marketing’s focus on acquisition and growth. When DevRel reports to Marketing, it risks becoming a lead-gen tool rather than a champion for developers.

Documentation: Written by DevRel; Guided by Engineers

In the race to keep up with product improvements and user demands, DevRel and the Technical Writers within the team are the drivers of good documentation with Product Engineers navigating. Engineers are experts at building products, not explaining them. It is hard for an engineer deep in technical understanding to look at their own product from the eyes of the end user. Not to mention the soft skills needed and the time it takes to write good docs. Documentation requires a different skill set: clarity, empathy, and an understanding of diverse user personas. Technical writers on a DevRel team should own documentation. When documentation lives under DevRel (which itself aligns with Product), it becomes a living resource that evolves with the product.

DevRel’s Role: Guiding Developers to the Right Resources

DevRel’s primary goal is to guide developers to success, entertaining, generating leads, etc are importent but secondary.

• Creating tutorials and demos that highlight key features.
• Directing developers to relevant documentation.
• Acting as a feedback loop between users and Product.

When DevRel and Product share goals, incentives align. For example, a Product team focused on adoption will prioritize features that solve real problems, while DevRel ensures developers can easily find and understand those features.

Marketing vs. DevRel: Entertainment vs. Information

• Marketing’s Role: Entertain, engage, and attract. Think viral tweets, swag, and event sponsorships.
• DevRel’s Role: Inform, educate, and retain. Think in-depth workshops, troubleshooting guides, and API deep dives.

Marketing creates the first impression; DevRel ensures the second, third, and hundredth interactions are meaningful. Imagine Marketing as a matchmaker and DevRel as the wingman: Marketing gets developers in the door, but DevRel ensures they stay.

The Path Forward: Integrate DevRel with Product

To maximize developer success:

1. Move DevRel under Product and align incentives with developer outcomes.
2. Empower technical writers as first-class stakeholders in product development.
3. Treat documentation as a core product feature, not a support artifact.
4. Celebrate the onboarding experience making it just has memorable as the first impression.

When DevRel and Product work in lockstep, developers win and so does your product.