What is an auto-triage PM?
"Auto-triage PM" is a name for software that does the intake half of product work automatically: it reads inbound feedback, decides what kind of report it is, merges it with duplicates, attaches the customer and company behind it, and, when someone asks or an automation runs, turns it into a tracked issue. The name describes a job, not a person. The judgment half of product work, deciding what to build, writing specs and owning the roadmap, stays with people.
Before the definition goes further: we build Modem, which does this intake work, so we are describing a category we sell in. We don't call Modem a product manager. It reads your team's conversations in Slack, Discord, support tools, email and call transcripts, groups reports that mean the same thing into topics, classifies each topic, links it to the people and companies behind it, and files a Linear, Jira, GitLab or GitHub issue when a teammate asks or an automation your team built runs. What to build, and why, is still decided by your team, PMs included. The structure under it is a context graph: topics, people and companies linked across every source with the original messages kept, and the pipeline below falls out of that structure.
“export fails on big workspaces”
“CSV export times out for us”
“exports broken since Tuesday”
a coding agent
PR openedreviewed by a humanThe work it takes on
On most small teams, nobody holds the triage job on paper, so everybody holds it in practice. An engineer skims the support queue. A founder pastes Slack messages into a doc. Someone tags things in the tracker for a few weeks after each planning cycle, then stops. The work is real (reading, deduping, tagging, counting, routing), but it is nobody's role, so it happens in bursts or not at all, and the backlog fills with duplicates and unattributed one-liners. On teams with a PM, the same intake work tends to crowd out the rest of the PM's job.
The auto-triage observation is that the work splits. The intake work is high-volume, low-judgment and pattern-shaped, which is the profile of work that automates. The strategy work is low-volume and high-judgment, and it stays with whoever owns it, whether that's a PM, a founder or an engineering lead. Automating the first half gives that person more time for the second.
What it does, concretely
Auto-triage software sits on the channels where feedback already lands and runs a fixed pipeline on each message:
- Capture: reads the Slack and Discord channels it's added to, support tools like Zendesk and Intercom, email, sales call transcripts and GitHub issues, and picks out the conversations that contain a request, bug or complaint.
- Dedupe: matches each one against existing topics by meaning, so "export to CSV," "can I download this as a spreadsheet," and "no way to get my data out" become one item with three requesters, not three items.
- Classify and count: types each topic as a bug report, feature request, complaint, praise or discussion and keeps the requesters and companies on it, which is what makes the output prioritizable rather than just organized. More on why counting is the point in feature requests.
- Route and file: when a teammate asks, or through automations your team sets up, turns real topics into tracked issues in Linear, Jira, GitLab or GitHub, with the customer evidence in the issue.
- Close the loop: remembers who asked. In Modem's case, an opt-in automation posts an internal Slack note naming who asked when a GitHub PR directly linked to the topic merges, and the agent drafts the follow-up for a person to approve when asked. That is the step human triage almost never gets to, covered in close the loop.
The distinction from AI support triage is worth keeping sharp. Support triage (DevRev's playbook is representative) optimizes for closing tickets: route to the right agent, deflect with an article, reduce resolution time. Auto-triage for product work optimizes for build decisions: the output is not a resolved ticket but a prioritized, evidence-backed backlog.
What it is not
It is not a product manager, and it does not replace product judgment. It can tell you that twelve accounts asked for SSO; it cannot tell you whether SSO matters more than the migration that unblocks your next market. Anyone selling automated prioritization decisions is selling the part of the job where being wrong is expensive and detection is slow.
It also looks different by team. A large product org with dedicated PMs per area has people whose job already includes triage, and there the software takes the reading and counting off their plate so they can spend more time on decisions. And a team whose feedback arrives mostly through a public voting board has a different intake problem: boards pre-structure the input, and that is a different tool category.
Why the category is emerging now
Two curves crossed. Language models got reliable at the specific tasks triage consists of (classification, semantic dedupe, entity extraction), which several vendors now treat as commodity capabilities (Sentisum on automated ticket triage). And coding agents made execution cheap enough that intake became the constraint: when engineers and agents can ship from a well-specified issue, the scarce input is well-specified issues.
The test for whether you need one
Count the steps between a customer saying something and a tracked, deduplicated, attributed issue existing. If the answer is "a human has to notice, remember, and file it," you are running triage on volunteer labor, and it is the kind of labor that stops the week things get busy. Start with one channel: put auto-triage on the noisiest one and see what a week of your feedback looks like ranked.