What product feedback means
Finding what people wish your product did — feature requests, comparisons that name a missing capability, and the workarounds people build because something is absent.
GitHub · Product feedback
Monitor GitHub for product feedback
Feature requests filed as issues on other people’s repositories, and the forks and wrappers built around what your product is missing.
[01] THE JOB/ PRODUCT FEEDBACK
What it looks like on GitHub
GitHub feedback arrives as code. Somebody wanting something you do not have writes a wrapper, forks a client, or opens an issue on a library that integrates with you asking for support you have not shipped. All three are feature requests with a working reference implementation attached, which is the most detailed form feedback can take. The other shape is the comparison in a README or an awesome-list, where your absence from a feature table is itself the feedback.
What GitHub will not give you
GitHub rewards a technical answer and punishes a marketing one. This is the platform where the reply register matters most — FishOut drafts in a technical register here and still never posts for you.
What FishOut collects from GitHub
Issues and pull requests whose title or body matches, with the repository name attached.
[02] WHAT TO TRACK/ KEYWORDS
Keyword shapes for product feedback on GitHub
A keyword tuned for this job on another platform is usually silent here, because the same person writes differently in each place. The example beneath is read the way FishOut reads one: a relevance bar and the label it would carry.
keywords · github
your package name plus wrapper language
"wrapper", "client", "unofficial", "sdk". Somebody building a client you did not ship is telling you which interface is missing.
your name plus "support for"
Issues asking a third-party library to support something of yours, which is demand routed around you rather than to you.
your name in comparison tables
Feature matrices in READMEs and awesome-lists. Being marked as lacking something, accurately, is feedback with an audience.
GitHub — issue on a third-party repo76Any plans to support AcmeMail webhooks here? Wrote a small shim to bridge it because their API has no batch endpoint, happy to upstream.
Feature request · your label[03] HOW TO SET IT UP/ VIEWS & ROUTING
The configuration that works here
A relevance floor of 55, labelled with your Feature request label and assigned to whoever owns the roadmap rather than to support. Unlike the bug-report cell, this one wants aggregation rather than urgency — but a wrapper or shim is worth reading immediately when it appears, because somebody has just done unpaid design work on your product.
And what to do with what arrives
Labelled and collected rather than answered immediately — describe a label such as "Feature request" and the AI applies it, then save the view. This is the one job where the value is in the aggregate rather than the individual mention.
[04] THE COMMON MISTAKE/ AVOID THIS
Filing wrappers as bugs
Somebody who has written an unofficial client or a shim has not reported a problem, they have done unpaid design work on your product and told you exactly which interface is missing. Routed into the bug queue it gets triaged as “working as intended” and closed, and the most detailed feature request you will receive that quarter disappears.
Questions
Other jobs on GitHub
Product feedback on other platforms
Reddit
YouTube
TikTok24 of a possible 40. A job and a platform only make a page when the intersection has something true of it alone.