Product
Sixty requests, and no idea how many people asked
Clustered requests with a real count of who asked, so the argument is about value rather than recall.
What the worker does
Feature prioritisation with an AI worker starts with counting. The worker collects open requests from Slack threads, tracker issues and CRM notes, clusters them by theme, counts how many distinct accounts asked for each, and keeps a source link against every mention. The delivery is a ranked table posted as a comment. Weighting the themes and choosing what to build remains a human decision.
- Runs
- Before each planning cycle
- Connections
- Slack, Linear, HubSpot
- Output
- A counted, sourced table
Prioritisation arguments are usually memory arguments
Someone says customers keep asking for this. What they mean is that three customers asked, one of them twice, and the last time was in a call four months ago that stuck in their head. Someone else remembers a different set. Neither person is lying and neither can produce the list.
The requests exist. They are in Slack threads, in support tickets, in tracker issues and in the notes attached to deals. They have simply never been counted, because counting them by hand takes a full day and expires the moment a new request arrives.
What the worker is briefed to do
Collect, with the source kept
Every mention gets a link back to the thread, ticket or issue it came from. A cluster with no traceable sources is a cluster you should not trust.
Cluster by what was asked for, not by wording
Export to CSV and can I get this as a spreadsheet are the same request. The rules for what merges live in the worker's SKILL.md, so they are yours to tighten.
Count distinct accounts, not mentions
One vocal customer asking eight times is not eight customers. This distinction is the entire value of the exercise and it is where hand-counting usually fails.
Flag the singletons
Requests with exactly one asker are listed separately rather than ranked. Some of them are the most important thing on the page, and burying them in a ranking hides that.
What each connection contributes
| Connection | What it holds | What the worker takes from it |
|---|---|---|
| Slack | Requests made in channels and threads | The ask, who made it, the thread link, the date |
| Linear | Requests already filed as issues | Existing issue text and any linked duplicates |
| HubSpot | Requests raised in deals and calls | Notes attached to accounts, and which account asked |
| Notion | Requests captured in meeting notes | Anything written down outside the tracker |
Counting is not deciding
The worker supplies
- How many distinct accounts asked
- When each one asked, and where
- Which requests are already filed
- Which requests only one person has ever raised
You supply
- Which accounts you actually want to serve
- What the request costs to build
- Whether the request is the real problem
- The decision, and the reason you will give for it
Questions people ask
+How does the worker avoid double-counting the same request?
By counting distinct accounts rather than mentions, and by keeping every source link so a cluster can be audited. Where two mentions look like the same account under different names, they appear in the delivery comment as an ambiguity for you to resolve.
+Can it pull requests from our support inbox?
Yes, through the Gmail connection if support runs on email. The connection catalog is fixed: Slack, Notion, Linear, GitHub, Gmail, Google Calendar, Google Drive, Figma, HubSpot, Stripe, Supabase, WhatsApp, Instagram and open web search.
+Will it invent a request that nobody made?
Every clustered item carries the links it was built from, so a claim with no source is visible immediately. Requiring a source link per mention is worth writing into the acceptance criteria of the task, and the worker ticks those criteria as it works.
+How often should this run?
Before each planning cycle rather than daily. Request volume does not change much week to week, and a table that is regenerated constantly stops being read. Monthly is enough for most teams under fifty people.
Related
Product management with an AI worker on the roster
Five jobs a product team can hand to an AI teammate, and the ones it should never hand over.
Your roadmap document and your tracker disagree
A weekly diff between what the roadmap claims and what the tracker actually says.
Twelve interviews recorded, two of them read
Themes with participant counts and verbatim quotes, plus a flag wherever the evidence is thin.
Connect Slack to Polaris
Six scopes, no access to direct messages, and a bot that only reads the channels somebody invited it into.
Connect HubSpot to Polaris
Private-app tokens are scoped where you create them, which makes HubSpot one of the easier connections to grant narrowly.
Hire an AI research analyst
Assign the question on Tuesday afternoon and read the brief before your Wednesday call, with every claim carrying the URL it came from.
AI worker
The difference between an agent you prompt and an agent you assign work to.