// The feedback loop: how DevRel bridges community and product

There’s a phrase you likely hear in DevRel and developer-focused companies: “voice of the developer.”

It captures something real, but I think it’s too small for the job many teams are doing in reality. I’ve been in product meetings where “the community wants X” landed with a thud, because nobody in the room knew which developers that meant or what they were actually stuck on. Product teams need patterns, examples, and enough context to decide what should change.

Disclaimer: (Though you already know this if you’ve been following on my blog series already!) These reflections come from 13 interviews I ran for my MBA dissertation. Most of the people I spoke to were in technology companies, so I’m not claiming this is true across industries that work with developers in an adjacent context. However, I do think they are a useful description of how strong DevRel teams operate.

Chris, isn’t this just another way of saying DevRel passes feedback to product?

Not quite. Passing feedback on is part of it. The stronger pattern in the interviews was that DevRel often helps product teams hear, interpret, prioritise and respond to what developers are actually running into. That is a broader job that matters more than you might think on first glance. One participant explained the inward advocacy part of the job like this:

I’ve had cases where the organisation identified a goal, but it’s not resonating with the community. And so, part of Developer Relations is to bring that feedback inside the house and say nobody cares. Here’s how they are using the product, and maybe we should tweak our goals to have that market fit.

That job runs in two directions:

• DevRel advocates inward (taking developer experience and community patterns into product decisions)
• DevRel advocates outward (going back to developers to show what changed and why).

Both matter. Most discussions of DevRel stop at the first direction and forget the second; they don’t close the loop by showing developers that their feedback led somewhere. That is a missed opportunity, because it is the second part that builds trust, keeps people engaged, and encourages more sharing in the future.

DevRel as a primary conduit

While Developer Relations are often not in the product org, they are a primary conduit to the end user.

That subtlety matters: a primary conduit, not the only conduit. Product teams hear things from support, sales, telemetry, customer calls and many other sources. But DevRel often sees a different slice of reality: the questions developers ask before they file a ticket, the friction they work around without reporting it, and the repeated patterns that only show up when you are close to a community over time.

That is why I think the “voice of the developer” phrase undersells the job. It makes DevRel sound like a team that turns up to a meeting, repeats what it heard, and leaves. In practice, the better teams are doing something more active. They are helping the product team see what the community is experiencing, why it matters, and what kind of response is likely to help.

What makes DevRel feedback representative

Not all feedback deserves the same weight. One of the more useful ideas in the interviews was the need for representative feedback rather than simply loud feedback.

One participant made the point like this:

If you’ve got multiple community members talking about certain things, it will be important for the rest of your users.

That sounds simple, but it is a disciplined way of working. The loudest people in a community are often the most engaged, the earliest adopters, or the developers with enough confidence to speak up often. They matter, but they are not the whole community. As I argued in the earlier post on company context and lifecycle, developers sit at different points on the adoption curve. The people who happily experiment early are not always the same people who need reassurance, clarity, and proof before they adopt.

Another participant described that shift very directly:

We would take anybody because we needed feedback on the product. They were great for helping us get started and giving us feedback, but they didn’t develop much real business value. Part of the reason is that the business was evolving into an enterprise SaaS business, and enterprises have a very different set of expectations and requirements.

So the job is not just to collect comments and opinions. It is to look for patterns across different developers, different channels and different moments in the journey. On that point, this is where DevRel can be incredibly valuable. A product team can react to one loud complaint. A strong DevRel team can tell you whether that complaint is an outlier, the first sign of a wider problem, or the beginning of a shift in the community. That framing changes the decision.

Following up in DevRel: the step teams skip

One of the sharpest rhetorical questions in the interviews was this:

How often does that feedback influence the product and result in changes? How often do we return to developers and say we have done what you asked us?

The last part is what many teams skip. Gathering feedback and taking it into product conversations matters. But going back to the developers who raised the issue matters just as much. When people can see that their input changed something, they keep engaging. They keep sharing what they are running into, which can lead to them helping other developers, sharing workarounds and giving back to the wider community. That is how trust grows. That is how communities keep learning out in the open.

One participant described using an online system where developers could submit suggestions or bug reports and track progress. I like that because it turns “we heard you” from a vague reassurance into something developers can actually see. A small change, but a meaningful one. The risk however is that if you don’t follow up, you end up with a lot of “we heard you” promises that never go anywhere which I think is worse than not saying anything at all.

Stateshift’s recent piece on the future of DevRel reflects some of these thoughts as well. It argues that community forums are shifting away from basic transactional support towards experience sharing, trade-offs, and implementation discussion. I think that makes the follow-up problem even more important. If AI can help us to answer more routine questions (like scouring docs for the low-hanging fruit), the human value in DevRel communities sits even more in context, response, and visible learning. Developers do not just want an answer; they want to know whether someone did something with what they said.

Spidey sense and the limits of data

There is another part of feedback work that is harder to measure, but no less real.

So, we’ll do stuff where telemetry doesn’t indicate a problem, but our Spidey sense does.

I love that line because it names something experienced practitioners recognise immediately. Sometimes the dashboard and the reported metrics look fine. But the conversations at an event, the pattern of questions in a forum, or the hesitation in a workshop tell you something different.

This is not magic. It comes from being close enough to a community to know what normal looks like, and to notice when that normal starts to move. Sometimes the first signal is not a chart. It is a feeling that the same confusion keeps showing up in different places.

That kind of judgment does not sit neatly on a content dashboard, but it matters - a lot. It might be one of the most useful things an experienced DevRel team can offer.

Developer experience audits as a DevRel feedback mechanism

In my previous post on Developer Experience, I wrote about developer experience audits. They matter here as well, because they turn general community frustration into something concrete. One participant described the value of this kind of observation very clearly:

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.

That is such an important distinction; a lot of friction never becomes a support case, it just becomes silent frustration.

Equally, this is why I think DX audits are so useful. They help teams step through the product like a new developer, identify the points where the journey gets messy, and bring specific evidence back to product. DevRel.Agency’s article on six common friction points in the developer journey makes that tangible: poor technical documentation, no clear developer portal, no official community space, unnecessary gates before access, weak GitHub repo descriptions, and trial periods that are too thin to prove value. None of those issues look dramatic in isolation, but together, they quietly stop adoption.

I also think that Stateshift’s DevRel ROI piece frames this well. It treats activation, friction logging, community participation, and product adoption as part of the same system. Better onboarding, fewer dead ends, and clearer feedback loops are not side quests. They are a core part of how we in DevRel improve the ecosystem around our product and help more developers get to value.

From my own personal experience, I’ve found that the conversation changes once you can point to the exact place where a developer gets stuck. You are no longer saying “the community is unhappy”, you are clarifying “here is where the experience breaks down, and here is why”. That framing lands much differently.

What the DevRel feedback loop delivers

When this works well, the outcomes are not vague. They are concrete.

1. Better product decisions: product teams get patterns, examples, and evidence rather than isolated complaints.
2. More trust from developers: people can see that feedback leads somewhere, so they stay engaged.
3. Stronger community participation: developers who feel heard are more likely to keep sharing, helping, and recommending.
4. Clearer business impact: the work influences roadmap choices, documentation investment, onboarding priorities, and adoption.

One participant put the business side of it bluntly:

We drive literal revenue and retention. Our feedback has been responsible for launching new teams and products like P0 projects picked up by our product org.

This is a reminder that DevRel’s strategic value is not limited to content performance or event attendance. We shape what gets built, how quickly friction is reduced, and whether developers stay long enough to become committed users.

When developers get help from each other, see changes reflected back, and keep sharing what they learn, the feedback loop improves the product and the ecosystem around it at the same time.

DevRel’s invisible work problem, revisited

This is the part I keep coming back to. The visible work in DevRel is easy to count: the blog posts, the talks, the videos, the events, the view numbers. The less visible work, product feedback, DX advocacy, follow-up, early pattern recognition, is where a lot of the strategic value sits.

One participant captured the problem well:

And so, they see us as a content generation machine or a marketing machine, and they’re missing the developer experience and product feedback aspects, which sometimes happens.

That still feels current to me. The State of DevRel 2024 report found that proving impact with data and metrics remained the top challenge for the duscuokube, cited by 60.7% of respondents. That broad level of feeling is consistent with what I heard in these interviews, and it is why I keep returning to this problem.

The DevRel.Agency piece on metrics that matter gives useful language for this. It separates program goals from activity metrics and community metrics, then asks two simple questions of every measure: “So what?” and “What do I adjust?”. I like that because it stops the conversation at the point where DevRel reporting can slip into “performance theatre”.

Now don’t get me wrong, a list of outputs is not enough. The measures that make this feedback loop legible are the ones that show whether developers reached value, whether community participation deepened, and whether product teams changed anything in response.

With that, I think the real challenge is not proving that this work matters. The challenge is making it legible and visible. Not just to internal stakeholders, but to the community as well. DevRel teams need a clear way to capture feedback, show what changed next, and talk about that work internally in language that internal stakeholders can understand. Otherwise, the work remains invisible or misunderstood, and the strategic value is lost.

How are you building that feedback loop in your DevRel work? How do you make it visible to both product teams and developers? I’d love to hear your thoughts over on BlueSky using the thread below. Alternatively, if you’d rather chat about this in private, you can find me on LinkedIn. In the next post on DevRel measurement, I’ll look at metrics more directly, specifically why only two of the 13 DevRel leaders I interviewed could clearly connect their tactical work to strategic outcomes, and what a model for measurement could look like.

Until the next one, bye for now!