Comment recueillir des retours produit et des demandes de fonctionnalités sur Reddit, X et Hacker News

Pourquoi les canaux de retours habituels passent à côté

La plupart des équipes recueillent des retours à partir de trois sources : les tickets de support, un widget in-app et les appels commerciaux. Toutes trois présentent le même biais : elles n'entendent que les personnes qui dialoguent déjà avec vous.

Les discussions publiques sont différentes. Quelqu'un qui a résilié son abonnement le mois dernier ne répondra pas à votre enquête, mais expliquera volontiers sur Reddit les raisons de son départ. Un prospect qui compare différents outils listera ce qui manque au vôtre dans un post demandant « lequel devrais-je choisir ? ». Ce sont des retours impossibles à obtenir autrement, et ils s'accompagnent souvent de réponses d'autres utilisateurs qui confirment ou nuancent le propos, vous indiquant ainsi l'ampleur réelle du problème.

La difficulté réside dans le volume. Si vous recherchez le nom de votre produit une fois par semaine, vous trouverez une poignée de fils de discussion, généralement trop tard pour y répondre. Si vous configurez une alerte brute sur votre nom, vous recevrez chaque mention, y compris celles qui n'ont aucun rapport avec le produit. L'astuce consiste à rédiger des alertes ciblant spécifiquement les retours.

Rédiger des alertes ciblant les retours

Une alerte KWatch filtre chaque mot-clé de sa liste, les virgules fonctionnant donc comme un ET logique (AND). C'est ce qui fait l'efficacité des alertes de retours. Au lieu d'une seule alerte sur le nom de votre produit, vous associez ce nom aux termes employés lorsque les utilisateurs souhaitent une modification.

Voici une sélection de départ, où « acme » représente le nom de votre produit :

1. acme, wish et acme, would be nice pour les demandes de fonctionnalités
2. acme, bug et acme, broken pour les signalements de bugs
3. acme, switched et acme, cancelled pour les motifs d'attrition
4. acme, missing et acme, doesn't support pour les lacunes constatées lors des phases d'évaluation

Chaque ligne correspond à une alerte distincte, car une alerte regroupant tous ces termes exigerait qu'ils figurent tous dans une même publication. Vous ajusterez probablement la formulation après une semaine, une fois habitué au vocabulaire de vos utilisateurs. Les internautes écrivent rarement les termes « feature request », cherchez plutôt des expressions spontanées comme « would be great if » (ou « ce serait bien si »).

Quelques filtres suffisent pour éliminer l'essentiel du bruit. Sur Reddit et Hacker News, activez l'option Mots entiers uniquement si le nom de votre produit est court ou courant, afin qu'« acme » ne corresponde pas à « acmeplex ». Ajoutez les comptes de votre propre équipe en Utilisateurs exclus pour éviter que vos réponses et annonces de lancement ne déclenchent d'alertes. Si vous disposez d'un subreddit dédié à votre produit, vous pouvez créer une alerte spécifique limitée à celui-ci via les Subreddits inclus et supprimer le second mot-clé, puisque presque tout ce qui y est publié constitue déjà un retour.

Les mots-clés exclus fonctionnent à l'inverse des mots-clés inclus. Les mots-clés inclus doivent tous correspondre, mais une publication est écartée dès que l'un des mots-clés exclus apparaît. Gardez cette liste courte et précise, sous peine d'éliminer de véritables retours en même temps que le bruit. Notre article sur la réduction du bruit dans les alertes par mot-clé passe en revue chaque filtre plus en détail.

Où écouter en priorité

Toutes les plateformes n'apportent pas le même type de retours. Je trouve que Reddit et Hacker News sont les endroits où les utilisateurs rédigent des critiques longues et détaillées. Sur X, les messages sont plus courts et plus vifs, ce qui est utile pour repérer rapidement une mise à jour défectueuse. LinkedIn regroupe principalement des éloges et des annonces ; il figure donc plus bas dans cette liste, à moins que vos clients ne publient au sujet de leurs outils sur ce réseau.

La vitesse varie également selon les plateformes, ce qui influe sur l'utilisation de chaque alerte. Voici les fréquences d'actualisation indiquées dans notre documentation :

Pour des retours produit, aucune de ces vitesses n'est lente. Ce tableau indique qu'un fil Hacker News peut vous parvenir alors qu'il est encore en page d'accueil, c'est-à-dire au moment où une réponse d'un membre de l'équipe a le plus d'impact.

Transmettre les retours à l'équipe produit

Une alerte que personne ne lit n'est rien d'autre qu'une recherche plus agréable. L'étape que les équipes négligent souvent consiste à décider où arrivent ces retours et qui les consulte.

La configuration la plus simple est un canal Slack dédié. KWatch vous permet de définir un webhook Slack par alerte, et un webhook propre à une alerte prévaut sur celui défini au niveau du compte. Vos alertes commerciales peuvent ainsi continuer d'arriver dans le canal commercial, tandis que les alertes de retours rejoignent par exemple #product-feedback. Les chefs de produit et développeurs qui souhaitent simplement consulter les retours peuvent rejoindre votre équipe KWatch avec le rôle Lecteur (Reader), qui reçoit les notifications sans pouvoir créer ni supprimer d'alertes.

Si vous souhaitez quantifier les demandes dans le temps, envoyez plutôt ces alertes vers un webhook d'API. Chaque correspondance arrive sous la forme d'une charge utile JSON. Voici l'exemple issu de notre documentation :

{
  "platform": "reddit",
  "query": "Keywords: vllm",
  "datetime": "19 Jan 24 05:52 UTC",
  "link": "https://www.reddit.com/r/LocalLLaMA/comments/19934kd/sglang_new/kijvtk5/",
  "author": "lmzoo",
  "content": "sglang runtime has a different architecture on the higher-level part with vllm.",
  "sentiment": "neutral"
}

Dirigez ce webhook vers Zapier ou n8n et ajoutez une ligne dans une feuille de calcul, avec une colonne par champ. Le champ query indique quelle alerte s'est déclenchée, ce qui permet de trier automatiquement demandes et bugs. Le champ sentiment (positif, négatif ou neutre) permet d'isoler rapidement les messages les plus critiques. Nous avons détaillé la configuration de Zapier et n8n étape par étape si vous n'en avez jamais connecté auparavant.

Les alertes par e-mail fonctionnent aussi, mais les longs messages y sont tronqués. Les demandes de fonctionnalités étant souvent détaillées, Slack ou un webhook constituent une solution bien plus adaptée.

Que faire des informations recueillies

Une fois les retours enregistrés, la tentation est de répondre à tout. Je vous conseille d'être mesuré. Une réponse courte et utile émanant d'une personne travaillant visiblement sur le produit (« c'est sur notre feuille de route, voici une solution de contournement en attendant ») fait une excellente impression. En revanche, une série de réponses se terminant systématiquement par un lien d'inscription vous vaudra des votes négatifs, voire un bannissement sur certains subreddits.

L'habitude la plus précieuse reste la revue hebdomadaire. Une fois par semaine, un membre de l'équipe produit parcourt le canal ou le tableau et étiquette chaque élément : demande, bug, motif d'attrition ou non pertinent. Au bout d'un mois, vous aurez une estimation précise de ce que les internautes réclament en public, comparé à ce qu'ils demandent via les tickets. Lorsque les deux listes divergent, c'est généralement là que se trouvent les enseignements les plus intéressants.

Si certains de vos retours les plus utiles proviennent d'une poignée de personnes identifiées (utilisateurs avancés, analystes, fondateur d'un concurrent) plutôt que de mots-clés, notre produit frère MultiFollow suit des comptes LinkedIn et X spécifiques et vous alerte dès qu'ils publient, ce qui complète idéalement les alertes par mot-clé.