Introducing EarShots: Developer Signal for Technical Go-to-Market Teams
Takeaways
- Start from the conversation, not the dashboard. A question, a bug report and a tool comparison each need a different owner and a different response.
- Ground every factual reply in your own documentation. If no page supports the answer, fix the documentation before you reply.
- Track AI search answers like you track mentions. Check which prompts name your product, which competitors appear instead and which pages the engines cite.
- Treat a complaint as a report to investigate. One public post does not confirm a defect or its cause.
- Push signal into the tools your team already uses. The REST API, signed webhooks, MCP server and CLI expose the same workspace data the app shows.
- Approval is not sending. Post the reviewed reply in its original thread, then mark it sent in EarShots.
EarShots listens to public developer conversations and AI search answers about your product. Its agent, Ears, sorts what it finds into Questions, Friction, Buying signals and Praise, then drafts replies and content grounded in your documentation. A person approves every draft and sends it from the original thread. EarShots never posts for you.
What EarShots does
EarShots connects two places where developers form opinions about your product: community threads and AI answers.
On the community side, it reads GitHub, Reddit, X, LinkedIn and the wider web for posts about your product and your competitors. Posts from your own team, similarly named products and unrelated roundups are filtered out of customer feedback.
On the AI search side, it tracks the prompts your buyers ask ChatGPT, Gemini, Google AI Overviews and Claude. For each prompt you can see whether your product is mentioned, whether your pages are cited and which domains are cited instead.
Who uses it and what they get
| Team | Where they work in EarShots | What they get |
|---|---|---|
| Developer relations | Mentions and the reply queue | Unanswered questions found early, with reply drafts that cite your docs. |
| Product and engineering | Context Buzz and Friction | Recurring errors and blockers grouped by topic, each linked to the posts behind it. |
| Product marketing | Competitor Signal and AI search reports | Where competitors win praise or complaints, and which prompts name them instead of you. |
| Content and docs | Campaign Engine and Ground Truth Review | Briefs, comparisons and FAQs checked against your sources, plus claims in articles verified or flagged. |
| Support and solutions | Mentions and Create ticket | Public bug reports turned into tickets with the original post and context attached. |
| Platform and automation | REST API, webhooks, MCP server and CLI | Workspace data in your own pipelines, Slack, issue trackers and coding agents. |
Reply with evidence
Each reply draft cites the documentation it relies on. Before approving, check that the cited passage applies to the person asking: the plan they're on, the version they run and any limits that matter.
Reply drafting covers X, LinkedIn and Reddit. For other channels, EarShots gives you the original post and a way to create a ticket instead.
Check claims about your product
Ground Truth Review compares factual claims in articles and AI answers with your company pages and technical documentation. A claim with supporting evidence is marked as such. A claim with no evidence is marked "Not enough to judge." Missing evidence does not make a claim false, and EarShots never calls it accurate.
Turn prompts into content
The Campaign Engine works from a single AI search prompt. It builds a strategy brief first, then optional pieces like comparison articles and FAQs, one step at a time. Each piece is reviewed against your documentation before you can approve it. If no source supports the content, generation stops and asks you to add documentation.
Use it from your own tools
The app is one way in. The others expose the same workspace and the same permissions:
- The REST API uses workspace API keys with scoped permissions and expiry.
- Webhooks send signed, metadata-only events to receivers you trust.
- The MCP server lets coding agents read workspace data and save drafts.
- The CLI runs reads and draft workflows from a terminal.
None of these can send a reply or publish content. They read data and prepare drafts for review.
A note from me
I've spent more than 15 years in marketing and growth, and I've worked in AI Search since 2019. Most recently, I was a Developer Relations Engineer at Google Labs, where I led growth for Jules and worked on the Situationally Aware Agents project. Before that, I ran growth for AthenaHQ.ai, one of the leading AEO/GEO platforms, was interim CMO and Head of Growth at HockeyStack, and led social, search and product-led growth across v0.app at Vercel. The conversations that mattered most were always the ones we found too late. A good question sat unanswered for a week. A competitor got recommended in a thread we never saw. I started EarShots.Dev so teams hear those conversations while they still matter, and answer them with facts. If you want to see it on your own product, book a demo.
David Zeledon, Founder and CEO
Try it on one conversation
Add your product, your competitors and your documentation. Pick one recent conversation, read the original post and decide whether it needs a reply, a ticket or nothing. If you draft a reply, check its citations before you send it.
Sign up for EarShots or [request a demo](/).