Find Feature Requests Across Public Discussions

Feature requests often appear in public long before they reach a support inbox. The useful part is the task and workaround behind the request, not the feature name alone.

This product feedback workflow builds a sourced queue for product staff to review.

SocialListeningAPI searches public posts on Reddit, LinkedIn, X, Hacker News, YouTube, and TikTok for the phrases you choose and returns normalized records with source URLs.

Step 1: List request and workaround phrases

Create a SocialListeningAPI account and claim the 100 free credits. Combine your brand and category with request language:

• wish product name had
• product name needs support for
• missing feature in product name
• workaround for product name
• category tool that can

Search the category too. People may describe the missing capability without naming your product.

Step 2: Search six public sources

for endpoint in \
  reddit/search-posts \
  linkedin/search-posts \
  x/search-posts \
  hackernews/search-posts \
  youtube/search-posts \
  tiktok/search-posts
do
  curl --get "https://api.sociallisteningapi.com/api/v1/$endpoint" \
    --data-urlencode 'query=category tool that can export reports' \
    --header 'x-api-key: YOUR_API_KEY'
done

One query across six sources costs 7 credits. Read the API documentation for the normalized response structure. Claude or ChatGPT can search through the MCP.

Step 3: Store the request and its job

Save source URL, platform, published date, request wording, product named, workaround, and user task in an external system. Use an external LLM to suggest a request type.

A product person must check the source and confirm what the person was trying to accomplish.

Step 4: Merge duplicates carefully

Group requests by the job, not only matching words. Export CSV and send data to a spreadsheet may describe the same job, while two requests for alerts may need very different behavior.

Count unique sources and keep representative examples. SocialListeningAPI does not maintain a product backlog or calculate request frequency.

Step 5: Review product feedback with product context

Compare each theme with current features, support tickets, strategy, effort, and known poor-fit requests. A repeated request is evidence for research, not an automatic roadmap decision.

Conclusion

Review the first queue with product and support staff before setting any priority. They can spot existing features, old information, and duplicate jobs.

Keep every backlog theme tied to source URLs, observed frequency, and the task people were trying to finish.

Continue with Find Onboarding Friction in Public Product Posts.

Written by ShashFounder at sociallisteningapi, focused on product and growth