How to Run a Feature Request Triage Meeting

Author: Inputly

What is a feature request triage meeting?

Triage is the recurring meeting where a product team reviews new feature requests, decides what happens to each one, and records the decision. It is not a roadmap session and not a design review. The output is a status for every item: accepted, needs evidence, planned, or declined. Teams that hold triage consistently stop re-litigating the same requests, because each one has an owner and a state.

The alternative is worse. Requests pile up in a spreadsheet, decisions happen in chat threads nobody can find, and the loudest manager sets the order.

Who should attend a triage meeting?

Invite the fewest people who can actually decide: a product manager or founder, one engineering lead, one person from support or success, and one from sales if revenue commitments are involved. Design joins only when a request is ambiguous about the user problem.

Everyone else contributes asynchronously by adding context to the request beforehand. Two rules keep the room small: attendees must speak for their function, and nobody attends to defend a single pet request.

How often should you hold triage?

Weekly is the default for most SaaS teams, and it matches how fast feedback arrives. Biweekly works when volume is low, though the queue grows long enough that requesters stop expecting answers. Daily triage usually points at a badly built intake process.

Protect the slot. Cancelling triage is the fastest way to let a backlog double, because items then get decided in scattered conversations. Keep the time fixed and end early when the queue is small.

What is the agenda?

• Five minutes: review the queue. Everything new since the last meeting, sorted by votes or arrival.
• Twenty minutes: decide item by item. For each request, capture the problem, who is affected, the evidence, and the next step.
• Five minutes: revisit deferred items. Anything marked needs evidence gets a deadline or gets closed.
• Five minutes: confirm owners. Every accepted item leaves with a name next to it.

Do the reading before the meeting. If attendees open the backlog for the first time in the room, half the session goes to setup.

How do you decide without endless debate?

Agree on the inputs before the queue arrives, then apply the same rule every week. A small table covers most cases:

| Question | What a yes means | |---|---| | Does it affect a core workflow? | Higher weight | | How many accounts asked? | Volume signal | | Is revenue or a renewal attached? | Urgency signal | | Does it fit the current goal? | Strategic filter | | Is there a workaround? | Lower urgency |

Use those signals consistently, and the numbers will sometimes disagree with the loudest voice in the room, which is the point. Where the evidence is thin, the decision is not yes or no but "needs more evidence, owned by X, due in two weeks". A repeatable prioritization model such as RICE helps once the queue is long.

How do you say no without losing the requester?

Decline the problem, not the person. Say what you understood, why it does not make the cut now, and what would change that answer. Add the item to a visible declined list with the reason, because people tolerate a clear no far better than silence. Teams that skip this step end up needing a script for saying no to feature requests.

Two habits help. Group declines: if ten requests come down to one missing capability, explain it once instead of ten times. Revisit on a trigger: when a relevant metric moves or a large account asks again, the item reopens automatically.

How do you communicate the outcome?

Publish the decision where the request lives, within a day. Each item ends with one of a small set of statuses: accepted, planned, needs evidence, declined. Then tell the requester in the same thread where they wrote, in plain language. "Planned for the next release" is useful; "we will keep it in mind" is not.

A board that shows last month's decisions as current is worse than no board, because people plan around it. If you publish an external roadmap, keep it aligned with these statuses so customers read one story.

What makes triage meetings fail?

1. No decision rules. Every item becomes a debate about first principles.
2. Empty owners. Items leave without a name, so nothing moves.
3. Too many attendees. The room optimizes for consensus instead of judgment.
4. No written intake. Requests arrive verbally, so demand cannot be counted.
5. Silent outcomes. Requesters stop submitting and complain in reviews.

Fix the intake form first. A good feature request states the problem, the affected workflow and the workaround tried, which is what the meeting needs to decide an item in a minute.

Frequently Asked Questions

1. Is triage the same as sprint planning? No. Triage decides what deserves attention; planning decides how and when accepted work gets built.
2. What if engineering says a request is impossible? Record the constraint and the estimate, then ask whether the problem deserves a different solution.
3. Do you score every request? No. Score themes. Fifty similar requests are one row with a count of fifty.
4. How do you keep sales from dominating? Use the same table for every source, and make the weight on revenue at risk explicit.
5. Do you need a dedicated tool? A tracker plus a form works. A feedback board with voting saves the manual step of counting demand.

Triage decides whether the rest of your feedback work matters. Pick a weekly slot, apply the same rules, and tell people what happened to their request. You can run intake, voting and statuses in one place on Inputly.