diff --git a/src/content/blog/technical/developer-relations-docs-feedback-loop.mdx b/src/content/blog/technical/developer-relations-docs-feedback-loop.mdx
new file mode 100644
index 000000000..164268235
--- /dev/null
+++ b/src/content/blog/technical/developer-relations-docs-feedback-loop.mdx
@@ -0,0 +1,69 @@
+---
+title: 'The Feedback Loop Missing from Most Developer Relations Docs'
+subtitle: Published July 2026
+description: >-
+  Most DevRel teams treat documentation as a publishing problem. The harder problem is what documentation reveals about where developers actually fail.
+date: '2026-07-27T00:00:00.000Z'
+author: Frances
+tag: Technical
+section: Use Cases
+hidden: false
+---
+import BlogNewsletterCTA from '@components/site/BlogNewsletterCTA.astro';
+import BlogRequestDemo from '@components/site/BlogRequestDemo.astro';
+
+A developer searches your docs for "rate limit exceeded." No results. They try "429 error." Nothing. They open your community Slack and ask. Someone answers six hours later.
+
+Your documentation platform logged that search query. Your docs analytics show a high-exit page on the error reference. Your Slack has the thread now. None of it made it back into a documentation review queue.
+
+That's the gap most developer relations docs have: not missing content, but missing feedback loops.
+
+## The conventional approach and its limit
+
+Most DevRel teams treat documentation as a publishing problem. The questions are: what to write, how to structure it, where to host it, who should review before it ships.
+
+These are real problems. But they're upstream of the harder one: what happens after documentation is published?
+
+[Postman's 2024 State of the API report](https://www.postman.com/state-of-api/2024) found that 44% of developers still dig through source code to understand APIs because documentation is insufficient. That number doesn't mean documentation was never written. It means developers encountered it and it didn't answer their question. Another 39% cite inconsistent documentation as the single biggest barrier to API collaboration.
+
+The developers who search your docs and find nothing are sending you a product signal. Most DevRel teams aren't receiving it.
+
+## What documentation reveals
+
+Every documentation surface generates signals. Most teams aren't reading them systematically.
+
+**Search queries with no results** show where developers expected to find something and couldn't. A query for "rate limit exceeded" with no results means a developer hit an error your docs don't address. The query is a content brief. Teams that review these regularly find they surface a predictable category of missing content: error handling and edge cases.
+
+**High-exit pages** show where developers gave up. A developer who bounces from step two of your quickstart after 45 seconds did not successfully onboard. A page with a high exit rate and short dwell time means the content didn't resolve the problem it was supposed to resolve.
+
+**Community questions** are the most explicit signal. When developers ask the same question in your forum, Discord, or GitHub Issues, they're telling you in their own words what your documentation failed to explain. Twilio's DevRel team has credited this approach publicly: community feedback drove documentation improvements that led to new API creation, because recurring questions revealed a use case the product hadn't yet addressed.
+
+**Support tickets** carry similar signal. When a ticket is about something your documentation should cover, it is documentation debt with a human cost on both sides.
+
+None of this is new information. What's missing is the operational loop that routes these signals to the people who can act on them.
+
+<BlogNewsletterCTA />
+
+## Why the loop stays open
+
+The signal data exists. DevRel teams have access to search logs, docs analytics, and community channels. The reason it doesn't close is that no one owns the connection between those channels and the documentation queue.
+
+Documentation decisions and community observation usually sit with different people. A developer advocate who hears a recurring question in Discord is not always the person who can update the docs. A technical writer who owns the documentation platform is not always watching community channels. Without a defined handoff, the information stays siloed and documentation strategy stays driven by internal assumptions about what developers need.
+
+This shows up in how DevRel teams measure their work. [Proving documentation ROI](https://promptless.ai/blog/technical/developer-documentation-roi) is one of the harder DevRel problems, and part of the reason is that most teams measure documentation output (pages published, tutorials created) rather than documentation outcomes (search success rate, support ticket deflection). The feedback loop is what makes outcome measurement possible, because you can only track whether documentation worked if you're watching for cases where it didn't.
+
+## Building the loop operationally
+
+A working documentation feedback loop needs three components.
+
+**Signal collection.** Designate someone to review documentation search logs weekly, flag pages with high exit rates from your analytics, and compile community questions by category. Most DevRel teams already have access to this data. The gap is formalizing the review.
+
+**Routing.** Create a lightweight process for moving signals into a documentation queue. A GitHub issue labeled "docs-gap" with the search query that surfaced it is enough. The goal is getting information out of community channels and into a system where it can be prioritized and assigned.
+
+**Prioritization by traffic impact.** When gaps are identified, prioritize based on the number of developers affected. A missing error code explanation searched 200 times a week ranks above a detailed architecture explainer with 30 monthly views. Documentation debt that affects the [highest-traffic paths](https://promptless.ai/blog/technical/documentation-debt-accrues-where-your-team-cant-see-it) compounds fastest.
+
+The teams that do this well find the loop running in both directions. Signals about documentation gaps feed the writing queue. Recurring questions about undocumented behavior feed the product roadmap. Documentation becomes a listening instrument alongside its function as a publishing channel.
+
+Getting signal collection right is the hard part. The sources exist: search logs, analytics, community channels, support queues. The operational work is connecting them into a system that routes signals to the right people before developers have already moved on.
+
+<BlogRequestDemo />