How to track feature requests without losing them
6 min read
Feature request tracking fails one of two ways almost every time. Either requests have nowhere to go, so they live in inboxes and Slack threads and get forgotten individually, or they have somewhere to go that nobody revisits, so they get forgotten collectively instead. A system that works has to survive both failure modes: it needs one place every request lands, and it needs a reason for someone to open that place again next month.
Where do feature requests actually come from?
More channels than most tracking systems account for. A support ticket that includes “it would be nice if”. A comment on a public roadmap. A sales call where a prospect names the one thing blocking the deal. An in-product widget. Each channel has its own owner and its own tooling, which is exactly why requests scatter: the support team’s ticket queue and the product team’s backlog are rarely the same system, and a request that only reaches one of them effectively only reached one department.
| Source | Typical owner | Where it tends to die |
|---|---|---|
| Support tickets | Support team | Closed as resolved, never re-surfaced |
| Sales calls | Sales / account management | A CRM field nobody in product reads |
| In-product widget | Product | A form submission with no follow-up |
| Public roadmap comments | Whoever built the roadmap | The comment thread itself |
| Social media / reviews | Marketing or nobody | Screenshotted once, then gone |
A single intake form for every channel doesn’t work, because nobody adopts it. What works is one destination each channel routes into, even if the routing is a person doing five minutes of copy-paste a day until it is automated.
What actually breaks feature request tracking?
Two things, almost always. The first is a missing destination: requests get answered in the channel they arrived in and never recorded anywhere durable, so the same request from three different customers looks like three unrelated one-off replies instead of one signal. The second, more common failure is a destination that fills up and stops being read. A spreadsheet with 400 rows and no filtering is not a tracking system anymore; it is an archive that happens to be writable.
The second failure is the more dangerous one, because it looks like tracking is working. Requests get logged. Nothing looks broken until someone asks “how many people have asked for X” and the honest answer is “we would have to read all 400 rows to know.”
What should a feature request record actually contain?
Enough to answer three questions later without re-reading the original message: what was asked for, in the requester’s own words if possible; who asked, and how to reach them if the answer is “we built it”; and what it would take to know if this is a common ask or a one-off. A raw quote matters more than a paraphrase, because a paraphrase written by whoever triaged the request already carries their read on it, and that read is exactly the thing a second reader six months later cannot check.
What labels are worth using?
Two, and they answer different questions. A type label separates a feature request from a bug report, because the two need different owners and different timelines, and mixing them in one queue means the loudest complaints crowd out the asks. A priority label, kept to a small set like low, medium and high, separates “blocking someone from using the product” from “would be nice,” because those two deserve very different response times and neither should default to the other’s pace. Getting the type label right assumes the request is what it says it is; when a feature request is actually a bug report covers the case where a customer’s own words point that label the wrong way.
Automated triage can apply both the moment a request lands. In Changeloop, a widget submission
gets labelled feature-request or bug and a priority:low|medium|high label from the same
pass, plus a from-widget tag so the source is visible without opening the item. That is enough
structure to filter the backlog into something answerable in a minute instead of an afternoon:
show me every high-priority feature request from the widget this month.
A third label is worth adding once you have a public roadmap: a status a requester can see moving. Public roadmap covers the planned, building, and shipped states in full; the short version here is that the label is what turns a private queue into something a requester can check on their own, instead of asking again.
How do you decide what to build next?
Group before you count. Ten differently-worded requests for the same underlying capability read as ten scattered rows in a spreadsheet and as one strong signal once they are grouped, and the grouping is usually the missing step, not the counting. A raw request count without grouping tends to reward whichever feature has the catchiest name, not the one with the most actual demand behind it.
Weight by who asked, not only how many asked. A request from an account near renewal carries a different kind of urgency than the same request from a trial signup, and a tracking system that throws that context away in favor of a bare tally is optimizing for the easiest number to compute rather than the most useful one.
Every decision here also produces requests that lose, and those deserve a reply too; how to decline a feature request covers what to say to the requesters whose ask didn’t make the cut. Grouping and weighting is only half of “what to build next”; how to prioritize feature requests covers the actual frameworks, RICE, revenue-weighting, and raw counts, and where each one breaks.
How do you close the loop once something ships?
This is the step tracking systems most often skip, and it is the one requesters actually notice. Closing the customer feedback loop covers the full mechanics; the piece that belongs here is that closing the loop only works if the original request stayed linked to the person who made it. A feature request template built from a GitHub issue, with the requester’s identity attached to the issue rather than buried in a comment, is what makes an automatic “shipped” notification possible instead of a manual one someone has to remember to send. Feature request template shows the actual template and the fields each one is for.
FAQ
What tool should I use to track feature requests? Whatever your team already checks daily beats a dedicated tool nobody opens. A GitHub issue tracker works well if engineering already lives there; a lightweight board works well if product does. The tool matters less than whether it gets revisited.
How do I stop feature requests from getting duplicated? Group by underlying capability before triaging by wording. A search across existing requests before filing a new one catches most duplicates; a monthly grouping pass catches the rest. Merging duplicates without losing the original voice covers what to do with the wording once the grouping itself is done, so the merge doesn’t quietly narrow the request to whichever submission arrived first.
Should every feature request get a response? Every one should get an acknowledgment, even a short one, but not every one needs a decision right away. A visible status, like a roadmap label the requester can check, replaces most of the one-off replies a team would otherwise owe individually.
What’s the difference between feature request tracking and a public roadmap? Tracking is the internal record of every ask, including the ones that will never ship. A public roadmap is the subset a team is willing to commit to publicly, at a status the requester can see without asking again.
The technical claims in this article have not been independently reviewed. If something here is wrong, tell us and we will correct it.