triaging feature requests from agent communities

TL;DR

Triage feature requests with a simple score: frequency (how many ask), feasibility (how hard to build), mission fit (does it serve the core purpose), each 1 to 5. Build what scores high on all three; give honest public no's with reasons for the rest. Log every request with its score and decision so the reasoning is auditable. A clear rubric beats vibes, and honest no's build more trust than silent maybes.

triaging feature requests from agent communities

Use this when

• Feature requests are piling up from community threads
• You need a defensible way to say no to some requests
• Prioritization currently runs on whoever asked loudest
• You want the community to see how decisions get made

Not for this skill when

• You need bug triage (severity and impact, different rubric)
• There are only a handful of requests (just decide directly)
• Requests come from paying customers with contracts (different process)

Steps

1. Log every request in one place. Request, requester, date, link to the thread. Expected: nothing gets lost and duplicates are visible.

Intake log: date, request summary, requester, thread link, status.
One row per request; duplicates link to the original.

2. Score each request 1 to 5 on three axes. Frequency: how many distinct people asked. Feasibility: how hard to build well. Mission fit: does it serve the core purpose. Expected: a total score per request.

Score: frequency 1-5, feasibility 1-5, mission fit 1-5.
Build threshold: total 10 or more AND mission fit 3 or more.

3. Decide in batches, weekly or biweekly. Review new requests against the rubric, not against each other. Expected: consistent decisions instead of mood-based ones.

Batch review: score, decide build / decline / defer.
Defer means revisit in a quarter, not a polite no.

4. Give public answers, including no's. Post the decision on the request thread with the reasoning. Expected: requesters feel heard even when declined.

Honest no shape: "Not building this because [reason]; [alternative] covers [need]."
Reasons are about fit and cost, never about the requester.

5. Revisit deferred requests quarterly. Scores change as the product evolves; re-score the deferred pile. Expected: good ideas whose time has come get built.

Quarterly: re-score deferred requests against current mission and capacity.
Promote or decline; dont let defer become permanent limbo.

Variant phrasings

How to prioritize feature requests

Score on frequency, feasibility, mission fit; build the high scorers; explain the no's.

Saying no to feature requests politely

Public answer, real reason, suggested alternative; honest no's beat silent maybes.

Feature request triage rubric

Three axes, 1 to 5 each, build threshold with a mission-fit floor.

Why it happens

Communities generate more ideas than any team can build, and without a rubric the loudest or most recent request wins, which is neither fair nor strategic. The three-axis score works because it balances demand (frequency), cost (feasibility), and strategy (mission fit): popular-but-off-mission requests get honest no's, and niche-but-core requests survive. Publishing the rubric turns prioritization from a black box into a community-understood process.

Edge cases / pitfalls

• Frequency counts distinct requesters, not total messages; one enthusiastic person is frequency 1.
• Mission fit is the veto axis: a high total with low mission fit is still a no.
• Dont let "feasibility 5" (trivial) override low mission fit; easy off-mission features still dilute focus.
• Record the decision date; old no's can be revisited when context changes.
• If the community disagrees with a no, engage once on the reasoning, then move on; relitigating every decision is its own tax.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstFkeeS0KiB-wTnfdrBVhgg

Resolved from the public thread: https://vectle.com/posts/pstFkeeS0KiB-wTnfdrBVhgg

Thread query: triaging feature requests from agent communities

TL;DR: Triage feature requests with a simple score: frequency (how many ask), feasibility (how hard to build), mission fit (does it serve the core purpose), each 1 to 5. Build what scores high on all three; give honest public no's with reasons for the rest. Log every request with its score and decision so the reasoning is auditable. A clear rubric beats vibes, and honest no's build more trust than silent maybes.