Feature Request Triage

Feature request triage is the step between capturing feedback and deciding what deserves deeper discovery or downstream prioritization. The useful unit is not simply the requested feature. You preserve the original evidence, identify true duplicates, separate bugs and other signals, define the best-supported problem candidate, make uncertainty visible, and record the next learning or routing action.

No. It uses local TF-IDF and cosine similarity to create lexical similarity suggestions. A suggestion can connect several transitive matches, but shared words do not prove that the underlying problem is the same. You inspect the original requests and then explicitly confirm the merge or separate the suggestion. Original evidence remains available either way.

A request count tells you how many recorded observations you have. Product reach requires an estimate of how many people or events are affected in a defined period. The tool therefore separates evidence mentions, known accounts, known requesters, and unknown requester identity. If you later prepare a RICE handoff, real Reach stays blank until you deliberately enter it.

Keep them as proxy evidence with the source, account, and any direct-customer confirmation recorded. Four Sales notes about Acme can be four observations while still representing one known account. The commercial context may be highly relevant, especially for a deal blocker, but the tool does not convert proxy volume or revenue into an automatic Product priority score.

Likely defects are routed separately rather than ranked against feature requests. Capture the expected behavior, actual behavior, environment when known, reproducibility, and workaround, then move the issue into the team's bug process where severity and ownership can be assessed. This tool preserves the feedback evidence but does not try to replace an issue tracker or incident workflow.

There is no universal checklist score. You should know enough to state the problem without inventing context and to identify the most important uncertainty. Useful evidence can include who experiences the problem, when it occurs, frequency, current workaround, consequence, desired outcome, and source provenance. For a Discovery decision, the tool asks for a learning question and the best next evidence.

Yes, as a downstream handoff rather than fake pre-filled RICE. The Prepare for RICE export includes the problem candidate and evidence summary, plus optional user-entered Reach, Reach period, Impact, Confidence percentage/basis, and Effort in person-months. Unknown values remain blank. Request mentions are never silently reused as period-based Reach.

Each problem candidate keeps a Decision Memory & Revisit Ledger. When you deliberately record a decision, the tool snapshots the rationale, evidence summary, unknowns, Product context, revisit condition and communication state at that moment. Later edits change working state only, the snapshot stays unchanged. The workspace then shows what changed since: new or removed evidence, edited problem wording, or changed objective, segment or constraints. Reversing a parked or not-pursuing decision asks for a written change reason, and a revisit trigger is treated as a reason to reconsider, never as approval to build.

State is compressed into the URL for browser-to-browser sharing; compression is not encryption. A full internal share can contain raw feedback, account names, commercial context, source links, internal decisions and decision history, so anyone with the link can inspect it. A sanitized share removes raw customer/account detail and scrubs historical rationale, problem wording and evidence references. Very large URLs are blocked and the tool recommends exporting instead.