Duplicate feature requests: merging without losing the voice
5 min read
Three customers ask for the same capability in three different weeks, phrased three different ways, and a triage process built to catch duplicates does its job: it groups them, counts them as one request with three votes, and the backlog stays clean. That’s the easy part. Which labels are worth using covers grouping by underlying capability before triaging by wording as the mechanical fix for duplicates; what it doesn’t cover is what happens to the words themselves once three requests become one line item, and that loss is usually bigger than the duplicate-counting problem it solved.
What actually gets lost when duplicates get merged?
The specific phrasing each requester used, which is often more informative than the vote count it collapses into. One customer might ask for “a way to export filtered results,” another for “CSV export that respects my saved filters,” and a third for “export that doesn’t include hidden columns.” All three are the same underlying request, correctly grouped, but each phrasing carries a slightly different emphasis on what matters to that person, and a merge that keeps only the first submission’s wording throws away the other two entirely. The count survives; the texture that would help someone build the right version of the feature does not.
Why does the texture matter if the vote count already tells you demand exists?
Because demand and design are different questions, and only the specific wording answers the second one. Ten votes on “export” tells a team the feature is worth building; it says nothing about whether “export” means CSV, PDF, a scheduled email, or an API endpoint, and a merge that discards nine of the ten original submissions in favor of the first one’s wording can quietly narrow the spec to whatever the first requester happened to ask for, even if the other nine wanted something subtly different. What a feature request should actually capture covers this same gap from the intake side; duplicate merging is where it resurfaces after intake, at the point where a team most needs the range of what was actually asked for.
What’s a merge process that keeps the wording instead of discarding it?
Append rather than replace. The canonical item keeps a single title for the backlog view, but the original wording from every merged submission stays attached to it, either as a list of quotes or as linked source tickets, so anyone reviewing the item later can see the actual range of what people asked for instead of one team member’s summary of it. This costs almost nothing to build, a field on the ticket rather than a new system, and it is the difference between a merge that compresses information and one that just compresses the display of it.
Feature: Filtered CSV export
Votes: 12
Merged requests:
- "a way to export filtered results" (acct_4421)
- "CSV export that respects my saved filters" (acct_8832)
- "export that doesn't include hidden columns" (acct_1097)
...Does every duplicate deserve to be merged, or are some false matches?
Some are false matches, and treating “sounds similar” as “is the same request” is its own failure mode. “Let me export my data” and “let me export just the filtered view” can get grouped by a keyword match on “export” while actually describing two different scopes of the same general capability; merging them either inflates the vote count for the wrong thing or, worse, ships the narrower version because it happened to arrive first. A human pass on the grouping, even a quick one, catches this before it compounds; an automated similarity match alone will over-merge on vocabulary and under-merge on intent.
When should duplicate-checking actually run, at intake or later?
Both, for different reasons. Checking at intake catches the obvious case, a new request that restates something already open, before it ever becomes its own untracked line item; a similarity search against open requests at submission time handles most of these with no human involved. A second pass later, on a slower cadence, catches the case intake misses: two requests that used different enough language to slip past a keyword or embedding match at the time, but that turn out, once a team has seen a dozen variations, to describe the same underlying capability. Skipping the second pass leaves near-duplicates scattered under separate titles indefinitely, each with its own small vote count that never adds up to the number that would have gotten it built.
Should the requester know their submission got merged into an existing item?
Yes, and this is the same discipline as closing the customer feedback loop applied one step earlier than usual: a requester who submitted something and never hears back concludes their request went nowhere, even if it was correctly merged into an item with eleven other votes that eventually shipped. A short acknowledgment, “we’ve combined this with an existing request others have made too,” costs one message and prevents a customer from re-submitting the same request every few months because they have no visibility into whether it was ever actually tracked.
Does merging change who gets credited when the feature ships?
It should include everyone, not just whoever submitted first. Closing the feedback
loop covers telling requesters when their ask ships; for a merged
item that means every account attached to the merge, not only the one whose wording became the
canonical title, because from each requester’s side they asked for this and it shipped, regardless
of whose phrasing a triage process happened to keep. With Changeloop that means the pull request
names every linked issue (Fixes #142, fixes #187); an issue it does not name gets no comment.
FAQ
How much wording is worth keeping per merged request, a quote or a full ticket link? A short quote is usually enough for the common case, since its purpose is letting a reviewer see the range of phrasing at a glance; keep the full ticket link too when the original had significant extra context, like a screenshot or a detailed workflow description that a one-line quote would flatten.
Does keeping every duplicate’s wording make the backlog harder to scan? Not if it’s collapsed by default. The canonical title is what a scanning reviewer sees; the merged wording is one click or one expand away, present for the person doing deeper research but not cluttering the view for someone just counting votes.
What if two requests look identical but turn out to want different things once built? Split them back apart the moment that becomes clear, and treat the original merge as a reasonable call made with the information available at the time, not a mistake to avoid repeating. A grouping system that never unmerges anything will eventually have a few wrong merges permanently baked in.
Is there a threshold vote count where a merged request should get a human review of the underlying wording? Not a fixed number, but any request nearing a build decision deserves it regardless of vote count, because that’s the point where the difference between “export” and “export as CSV with saved filters” stops being a nuance and starts being the spec.
The technical claims in this article have not been independently reviewed. If something here is wrong, tell us and we will correct it.