When you are asking me for a “neat feature request process”, you are probably solving the wrong problem.
The process (or lack thereof) is the symptom, but the real solution requires a mindset shift.
When people talk about the feature request process, they think about a single place to submit, tag, dedupe, and track so nothing gets missed and everyone can see status. Sounds reasonable in theory, but in practice, it turns requests into tickets and PMs into agents. We start managing SLA to a queue instead of making decisions that move the business.
To break this pattern, we must look at the purpose of feature requests. Not all feature requests are alike, and the ticketing system where you feed them shouldn’t be the solution for everything.
Here is what feature requests are really about, and what to do with them from the various angles.
What feature requests are really about
Feature requests are an ongoing conversation between the field and product. We often pour that conversation into a ticketing system because it is the most available tool. But the nature of the work is not ticket handling. It is a steady exchange of input and output that the product team uses to understand what is happening, make choices, and explain them.
When we mix this ongoing communication with ad hoc questions and true escalations in one funnel, things get messy.
Seen for what they are, feature requests serve four goals:
- Ongoing input: A continuous log of what people are seeing in the field
- Ongoing output: A regular way for the product team to close the loop and show progress in the right direction
- Ad hoc clarity: Sometimes someone needs to know whether we will support something, and when
- Ad hoc deal breaker: When a live customer situation requires immediate attention and an explicit tradeoff
The ad-hoc ones require immediate attention and must stand out to be properly handled. It can be within the ticketing system that you use for feature requests or through a separate process.
Once we have separated them, we can now talk about the ongoing nature of feature requests and how to handle them properly.
Ongoing input, not tickets
If we stop treating feature requests as items we must answer and start treating them as ongoing input, here are two important ways to use this ongoing stream:
Always-on feed for intuition
Recommendation: treat an always-on feed as your primary intuition builder. You will not read everything, and that is fine. The point is exposure.
Resist the urge to batch requests into a weekly AI digest. You probably will not read it.
Instead, push brief, real-time signals to yourself. Email or chat is fine. Aim for a title and one short line of context. Glancing at many tiny signals beats one long summary you postpone.
Your brain will quietly connect dots over time: repeated pains, phrasing customers use, where issues cluster, and how they shift. Even when you take no action, the accumulation sticks.
Periodic deep dive for planning
Every so often – quarterly, yearly – you must raise your head for long-term planning.
This is when the entire feature request pool turns into a goldmine.
That’s where AI can be extremely handy: Pull the lot, feed it to your favorite AI tool, and explore it to surface patterns and hidden gems.
Beware that this takes time, so make sure you prepare accordingly. The longer your planning horizon, the more time you should invest, while accepting that you will not finish the analysis.
The goal is not to sort everything perfectly. You are still using it as input. Look for the big signals, the themes that matter, and the few moves that change outcomes. Decide what to act on now, what to watch, and what to ignore until the signal grows.
Ongoing output – close the loop
Telling the field what is happening in our releases and roadmap should happen anyway, regardless of feature requests.
This should be done through ongoing communication – ideally, a product update meeting at a regular cadence (with or without more frequent written updates).
The feature requests pool comes in handy here if you want to provide evidence that what you do matters or help people understand that their voice is indeed heard and has made an impact.
A simple way to do that is to add to your update a list of the feature requests that were closed with this release, or even just the number and a few examples.
Remember, if they hear the update and it’s relevant to their customers, they don’t care about the ticket itself.
And so should you.
Feature requests are ticketed just as the tool. Stick to the essence to make everyone sane and happy.
