How to handle duplicate feature requests
The tenth request for CSV export feels like noise. It's the opposite: it's your prioritization data arriving one customer at a time. A duplicate feature request is a customer independently confirming that a problem is real, and the count of duplicates — who asked, how many, from which accounts — is the strongest evidence you'll ever have for what to build next.
Teams that treat duplicates as clutter delete or close them, and the damage is specific: the signal fragments. "Add dark mode," "night theme please," and "my eyes at 2am" sit as three separate items with a third of the weight each, and your most-requested feature looks like several mid-tier ones. The job is not to eliminate duplicates; it's to merge them without losing anything.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in Notion1. Decide what "the same request" means
Before merging anything, agree on the unit. The useful rule: two requests are duplicates if shipping one thing would satisfy both. "Export the audit log to CSV" and "let me download admin activity" — same request. "Export audit logs" and "export invoices" — same verb, different feature; keep them apart, related but distinct.
This is also why matching on words fails. Duplicates almost never share phrasing — customers describe problems in their own vocabulary — so any process that relies on identical titles will miss most of them. Whoever merges needs to compare underlying problems, not strings.
2. Create one canonical topic per request
Pick one item to be the canonical record — usually the clearest-written one, not the oldest — and give it a title in problem language: "Customers need scheduled exports of the audit log," not "Zapier integration." Solution-flavored titles attract the wrong merges later.
Everything else about the duplicates gets folded in, not thrown away:
- Every requester, with company, attached to the canonical topic
- Every verbatim quote — different customers reveal different facets ("for our auditors," "for a weekly report," "because the API is rate-limited")
- Links back to each original conversation or ticket
The rule that makes this work: merging must never delete a requester. The whole point of the merge is that the counter goes up while the clutter goes down.
3. Close the duplicate politely, pointing at the canonical
When you mark something as a duplicate, tell the requester what that means, because "closed as duplicate" reads as dismissal:
"You're the 14th customer to ask for this — I've added you to the main request so your ask counts toward it, and you'll hear from us when its status changes."
That message converts a rejection into evidence of momentum. It also commits you to the follow-up, which is the payoff of step 2: when the feature ships, everyone attached to the canonical topic gets told. A merge that preserves requesters makes closing the loop a mail-merge; a merge that doesn't makes it impossible.
4. Count duplicates as your prioritization input
Once merges are flowing into canonical topics, the topic list becomes a ranked backlog for free: requests sorted by requester count, weighted by whatever matters to you — account size, plan, churn risk. This is the payoff, and it's why teams that dedupe well stop arguing about priorities from anecdote. The counting only works if merging keeps up; a backlog where half the duplicates are unmerged is quietly lying to you about rank order. More on the overall system in our feature request tracking overview.
5. Decide who merges, and how it scales
At low volume, dedupe is a human habit: whoever triages checks new requests against existing topics before filing, weekly. A spreadsheet with a Theme column does this fine — see our feedback tracker templates.
It stops scaling for a predictable reason: matching requires reading every new item against memory of every old one, and that memory lives in one person's head. When they're out, dedupe stops; when volume doubles, it silently degrades. Feedback platforms have converged on semantic matching for exactly this reason — Upvoty's Merge AI does it within its board, for example.
Disclosure: we build Modem, and dedupe is the center of what it does — every message from Slack, Discord, support, and email is compared semantically against existing topics as it arrives, merged with the requester and quote preserved, and counted. What accumulates is a context graph: topics linked to every person and account that raised them, with the original wording kept as evidence. The honest boundary: automated matching still wants a human check on borderline merges — "same feature or adjacent feature" (step 1) is a product judgment, and a wrong merge is worse than a missed one because it hides a distinct need inside another topic's count.
What not to do
- Don't delete duplicates. Every deletion subtracts a requester from your evidence and a name from your ship-day announcement list.
- Don't merge by keyword. You'll merge "export invoices" into "export audit logs" and miss "night theme" entirely.
- Don't let votes replace dedupe. Voting boards only aggregate the people who found the board and searched before posting. The duplicates arriving through support and Slack are usually the larger population.
The smallest version to start this week
Take your current request list, sort it, and spend one hour merging the obvious duplicates into canonical topics — preserving every name. Then add one rule to triage: before filing anything new, check it against the topic list. When you announce your next shipped feature to eleven attached requesters at once, the habit will fund itself.
