How to run feedback triage without a PM

Short answer. Feedback triage without a PM is one rotating owner, a 30-minute weekly session, and three questions asked of every item: what is it, have we seen it before, and how much does it matter. The steps below need nothing more than a shared spreadsheet or your tracker's triage queue. When volume outgrows the session, Modem (our product) can take the mechanical half: it reads Slack, Discord, support tickets, email, and call transcripts, groups differently-worded reports of the same problem into one topic, classifies each topic by type, and gives it an AI-assigned priority. It does not decide who owns the work. Topics have no owner field, and routing happens through automations your team sets up or by asking Modem's agent, and nothing is filed in your tracker unless one of those asks.

Plenty of teams shipping real products have no product manager: four engineers, a founder who sells, and a support queue. Feedback still arrives constantly, and without anyone whose job is to process it, it either gets ignored or it interrupts. Whoever shouts in Slack most recently sets the priority, and nobody can say whether a request was asked once or ten times.

Triage is the fix, and it is smaller than it sounds. A team that answers the three questions the same way every week has a working process, PM or not.

The three questions

What is it? Bug, feature request, confusion, or question. Each type has a different destination: bugs go to the tracker now, requests get counted first, and confusion often means a docs or UI copy fix.

Have we seen it before? Duplicate detection is the highest-value step and the one people skip. "Can I export this to CSV?" and "any way to get this data into a spreadsheet?" are the same request. Logged separately, each looks like it was asked once.

How much does it matter? Not gut feel. Who asked, how many distinct accounts have asked, and what is attached to them. "Requested by 8 accounts, 3 on the enterprise plan, one in a renewal quarter" is an answer. "Feels important" is not.

Step 1: pick a triage owner and a cadence

Without a PM, the role rotates. One person per week owns the queue, with 30 minutes on the calendar at the same time every week. Friday afternoon works: the week's feedback is in, and the output feeds Monday planning. Rotation also spreads customer contact across the team.

The owner does not decide the roadmap. They produce the ranked list; the team decides in planning.

Step 2: write the vocabulary down so tags stay consistent

Counts fragment when one person tags "dashboard", another "UI", and a third "reporting" for the same complaint. Fix the vocabulary before the first session:

Four types: bug, request, confusion, question. No others.
10 to 20 product-area tags, each with a one-line definition and one example. "Reporting: anything about getting data out of the product (exports, scheduled reports, CSV)."
One place for the list: the queue's description or a pinned doc. If a tag is not on the list, it does not exist.
New tags are added in planning, not mid-session. The owner can propose one; the team agrees. This stops near-synonyms from creeping in.
A monthly cleanup: merge any two tags that keep getting used for the same thing, and retag their items.

An illustrative triaged item:

Type: request. Area: reporting. Theme: get report data into a spreadsheet (now 6 accounts). Latest: "We copy this table into Sheets every Friday, it takes an hour", from [requester] at [account], Zendesk #[id].

Step 3: catch duplicates that are worded differently

Most duplicates do not share a keyword, so searching for the new item's words misses them. Four habits catch most of them:

Name themes by the outcome the customer wants, not the feature they proposed. "Get report data into a spreadsheet" catches CSV export, Sheets sync, and "can I download this?" A theme called "CSV button" only catches the first.
Keep a synonyms line on each theme. Every time you attach an item worded differently, add its phrasing ("download", "Excel", "Sheets"). Next week's search finds it.
Browse by area tag before searching by words. Scan every open theme under the item's area; there are rarely more than a dozen.
Use one test for "same": would one change fix both? If yes, attach. If they share a theme but need different fixes ("export is slow" and "export is missing columns"), they are two themes.

Count distinct accounts on each theme, not messages. The same customer asking in Slack and in a support ticket is one requester, not two.

Step 4: run the 30 minutes the same way every time

Sweep the intake sources: the feedback queue, plus a scan of the customer Slack channels and the support tag, for anything not yet logged.
For each new item: classify it, then search existing themes before creating a new one. Attach, don't duplicate.
Update the account count on themes that grew this week.
File anything urgent (data loss, security, a blocked enterprise onboarding) straight into the tracker for the current cycle.
Post the output in the team channel: the top five themes by movement.

Step 5: decide what matters with evidence

Give each theme the same three facts so planning compares like with like:

Breadth: how many distinct accounts, and how many new this week.
Who: plan or tier, and anything time-sensitive, such as a renewal, an open deal, or an onboarding.
Stake: what breaks or what it costs them. "Copies the table into Sheets by hand every Friday" is a stake; "would be nice" is not.

Agree on a threshold for moving a theme into the tracker, and write it next to the vocabulary. A workable starting rule is five accounts, or one account the team has named as strategic. Adjust it after a month.

Step 6: make the output visible, then route it

The weekly post is what keeps the process alive. When the team sees "SSO moved from 4 to 7 accounts this week", triage visibly produces information instead of disappearing into a database.

Then the output has to land where work happens. When a theme crosses the threshold, the triage owner files it as an issue in Linear, Jira, GitHub, or GitLab with the requester list and two or three of the customers' own sentences attached. Assignment happens in planning, like any other issue. The queue holds signals; the tracker holds commitments. Keeping them separate stops the queue from becoming a second, sadder backlog.

Step 7: automate the mechanical parts when volume grows

The manual version works while the session fits in 30 minutes. Signs it no longer does: the owner runs out of time before the sweep is done, often somewhere between 20 and 50 new items a week; the same customer shows up as two requesters; or themes split because nobody remembered the right synonym.

Classification, duplicate detection, and counting are the parts software does well. Judgment about what to build, and who builds it, stays with the team.

What Modem does in this process, and what it doesn't

We built Modem because, as our launch post put it, "corralling feedback from users across a dozen channels" was part of what "was always the hard part, and it was almost entirely manual." Mapped to the steps above:

Sweep and classify (Steps 2 and 4). Modem reads the sources you connect, including Slack, Discord, GitHub issues, Zendesk, Intercom, email, and call transcripts. It skips conversations that are not about your product. Each topic gets one of five fixed types: bug report, feature request, complaint, praise, or discussion. You cannot define your own types, and there is no separate "question" type; questions fall under discussion.
Duplicates (Step 3). Reports are matched by meaning, so the CSV and spreadsheet asks can land in one topic even when one arrived as a Zendesk ticket and the other as a Slack thread. Topics are split by what change would fix them, not by broad theme, the same test as Step 3. Matching is model judgment, so it can over-merge or over-split; you can merge topics or edit them by hand. People are linked across platforms when they share an email address; Discord users have no email, so they are not merged automatically.
How much it matters (Step 5). Priority is an AI-assigned score on five levels. It weighs who is affected, how many customers and companies, whether the problem keeps recurring, and whether it is already being handled. A fixed outage someone is already on should score low; a quiet, unanswered customer complaint should score high. Priority is not a count: past a few companies, more requesters stop moving it much. It is not weighted by revenue either. To make named accounts count for more, you write that guidance in Modem's prioritization settings, and you can ask the agent questions that join Stripe billing data to topics, such as "Which paying customers reported bugs this month?"
Output and routing (Step 6). Topics have no owner or assignee. Routing is something you configure: Event Automations run Modem's agent when, for example, a topic is created or reaches high priority (the exact threshold depends on how your organization scores priority). An automation can post to a Slack channel, DM a teammate, or create a Linear, Jira, or GitHub issue. Automations run without an approval step, so they act on what you configure. In Slack and, by default, in the dashboard, an issue in a public repository waits for your approval first, because it's a statement in your organization's name. When an issue is created, the requesters and a few of their quotes are written into its body.

What stays with your team: the threshold, the planning meeting, the assignment, and the reply to the customer. Modem can draft that reply for approval in some channels, but it does not message customers on its own. At a few dozen items a week, the manual rotation above is fine and costs nothing. For other tools in this category, see best AI triage tools for engineering teams.

What good looks like after a month

Every item in the queue has a type, a theme, and a requester.
New duplicate themes stop appearing, because the synonyms lines catch them.
Planning meetings reference counts ("9 accounts, 4 enterprise") instead of anecdotes.
Someone has replied "logged it, you're the sixth account to ask" to a customer, which is the first small version of closing the loop.

Start this Friday

Put 30 minutes on Friday's calendar with one owner. Write down four types and ten area tags with definitions. Run one session and post the top five themes in Slack. That is the whole process; everything else in this guide is refinement.