How to reply to a public feature request
A feature request in public is not a demo request. Someone is asking a product they already use — or a community they trust — for a capability. If you have that capability, the temptation is to say 'we do this, link.' That is how you train people to hide feature requests from vendors. The useful reply treats the request as a spec: what job, what workaround, what 'done' looks like. If your product already does it, you may say so with disclosure and a constraint ('only if your docs are in git'). If it does not, you can still be useful by describing how other people fake it. PainHuntr will surface these as asking or discussing; this playbook is for the asking version where they want the job done, not a roadmap debate.
When this is real
It is real when they describe a missing job with enough detail to ship: 'I need the unsubscribe to hit Shopify customers tagged X,' 'I need SSO that does not require the enterprise plan,' 'I need the YouTube description to pull chapters from the edit.' GitHub issues, changelog comments, and 'if only X did Y' tweets count. The person is usually a current user of something, which means they have switching costs. That is good — if you respect the workaround they already have.
When to skip
Skip vague 'please add AI.' Skip feature-voting boards where vendors are banned. Skip requests that are clearly a unique enterprise one-off unless you sell that. Skip if you are going to say 'coming soon' with no date — that is a trap for both of you. And skip if the request is on a competitor's official forum where only customers and staff are allowed to post; that is trespassing, not outreach.
The angle
Treat the request as a spec. Clarify the job and the workaround. Mention your product only if it already does that job, with disclosure and a constraint. Never say 'book a call and we'll scope it.'
How to reply
- 01
Turn the wish into a job
Ask what they do today when the feature is missing. Spreadsheets, Zapier, a VA, a script. That workaround is the real requirement. If you cannot name the workaround, you do not understand the request yet, and any product mention will be wrong.
- 02
Say whether it already exists — somewhere
Sometimes the feature exists in a setting, an app, or a fork. Pointing at that is more useful than a pitch. If you are wrong, they will correct you, which is still a conversation. If you are right, you just saved them a migration they did not want.
- 03
Disclose a fit, not a roadmap
If your product already does the job, one sentence with disclosure and a limit. If it does not, do not promise it. Public feature-request threads are full of founders who promised a thing they never shipped. That reputation follows you into the next subreddit.
- 04
Leave a breadcrumb they can verify
A changelog entry, a docs heading, or a two-step recipe beats a landing page. People in feature-request threads are trying to get work done today. If they have to sit through a homepage animation, you lost. If they ask for an invite, then you can continue — still in public if the community prefers it.
Example replies
Same thread, three outcomes. PainHuntr drafts toward the first one and away from the other two.
- Good
If the job is 'tag comes back from the ESP into Shopify without a sheet,' the usual workaround is a webhook into a Flow. I make a returns app that already writes the restock tag — disclosing — but only if you are not on the old checkout. If you are, the Flow path is less painful than switching apps this week.
It names the job, the workaround, a constraint, and a disclosure. They can ignore the product and still use the comment.
- Too salesy
We are actually building this right now. Join the waitlist and you will get early access plus a lifetime discount. Would love your input on a discovery call.
A waitlist is not a reply to a feature request. You just asked them to do product work for you. They wanted the job done, not a survey.
- Gets you banned
Posted this on our competitor's community because they will never ship it. Install us instead, here's a crack for their export: mega.nz/...
Trespassing on another vendor's forum plus piracy. That is a ban, a possible legal letter, and a screenshot that never dies.
Gotchas
- Do not harvest feature-request threads as a public roadmap for your competitor. It reads as stalking.
- 'Coming soon' without a date is worse than silence. People will quote it when you miss.
- YouTube comments under 'I wish this editor did X' are feature requests. Same rules. No 'we have an AI that does this' without a proof clip.
- If the request is a GitHub issue, follow that repo's contributing guide. A sales comment on an issue is a special kind of hated.
Frequently asked questions
What if I could build the feature next week?
Still do not promise it in their thread. Build it, ship a changelog, then reply with a link to the shipped thing and a disclosure. Feature-request audiences have been burned by vapor. The comment can wait a week. The reputation cannot.
Is a feature request the same as a recommendation request?
No. Recommendation is 'what tool should I use.' Feature request is 'this tool I already have should do X.' You are talking to an incumbent's customer. Switching costs are higher. Be more conservative about the pitch.
Can I ask them to star a GitHub issue?
Only if it is the same issue they described and you are not using their pain as a growth hack. Begging for reactions on someone else's request is rude. If you maintain the project, a normal 'tracked in #123' is fine.
What about changelog comment threads?
Those are closer to support. If they asked for a feature you just shipped, a terse 'this shipped in 1.4, here's the setting' is perfect. If you ship a competitor, stay out of their changelog.
How would PainHuntr draft this?
Clarify the job, do not offer a walkthrough, mention the product only if it maps to what they named, disclose in the same sentence. Same family as the recommendation draft, with extra respect for the incumbent they already pay.
Related playbooks
Find the threads first
Reading 1,000 threads a month doesn't scale. PainHuntr does.
Paste your product URL. PainHuntr finds the conversations on Reddit, X, Hacker News, YouTube, and review sites — then helps you reply, track what worked, and do it again.
Join the waitlist to get early access and help shape the product.