// Developer experience: prerequisite and product of DevRel

I’ve written before about how DevRel creates value and what that looks like in practice, and why DevRel is better understood as value co-creation than as marketing. My second post described Developer Experience (DX) as the “value-in-use” dimension of value co-creation: the value a developer actually experiences when using the product. This post picks up from there and focuses on developer experience specifically: what it actually means, why it sits at the centre of DevRel strategy, and the nuance I think most writing on DevRel misses.

I believe that developer experience shouldn’t just be “one of the things” DevRel teams care about, but the central thing that DevRel focuses on. In their book Developer Relations, Caroline Lewko and James Parton are among the few authors to position Developer Experience at the centre of DevRel activity, with education, success, marketing, and programmes contributing towards it. That’s the same framework we explored in my last post, and it lines up well with Matthew Revell’s “What is developer relations?” guide, which frames DevRel as a strategic mix of adoption, enablement, ecosystem, and product feedback rather than just a tactical content engine.

Every one of the 13 leaders I spoke with came back to developer experience as central to their work. Many of them treated it as a proxy for product adoption throughout their interviews. When leaders with direct DevRel experience keep returning to the same point, that tells you something.

As a reminder, my sample skewed towards technology companies and more established DevRel teams, so this isn’t a universal claim about every DevRel function. Even so, the conversations surfaced something that most writing on DevRel doesn’t really tackle which I think has implications for how we structure DevRel strategy.

Chris, doesn’t that consistency across all 13 participants just mean you spoke to people who already see DevRel this way?

That’s a fair challenge. The point of this research wasn’t to run a survey and pretend it speaks for every DevRel team everywhere. It was to go deep with practitioners who live these challenges day-in, day-out and understand how the work actually plays out. And what stood out wasn’t just that they landed in a similar place. It was that they got there for slightly different reasons. That’s a meaningful pattern.

What is developer experience, and why does it matter?

Before we get to the nuance, let’s be clear on what I mean by Developer Experience. In a nutshell, it’s the quality of the journey developers have with your product.

When I break that phrase down, I mean:

• Developer: the person who interacts with your product, and whose experience you’re trying to shape.
• Experience: the quality of the journey they have when they interact with your product, and the associations they form with it.
• Relations: the team that builds relationships with those developers, and the activities they do to support them in their journey.

Put together, Developer Experience in the context of DevRel is about the quality of the journey developers have when discovering, evaluating, learning, building with, and scaling your technology. It’s not just documentation quality, though that’s an incredibly visible part of it. (For example Stack Overflow’s 2024 Developer Survey found that API and SDK docs were the documentation source of choice for 90% of developers). Developer experience is the sum of everything a developer encounters when they interact with your product. It’s the coherence of the experience across different parts of the platform. It’s the clarity of the onboarding path and how easy it is to get from “I want to try this” to “I’ve built something useful”. And overall, it’s how supported developers feel when they run into obstacles. Stephen O’Grady’s The Developer Experience Gap is useful here because it makes the same point from another angle: developers now work across fragmented toolchains and services, so the burden of stitching everything together often falls back on them unless someone has deliberately designed the experience to feel coherent. One participant described their role succinctly:

It’s about relieving friction along the developer journey. If we release something new and don’t support its content, that’s friction. They come and try to do it, and the contents are not there. That’s friction. Is something broken or incorrect in the documentation? That’s friction. Well, that’s really what it’s about. What journeys do we care about, how much friction is there, and how do we eliminate it?

Another put it from the developer’s perspective:

We want our users to feel powerful and empowered. Like they’re supported and getting the answers to what they want without having to run around for it.

And a third described what good DX produces:

We ensure the journey through all the different parts of our platform and ecosystem feels cohesive. That inter-product friction is really where we shine.

These aren’t descriptions of a single metric or a single programme. They’re all describing the same thing: the quality of the end-to-end journey a developer has with your product. And that’s exactly why developer experience sits at the centre of everything for DevRel.

Developer experience is the centre of gravity for DevRel. The quality of that developer’s journey is ultimately what determines whether they adopt your product, advocate for it, and build a relationship with your community.

Developer experience and product adoption: the flywheel

The most direct way to understand why developer experience sits at the centre of everything is to trace the path to product adoption.

Across all 13 conversations, one thing was consistent: they were all trying to help developers get to value with the product and keep using it. The path to product adoption runs, consistently, through developer experience.

A poor developer experience means developers struggle to evaluate your product, fail to reach value in a reasonable timeframe, or become frustrated by friction in the build phase. None of those things produce adoption. A strong developer experience means developers can progress through their journey efficiently, reach genuine value, and crucially, form the positive association with the technology that turns them into advocates. That’s the seed of advocacy, and it belongs to the whole DevRel organisation, not just those with a “Developer Advocate” title.

As one participant explained from their own internal data and experience:

About 38% of our alumni and community members have introduced technology they learned at a hackathon into production at work. That might take a year or two. But they remember what they used, and that is incredibly sticky.

That stickiness is where the developer experience leaves a lasting positive impression. And when it creates advocates, those advocates spread through peer recommendation and community presence acting as a flywheel that DevRel teams can build and cultivate over time. That spirit of giving back (recommending tools that genuinely helped you, sharing what worked with the next developer who asks) is how the best DevRel flywheels operate. They’re grounded in authentic value-in-use and positive associations with the product, which is what a good developer experience creates.

One participant put it in terms of what the onboarding stakes actually are:

You must have a developer experience that enables people to onboard effectively and not lose all your developers because it’s too hard to get started.

Another participant described the case for onboarding investment this way:

Many people ask me, why do you focus so much on onboarding? […] The goal is that everyone should be doing the word-of-mouth thing — ‘Go build on […], you’re missing out if you’re not’. When these people land, it’s very important that their experience not only be good but delightful.

The nuance: does DevRel depend on developer experience, or shape it?

With that, here’s the nuance from my research that I think most DevRel writing underplays. Developer experience is both a starting condition for DevRel’s work and an ongoing product of it. I know that sounds a bit paradoxical, so let’s explore it.

Think of developer experience as a prerequisite that DevRel depends on, and simultaneously as something your team actively shapes. Both are true at once, and that changes how you structure your team’s work. Put simply, value isn’t something you deliver to a developer once. It’s realised through their ongoing interaction with the product, and shaped by everyone involved in that journey. Vargo and Lusch’s service-dominant logic is a useful academic reference for that idea.

• As a prerequisite, developer experience sets a floor. If the product has a fundamentally poor developer experience (hard to use, badly documented, or unreliable), DevRel cannot overcome that through great content and enthusiastic community engagement. The developer experience has to be good enough for DevRel’s activities to have traction. There’s a version of DevRel that treats developer experience as someone else’s problem (where the team focuses on content, events, and community, assuming the product will hold up once developers arrive). When the developer experience is genuinely broken, that assumption fails. The content brings developers in; the developer experience sends them away.
• As something DevRel actively shapes, developer experience changes over time through the team’s work. Education content reduces friction by filling gaps the documentation missed. Developer success initiatives help community members navigate difficult transitions in their journey. Community conversations carry developer observations about rough edges back to the product team. All of these activities improve the developer experience which then creates better conditions for further DevRel work.

As one participant put it:

I’d probably fight for a good developer experience more than anything else. The feature might be available, but how can we make it more intuitive? How can we get them to where they need to be sooner?

That might sound subtle, but it matters a great deal in practice. It means that DevRel needs to do two things when it comes to developer experience:

1. Monitor and advocate for the baseline developer experience quality by making sure the product team hears from the community about friction points, and making sure developer experience prerequisites are in place before investing heavily in programmes that depend on them.
2. Actively improve the developer experience through their work by not waiting for the product team to solve every experience gap, but treating content, community, and programmes as levers for reducing the friction developers experience.

“Developer Experience audits”: making the gap visible

With that dual role established, one practice that emerged from the interviews deserves some attention because it addresses both aspects. Several participants described what they called developer experience audits:

[…] We also do developer experience audits where the team embodies a user and identifies where they hit friction

In practice, it means DevRel teams put themselves through the real first-time-user journey: discovery, evaluation, onboarding, and building. They identify friction points where the journey breaks down, documentation is missing or confusing, or where the expected path doesn’t match the actual path. A lot of friction never surfaces in a support ticket, it just stays invisible. That’s exactly what makes these audits more useful than general feedback. As another participant put it:

It’s different to watch someone looking for a button in your dashboard. That might be an annoying experience, but they never file a support ticket because it wasn’t an error. But it’s not good either.

Friction is often silent. The developer experience audit is what makes it audible.

This practice has been written up more formally in other corners of the industry. For example, the DevRel Agency have written about developer experience audits from a product adoption perspective, and Apollo GraphQL have published their own developer experience audit framework. It also looks less niche than it used to. The State of DevRel 2024 report found that teams who never conduct developer experience audits fell from 44.2% to 31.2%, suggesting this is becoming a more standard practice. What struck me was that participants organically described doing this, without me prompting for it in the interviews.

When I think about the “silent friction” and the power of developer experience audits to surface it, I often think back to some wise words from a previous manager. Every engineer and product manager goes to work trying to make their product the best it can be. But they are rarely experiencing it for the first time, or looking at it holistically (integrating across a platform with other toolchains). A developer onboarding fresh does not have that context, and that gap stays hidden unless someone deliberately goes looking for it. That’s our job.

And this is why I think the developer experience audit is such a powerful practice. It gives the team a shared, concrete perspective on the actual user journey, and surfaces friction that might otherwise be invisible to the product team. I’m a firm believer that everything should have a URL, particularly around making work visible and creating shared understanding across teams. The developer experience audit is another example of that, because it creates a shared artefact that the product team can see and understand, rather than just hearing about “some friction” in a general sense. It turns what developers are actually experiencing into something tangible that product and engineering teams can see and act on.

These audits also create artefacts that DevRel teams can use in stakeholder conversations to demonstrate the value of their product insight role. As one participant described it:

We don’t just evangelise to developers; we advocate for them in our organisation.

When that advocacy is backed by specific developer experience audit findings, it becomes much more persuasive.

DevRel’s invisible contribution to developer experience

One of the most easily overlooked challenges in communicating DevRel’s contribution to developer experience is that much of it is invisible.

The direct outputs (blog posts, talks, videos, programs, etc.) are easy to see and count. But the developer experience improvements that result from DevRel’s advocacy and feedback are harder to attribute. The documentation that got rewritten because a developer advocate noticed a gap doesn’t often come with a “DevRel improved this” label. The onboarding flow that was simplified after the team brought community feedback to the product conversation is just listed as a product improvement.

I’ve experienced this myself; the visible work is easy to point at. However, the friction that gets removed behind the scenes, the feedback that gets passed to the product team, and the advocacy that leads to experience improvements often disappears into the product. It’s almost as if it just happened, without a clear line back to DevRel’s contribution. That makes it harder to communicate the value of that work to stakeholders, and can lead to an underappreciation of DevRel’s role in shaping that experience.

Several participants described this visibility challenge explicitly. One noted:

[Senior stakeholders] see us as a content generation machine or a marketing machine, missing the developer experience aspect.

This is worth thinking about carefully when you’re designing how your team communicates its work. The visible outputs (content, events, community) are the things stakeholders tend to see. The invisible contributions to developer experience (product feedback, experience advocacy, friction identification) are often where DevRel’s most durable impact lives.

Making that invisible work visible is partly a communication challenge and partly a systems challenge. It requires DevRel teams to track and report their developer experience contributions explicitly, not just their content and community outputs.

Developer experience friction is also a market problem

But the issue doesn’t stop at internal visibility. There are two risks at once. Internally, DevRel’s contribution to developer experience can go unrecognised or undervalued because so much of the impact disappears into the product. Externally, the underlying developer experience friction is still very real, and broader industry data reinforces that.

Postman’s State of the API 2025 found that 93% of API teams still face collaboration blockers, 55% struggle with inconsistent documentation, and 34% cannot find existing APIs. Stack Overflow’s 2025 Developer Survey adds the developer perspective: poor usability, inefficient or time-costly experiences, and sub-par APIs are all among the reasons developers lose interest in technology.

O’Grady’s more recent AI Tooling, Evolution and The Promiscuity of Modern Developers helps frame why this matters right now: developers are increasingly willing to experiment with alternatives and switch tools when something better appears. In the kind of competitive market that AI has accelerated, developer experience stops being a nice-to-have and becomes one of your clearest differentiators. Taken together, that means this is not only a visibility problem for DevRel teams. It is also a real market problem, because the friction DevRel helps surface and reduce is exactly the kind that now pushes developers away.

And this is where the argument comes back to DevRel as a discipline, because reducing friction is only half the problem; teams also have to show that this work matters. The State of DevRel 2024 report found that proving impact with data and metrics remained the top challenge for Developer Relations at 60.7%, while proving the business impact of DevRel rose to 28.5% among program-level challenges. It also found that 63% of respondents showed high interest in a non-profit, open collaboration effort to standardise and professionalise DevRel, which hints this is now an industry-wide concern rather than a team-by-team frustration. It’s been a recurring theme in industry discussions for years; Kurtis Kemple’s systems thinking and invisible work in DevRel is a thoughtful exploration of how to bring that invisible work out into the open if you want a practical framework for it.

What this means for your DevRel strategy

If we frame developer experience from both an antecedent (pre-requisite) and consequence (result) point of view, a few practical implications follow:

1. First, assess developer experience prerequisites before investing heavily in programs. If the onboarding experience is fundamentally broken, the highest-value investment may be fixing that, not creating more tutorial content or building a new ambassador program. Great DevRel amplifies a good developer experience; it doesn’t substitute for a poor one.
2. Second, treat developer experience improvement as a core DevRel activity, not a side effect. DevRel teams that see their role as producing content are missing half the picture. Their product advocacy and feedback work (prioritisation sessions with product teams, developer experience audits, ongoing product feedback) are as central to their value as anything they publish.
3. Third, measure developer experience outcomes alongside the content and community activities you’re already tracking. “Can they reach value within a certain amount of time?” (as one participant framed the goal for every developer who lands) is a better question than “how many views did our tutorial get?” Both matter. But the developer experience outcome tells us more clearly whether DevRel is helping developers reach value and stick with the product.

Equally, don’t wait until your developer experience is perfect before investing in the community. The developer experience audit practice exists because you can identify and address friction at any stage. Instead of asking “is our developer experience good enough?”, ask “do we know where the friction is, and are we actively working to reduce it?”

Up next in this series is “The four pillars of DevRel and the foundation they rest on”. We’ll explore the four main areas of DevRel work, how they connect and reinforce each other, and the foundational piece that most writing on DevRel quietly overlooks. If you want the broader context in the meantime, you can follow the wider Strategic Case for Developer Relations series.

As with my other posts, if this resonated, I’d love to continue the conversation. Comment on the public BlueSky thread below, or drop me a DM on LinkedIn. Until the next one, bye for now!