There is a spreadsheet. It has 400 rows, three of which have been read this quarter, and its column headings are "customer", "request" and "notes". Somewhere in it is the one problem that, solved well, would move renewal for an entire segment — and nobody will ever find it, because the queue was designed for storing requests rather than for answering them.
Managing feature requests properly is not about collecting more of them. It is about three unglamorous disciplines: translating each request from a proposed solution back into the problem behind it, knowing how badly each intake channel is biased, and going back to the person who asked — both when you decide and when you ship.
This guide covers the full pipeline, the channel biases nobody accounts for, what to do with the large pile of requests you will never build, and why closing the loop is the step that determines whether anyone bothers telling you anything next quarter.
Key Takeaways
- A request is a proposed solution, not a need. The job is to recover the problem underneath before it reaches a roadmap.
- Every channel is biased. Sales requests skew to deals, support requests to breakage, public boards to whoever is watching the board.
- Vote counts are not priorities. They measure engagement with your feedback system, not the size of the problem.
- One owner, one queue, one schedule. Triage that belongs to everyone happens to nobody.
- Say no quickly and specifically. Silence damages the relationship far more than a clear decline does.
- Closing the loop when you ship is the highest-return step — it converts a request into adoption and keeps the pipeline full.
A Feature Request Is a Proposed Solution
Feature request, in one paragraph
A feature request is a customer or colleague asking for a specific capability to be added or changed. What makes them hard to manage is not their volume but their form: people report the fix they imagined, not the problem they hit. The request is a compressed, lossy encoding of a need — and the compression discards exactly the information you need to decide well. Recovering the need is the first and most valuable step in the entire process.
The classic illustration is the export request. Six customers ask for CSV export, and there is a version of this story where the team builds CSV export, ships it, and discovers that usage is close to zero — because when you finally ask, all six wanted something else.
Each right-hand column suggests solutions the left-hand column does not — a scheduled digest, a fix to the input that keeps producing the mistake, a brightness-aware theme. This is the same move behind jobs to be done: ask what the person was trying to accomplish and what they did instead when it did not work.
The one question that does most of the work. "What were you doing when you needed this, and what did you do instead?" It takes a sentence to ask, converts a request into a story with context, and frequently reveals that two requests filed under different names are the same problem.
Where Requests Come From — and How Each Channel Lies
Requests do not arrive as a representative sample. Each channel over-represents a particular kind of user and a particular kind of problem, and treating the mix as data about your user base is the most common structural error in feature request management.
| Channel | What it over-represents | What it is genuinely good for | Bias |
|---|---|---|---|
| Support tickets | Things that are broken or confusing right now | Friction that is costing you tickets today | Medium |
| Sales calls | Requirements attached to a deal that has not closed | Gaps that block a whole segment from buying | High |
| Customer success reviews | The largest and most vocal accounts | Renewal risk with a name attached to it | High |
| Public voting board | Users who follow your roadmap for sport | Transparency and duplicate detection | High |
| In-app prompts | Whatever screen you put the prompt on | Context — you know exactly what they were doing | Lower |
| Churn and exit surveys | Reasons people give when leaving | What was missing badly enough to lose the account | Medium |
The lowest-bias channel is the in-app one, for a structural reason: it catches the user at the moment of the problem, on the screen where it happened, without requiring them to care enough to open a board or email support. Our guides to in-app surveys and exit surveys cover the mechanics; the point here is that a request captured in context arrives with half the clarification work already done.
The silent majority problem. The users most likely to file a request are the ones most invested in your product — your power users. They are also the ones whose problems are already smallest, because they have learned the workarounds. A backlog built purely from inbound requests is therefore a machine for over-serving the people who need you least, which is one of the mechanisms behind feature bloat.
The Four-Stage Pipeline
A working system has four stages and one owner. The owner does not decide everything; they are accountable for the queue moving, which is a different and rarer job.
Every channel lands in one queue with the same fields. No parallel spreadsheets.
Turn the request into a problem statement, merge duplicates, attach who and how many.
Now, later, or no — on a schedule, with the reason written down.
Tell the requester what you decided. Tell them again when it ships.
Four stages, one queue, one owner. Most broken processes are missing stages two and four.
1. Capture: one queue, consistent fields
It does not matter much which tool holds the queue. It matters enormously that there is one of them and that every entry has the same handful of fields: the request in the requester's own words, who asked, their segment or plan, the screen or workflow it relates to, the date, and the channel it arrived through. That last field is what later lets you notice that a "top request" is really eight people on a public board and one paying customer.
2. Clarify: rewrite it as a problem
Weekly, on a fixed schedule, take the new entries and rewrite each as one sentence of the form "[who] cannot [do what] because [why], so they currently [workaround]." Where the request is too thin to rewrite, go and ask — the requester will almost always reply, because someone actually read what they wrote. Then merge: requests that share a problem statement are one item, however differently they were phrased. This is where a queue of 400 rows usually becomes 60 real problems, and it is also the natural point to run a structured feedback analysis over the text you have collected.
3. Decide: now, later, or no
Three outcomes only. "Under consideration" is not a state, it is a way of avoiding one, and a queue full of them is what customers eventually read as indifference. Weigh four things: how many users are affected and how severely, how well the problem fits where the product is going, the true cost including maintenance and the extra thing every future user has to learn, and what happens if you do nothing. The Kano model is useful precisely here, because it separates requests that are unmet basic expectations — where absence causes real dissatisfaction — from delighters that sound exciting and change nothing.
4. Close the loop, twice
Once at decision time, so the person knows they were heard and what happens next. Once again at ship time, so the person who asked six months ago discovers the thing exists. The second contact is the one nearly everybody skips and the one with the most value in it — see the next section.
Closing the Loop Is the Whole Point
A feature request system has a feedback loop of its own: people file requests in proportion to how much they believe filing them does something. Teams that never respond see submissions dry up, then conclude that customers have no feedback — while the same customers describe the same missing capability to a churn survey eight months later.
The most under-used sentence in SaaS is "you asked for this last quarter — it is live now, here is where it is." It costs nothing, it lands on someone who has already told you they want the thing, and it converts a request into actual usage rather than into a line in a changelog nobody read.
— the argument for targeted announcementsThe practical version has two parts. First, publish what shipped, properly — our guide to writing release notes covers the format. Second, and separately, notify the specific people who asked, inside the product, on the screen where the new capability lives. A general announcement reaches everyone weakly; a targeted one reaches the requester at the moment they can act, which is the difference between awareness and adoption. Our feature announcement playbook covers the sequencing.
Requests captured in-app arrive with context attached — and the same channel can be used to close the loop later.
The "No" Pile Is Most of the Queue
Any healthy product declines the large majority of what it is asked for, and doing that well is a skill. Three patterns hold up:
- Decline fast. A no in a week is respected. A no after six months of silence reads as contempt, and by then the customer has usually built a workaround and lost interest in telling you anything else.
- Give the reason, not the policy. "This is outside what we are building this year, because we are focused on X" is a reason. "It is not on the roadmap" is a wall. The first keeps the conversation open; the second ends it.
- Offer today's answer. Most declined requests have a partial workaround already in the product. Sending it — ideally as a link to the relevant help article or an in-app guide on the right screen — turns a no into a small win.
One nuance worth holding on to: a request you decline is still data. Ten declined requests that share a problem statement are a signal about a gap, even if none of the ten proposed solutions was right. Keep the problem statements searchable, because the cluster that looks like noise this quarter is frequently next year's roadmap item.
A Note on Public Voting Boards
Public boards are genuinely useful for two things — showing customers that the queue exists, and letting people find that their request has already been filed. They are poor at the thing they are usually adopted for, which is prioritisation. Votes measure who is watching the board: engaged individual users vote, enterprise buyers essentially never do, and a request from a segment representing most of your revenue can sit under a request from six enthusiasts.
If you run one, treat votes as a duplicate-detection mechanism rather than a ranking, groom it ruthlessly so it does not become an archive of unanswered asks, and keep the real prioritisation inputs — segment, revenue, severity, strategic fit — in the internal queue where they belong.
Six Ways Feature Request Processes Fail
- Storing without triaging. A queue nobody grooms is not a backlog, it is a landfill — and the effort spent capturing into it is wasted from day one.
- Ranking by raw count. Frequency is one input. Used alone it hands your roadmap to whoever is most comfortable filing tickets.
- Building the literal request. Shipping the proposed solution without recovering the problem produces features that are used once and maintained forever.
- Letting the loudest deal set the roadmap. One large prospect's requirement list is a segment signal at best and a distraction at worst. Ask how many existing customers have the same problem before committing.
- No response at decision time. The single fastest way to stop receiving feedback, and it is invisible until the queue quietly dries up.
- Shipping in silence. Building the right thing and never telling the person who asked is the most expensive mistake on this list, because you paid the whole cost and collected none of the credit.
Feature Requests: Do vs. Don't
✅ Do
- Funnel every channel into a single queue with consistent fields
- Rewrite each request as a problem statement before deciding
- Record which channel each request came through
- Triage on a fixed weekly schedule with one named owner
- Decline explicitly, with a reason and any workaround
- Notify the original requesters in-app when it ships
❌ Don't
- Rank by vote count
- Use "under consideration" as a permanent state
- Build the proposed solution without asking what it was for
- Let a single deal rewrite the quarter
- Keep parallel request lists in three tools
- Assume a quiet queue means customers are happy
Collecting and Closing the Loop Inside the Product
Everything above is easier when both ends of the loop live where the user already is. Capture is better in-app because context comes free: you know the screen, the segment and what the person had just done. Closing the loop is better in-app because the announcement lands on the screen where the new capability actually exists, rather than in an inbox two days later.
That is a plain no-code job: a micro-survey on the screen where a workflow keeps stalling, and a targeted announcement to the segment that asked, published without waiting for a release. Combine it with a short walkthrough of the new capability and a request turns into adoption on the same day it turns into a shipped feature.
Ask where the problem happens. Answer where the fix lives.
Kompassify lets you run in-app surveys to capture requests in context, then announce what you built to exactly the users who asked — with tooltips, walkthroughs and announcements published on top of your existing product, no engineering time required. Free up to 100 monthly active users, plans from $129/month, GDPR-compliant and EU-hosted.
Start for free →The One-Paragraph Version
Treat every feature request as a proposed solution that has to be translated back into a problem, remember that each intake channel over-represents a different kind of user, run one queue with one owner and a weekly triage, decide in three states rather than parking things forever, and go back to the people who asked — once when you decide and again when you ship. The last step is the one that keeps the queue alive.
Frequently Asked Questions
What is a feature request?
A feature request is a customer or colleague asking for a specific capability to be added or changed. The important thing about the definition is what it leaves out: a request is a proposed solution, not a statement of need. Someone asking for a CSV export may need a scheduled report, an integration, or simply a way to show a number to their manager. Managing feature requests well is mostly the discipline of recovering the underlying problem before the proposed solution gets written into a roadmap.
How should you collect feature requests?
Collect them where the user already is, and funnel every channel into one place. In-app prompts catch the request at the moment of frustration with full context about what the person was doing; support conversations capture the problem in the user's own words; sales and customer success calls surface requests tied to revenue. What matters is not adding more channels but making sure every channel lands in a single queue with the same fields, because requests scattered across a helpdesk, a spreadsheet and three Slack channels cannot be counted, compared or answered.
How do you prioritise feature requests?
Not by vote count. Weigh how many users are affected against how badly, how well the request fits your product's direction, what it costs to build and maintain, and what it would mean to do nothing. Frequency is one input among several, and a raw tally is heavily biased towards the loudest and most engaged users — the people already succeeding with the product. Frameworks such as the Kano model help by classifying whether a request is a basic expectation, a performance improvement or a delighter, which changes the value of building it.
Should you have a public feature request board?
Only if you will maintain it. A public board with visible voting is excellent for transparency and terrible as a prioritisation input: votes measure who is watching your board, not who has the problem, and enterprise customers rarely vote at all. It also creates an obligation — a board full of two-year-old requests marked 'under consideration' is a public record of not listening. If you cannot commit to responding and grooming it, an internal queue with proactive follow-up serves customers better.
How do you say no to a feature request?
Quickly, specifically, and with the reason. Most customers accept a no far better than silence, and what damages the relationship is a request that disappears for six months before quietly dying. Name the problem you understood, say what you decided and why — off-strategy, served by an existing capability, too narrow for the user base — and offer whatever workaround exists today. A clear no also keeps people submitting requests, which is the outcome you actually want.
What does closing the loop on feature requests mean?
Closing the loop means going back to the people who asked, twice: once when you decide, and again when you ship. Most teams do neither, which is why customers stop reporting problems. The second contact is the valuable one — telling someone that the thing they asked for last quarter is now live, in the product, at the moment they can use it, converts a request into adoption and into goodwill. An in-app announcement targeted at the requesters is the cheapest reliable way to do it.
Who should own feature requests?
One named person or role should own the queue itself — normally a product manager, sometimes a product operations or customer success lead — even though everyone contributes to it. Ownership means being accountable for triage happening on a schedule, for the fields being filled in, and for responses going back out. Shared ownership of a request queue reliably produces an unread backlog, because triage is the kind of work that is always slightly less urgent than everything else.
How many feature requests should you actually build?
Fewer than you receive, by a wide margin. A queue is an input to strategy, not a substitute for it, and a roadmap assembled from the most-requested items tends towards feature bloat: lots of capabilities, each serving a small group, all of which must be maintained and taught to every future user. The healthier pattern is to look for the recurring problem behind clusters of requests and solve that once, which frequently satisfies a dozen requests with one well-designed change.