How to run a feedback triage process without a dedicated PM
Plenty of teams shipping real products have no product manager: it's 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.
Triage is the fix, and it's smaller than it sounds. As definitions like airfocus's put it, triage is reviewing, categorizing, and prioritizing incoming feedback before acting on it. In practice that's three questions per item. A team that answers them consistently has a working process, PM or not.
The three questions
What is it? Bug, feature request, usability confusion, or question. This routing decision matters because each type has a different destination: bugs go to the tracker now, requests get counted first, confusion often means a docs fix.
Have we seen it before? Duplicate detection is the highest-value step and the one humans skip. "Can I export this to CSV?" and "any way to get this data into a spreadsheet?" are the same request. If they're logged separately, each looks like it was asked once.
How much does it matter? Not gut feel — who asked, how many have asked, and what's attached to them. "Requested by 6 accounts, two 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; 30 minutes on the calendar, same time every week (Friday afternoon works — the week's feedback is in, and the output feeds Monday planning). Rotation spreads customer contact across the team, which engineers generally report as a benefit rather than a tax.
The owner doesn't decide the roadmap. They produce the ranked list; the team decides in planning.
Step 2: define the vocabulary before the first session
Agree on a type field (bug / request / confusion / question) and 10–20 product-area tags. Write them in the queue's description. Inconsistent tagging is how counts fragment and triage quietly becomes theater.
Realistic example of a triaged item:
Type: request. Area: reporting. Theme: CSV export (now 6 requests). Latest: "We copy this table into Sheets every Friday, it takes an hour" — Dana @ Acme, Zendesk #4521.
Step 3: run the 30 minutes the same way every time
- Sweep the intake sources — the feedback queue, plus a scan of #customers and the support tag — for anything not yet logged.
- For each new item: classify, then search existing themes before creating a new one. Attach, don't duplicate.
- Update counts on themes that grew this week.
- File anything urgent (data loss, security, a blocked enterprise onboarding) directly into the tracker, tagged for the current cycle.
- Post the output: top five themes by movement, in the team channel.
That last step is what keeps the process alive. When the team sees "SSO moved from 4 to 7 requests this week," triage visibly produces information instead of disappearing into a database.
Step 4: route, don't hoard
Triage output must land where work happens. When a theme crosses your threshold — say, five requests or one strategically important account — it becomes an issue in Linear, Jira, or GitHub with all requester links attached. The queue holds signals; the tracker holds commitments. Keeping them straight prevents the queue from becoming a second, sadder backlog.
Step 5: automate the mechanical parts as volume grows
Classification, dedupe, and counting are exactly the parts machines do well, and at more than a few dozen items a week the manual version starts eating the rotation. This is the product category we work in: Modem auto-triages feedback from Slack, support tools, and sales calls — dedupes, tags, quantifies, and routes it into your tracker — so the weekly session becomes reviewing a prepared list rather than building it. The dedupe holds across sources because Modem keeps a context graph underneath: the same complaint arriving as a ticket and a Slack thread resolves to one topic with two requesters, not two rows. We build Modem; judge that suggestion with the bias in mind. The category has other entrants too — we compared them in best AI triage tools for engineering teams, and the approach is described at AI feedback triage. At low volume, the manual rotation is genuinely fine.
What good looks like after a month
- Every item in the queue has a type, a theme, and a requester.
- Duplicate themes stop appearing.
- Planning meetings reference counts ("7 requests, 3 enterprise") instead of anecdotes.
- Someone has replied "logged it — you're the sixth to ask" to a customer, which is the first small version of closing the loop.
The smallest version you can start this week
Put 30 minutes on Friday's calendar with one owner. Agree on four types and ten tags. Run one session, post the top five themes in Slack. That's the entire process — everything else in this guide is refinement.
