Every PM at a developer tools company faces the same problem: feedback comes in faster than you can process it. GitHub issues, Discord threads, support tickets, docs comments — each channel tells a different part of the story. Reading them individually misses the pattern. Skimming misses the signal.
This agent ingests raw text from multiple sources, clusters it into themes, scores each theme by signal strength, and outputs a structured PM brief you can act on.
Built to model how I'd approach systematic developer feedback analysis at Anthropic, OpenAI, Supabase, Vercel, or Stripe.
Paste raw text from up to four sources: GitHub issues, Discord/Slack, support tickets, docs comments. Hit "Generate PM Brief."
The agent returns:
- Themes clustered from across all sources (3-8 themes, more suggests they're not distinct enough)
- Category per theme: bug, feature request, docs gap, or workflow friction
- Signal strength score per theme, weighted by frequency, sentiment, and urgency
- Representative quotes pulled directly from the input
- Suggested action for each theme — specific, not generic
- Top 5 themes by signal strength
- Recommended priority order with rationale
- Open questions you'd need to investigate before committing to a roadmap
- Caveat flagging the most significant limitation of the analysis given the data
Why four categories?
Bugs, feature requests, docs gaps, and workflow friction require completely different responses. A bug has a clear owner and a clear fix. A feature request requires scoping and tradeoff analysis. A docs gap is often cheaper to fix than it looks — and the root cause is usually underestimated user confusion, not missing content. Workflow friction is the hardest because users don't ask for it to be fixed; they just quietly churn.
Conflating these categories leads to the wrong prioritization. A team that treats "I can't figure out how to do X" as a feature request when it's actually a docs gap will spend 3 months building the wrong thing.
What signal strength means
Signal strength is not just frequency. A single ticket from a high-value enterprise customer describing a critical blocker should outrank five low-stakes comments about button color. The scoring model:
signal_strength = (frequency * 2) + sentiment_score + recency_boost
- Frequency is weighted 2x because pattern matters more than any single data point
- Sentiment score (1-5) reflects how urgent or frustrated the language is — "this is broken" scores higher than "would be nice"
- Recency boost gives a small advantage to newer feedback, reflecting that developer workflows and expectations change fast
The maximum score is ~100. A score above 70 typically indicates a critical issue worth addressing in the next sprint. Below 40 usually means "monitor but don't act yet."
Why open questions matter
Most feedback analyses end with a ranked list of themes. That's useful but incomplete. The open questions section surfaces what you'd need to investigate before making a confident decision — user segment breakdowns, root cause investigations, quantitative data to validate the qualitative signal. A PM who acts on qualitative feedback without checking the open questions tends to build for the loudest users, not the most important ones.
User input (pasted text, 1-4 sources)
│
▼
Next.js UI
(tab per source,
paste free text)
│
▼
POST /api/analyze
(Next.js route handler,
server-side)
│
▼
Anthropic API
claude-sonnet-4-20250514
│
▼
Structured JSON response
(themes, priorities,
open questions, caveat)
│
▼
Rendered PM brief
(theme cards, signal bars,
priority list, questions)
The API key stays server-side. The frontend never touches it.
Input text is sent in a single prompt with source labels preserved. The model clusters across sources rather than treating each separately — this is important for finding patterns that only appear when you look across channels.
git clone https://github.com/AnjanaG/developer-feedback-agent.git
cd developer-feedback-agent
npm install
cp .env.example .env.local
# Add your Anthropic API key to .env.local
npm run devOpen http://localhost:3000.
Get an Anthropic API key at console.anthropic.com.
Current limitations:
- No persistent storage. Each session is stateless — you can't compare briefs over time or track theme resolution.
- Source credibility is treated as equal. A power user's detailed GitHub issue and a one-line Discord comment contribute equally to frequency counts.
- Recency weighting is approximate — the model doesn't know actual timestamps unless they appear in the pasted text.
- No deduplication across sources. The same complaint in three channels will inflate frequency.
What a production version needs:
- Direct integrations with GitHub, Linear, Intercom, Zendesk, Discord via API — no manual pasting
- Timestamp-aware ingestion for accurate recency weighting
- User segment data (free vs. paid, company size, usage tier) to weight feedback by user value
- Longitudinal tracking — show which themes are growing, stable, or declining week-over-week
- Human validation loop — PM confirms or corrects theme clusters before they go into a dashboard
- Connection to roadmap tools (Linear, Jira) to close the loop from insight to ticket
Next.js 14, TypeScript, Tailwind CSS, Anthropic API (claude-sonnet-4-20250514)