Cet article a été traduit depuis l’anglais. Cliquez ici pour accéder à la version originale. 

La collecte de retours utilisateurs guide tout ce que nous entreprenons chez Livestorm. Ils offrent la possibilité à nos clients de prendre part activement au développement de notre produit tout en nous permettant de prendre des décisions éclairées. En d’autres termes, c’est une situation qui profite à tous. 

Vous le savez peut-être déjà, mais Livestorm a débuté comme un projet de fin d’études à l’HETIC. Moins de cinq ans plus tard, nous avons célébré notre série B de plus de 30 millions de dollars et nous sommes entrés dans la liste du Financial Times des startups à la croissance la plus rapide en Europe. Depuis le premier jour, notre succès repose en grande partie sur la collecte des retours utilisateurs.

Au départ, nous enregistrions les retours de nos clients dans un simple tableur. Mais au bout d’un an, il était clair que nous devions passer à la vitesse supérieure pour continuer à croître et rester organisés. Le passage à Productboard a changé la donne, et nous a permis d’absorber une quantité de plus en plus importante d’informations. Aujourd’hui, nous recueillions environ mille retours utilisateurs chaque mois. 

On me demande souvent comment nous gérons un tel nombre de retours, alors j’ai pensé que c’était l’occasion idéale pour vous partager notre méthode. Vous trouverez également un modèle gratuit à la fin de cet article pour analyser l’évolution de votre collecte de retours utilisateurs. 

Comment placer les retours utilisateurs au centre de son process de discovery ? 

Avant d’entrer dans le détail, précisons que les retours utilisateurs ne constituent qu’une petite partie de notre process de discovery. L’élaboration et la priorisation de notre roadmap produit nécessitent un mélange de recherche générative, de recherche évaluative, d’analyse de marché, de R&D, etc.

Il s’agit d’un sujet très vaste, qui mérite au moins plusieurs autres articles. Aujourd’hui, je me concentrerai donc uniquement sur la façon dont nous recueillons les retours utilisateurs chez Livestorm.

Diversifier ses sources de retours

Recueillir des retours utilisateurs de manière organisée peut s’avérer délicat, particulièrement quand ces informations proviennent de sources différentes. Sur l’ensemble des informations collectées, environ 75 % sont générées par des conversations directes avec nos utilisateurs et nos prospects. Les 25 % restants sont collectés de manière totalement automatique – par exemple, à partir des commentaires collectés avec le NPS, lors du désabonnement ou sur notre portail Ideas (dont je parlerai plus en détail par la suite).

Repartition des insights

Une vue d’ensemble des sources de nos retours utilisateurs.

Faire participer ses équipes 

La collecte de retours utilisateurs est un véritable travail d’équipe et les Stormies (le nom donné aux employés de Livestorm) sont en première ligne. Cela fait d’ailleurs partie intégrante de leur formation lorsqu’ils rejoignent l’entreprise (si vous souhaitez en savoir plus sur l’onboarding en général chez Livestorm, ma collègue Laure a écrit un excellent article à ce sujet).

Lorsqu’un utilisateur nous demande une fonctionnalité ou rencontre un problème quelconque avec notre produit, notre équipe retranscrit son retour directement dans Productboard. Ces retours sont ensuite rattachés à la fonctionnalité concernée. Et en cas de doute, ou si la fonctionnalité n’existe pas encore sur Productboard, notre équipe produit intervient pour conseiller les équipes opérationnelles. 

Il est important de noter que ce qui est appelé  “Features” sur Productboard ne sont en réalité pas toujours des fonctionnalités. Il s’agit souvent de catégories plus larges. Par exemple, nous avons une seule fonctionnalité sur Productboard intitulée “Meilleure bibliothèque de médias”, qui recouvre en réalité les fonctionnalités : “possibilité de renommer un média”, “possibilité de créer des dossiers de médias”, “possibilité d’ajouter des balises aux médias”, etc. Cette façon de faire nous permet de rester concentrés sur les problèmes et frictions de nos utilisateurs plutôt que de nous lancer trop tôt dans la recherche d’une solution potentielle.

Un exemple de la façon dont un retour utilisateur est lié à la fonctionnalité pertinente.

Un exemple de la façon dont un retour utilisateur est lié à la fonctionnalité pertinente.

Gamifier la collecte des retours utilisateurs 

La gamification a contribué à rendre l’ensemble du processus plus amusant et moins fastidieux pour les Stormies. Chaque mois, nous organisons un concours pour savoir qui a collecté le plus de retours. Bien qu’il n’y ait pas de prix réel pour celui qui recueille le plus de commentaires, l’annonce sur Slack et les nombreuses réactions qui suivent apportent aux gagnants une véritable reconnaissance à l’échelle de l’entreprise.

La gamification a contribué à rendre l’ensemble du processus plus amusant et moins fastidieux pour les Stormies. Chaque mois, nous organisons un concours pour savoir qui a collecté le plus de retours. Bien qu’il n’y ait pas de prix réel pour celui qui recueille le plus de commentaires, l’annonce sur Slack et les nombreuses réactions qui suivent apportent aux gagnants une véritable reconnaissance à l’échelle de l’entreprise.

L’annonce sur Slack des résultats de notre concours mensuel Productboard.

Les managers des équipes Sales & Customer Support jouent également un rôle clé pour maintenir la motivation. Pour cela, nous avons également introduit un objectif de taux de retour pour les équipes opérationnelles.

Ces équipes ont actuellement un taux de retour d’environ 20 %, ce qui signifie que 20 % des tickets fermés contiennent un retour qui est envoyé dans Productboard. L’utilisation d’un taux de retour comme indicateur de performance, plutôt que de se concentrer sur le nombre de retours générés, permet d’éviter une vision biaisée, notamment lorsque les Stormies prennent des congés et recueillent ainsi moins d’informations.

Simple “vote” ou retour détaillé : quel type de retours collecter ? 

Nous recevons deux types de retours de la part de nos clients. Les “votes” correspondent essentiellement à la demande de fonctionnalité en elle-même, puis nous recueillons des informations plus détaillées et plus contextuelles. Chaque type a ses avantages et ses inconvénients en fonction de la fonctionnalité et du nombre de retours à traiter.

Votes vs. retours détaillés 

Bien que les votes soient très pratiques pour voir quelles fonctionnalités sont les plus demandées, le manque de détails supplémentaires peut avoir ses inconvénients. Par exemple, beaucoup d’utilisateurs nous demandent la fonctionnalité “Événements payants” parce qu’ils veulent avoir la possibilité de faire payer les personnes inscrites à leur événement. Cela semble être une fonction plutôt simple, non ?

En réalité, il s’agit d’un projet beaucoup plus vaste qu’il n’en a l’air de prime abord. Il faut également tenir compte des modes de paiement, de la facturation, de la gestion des codes de réduction, des remboursements, des différents types de tickets, et la liste est encore longue. Sans des retours détaillés, il est assez difficile d’estimer l’ampleur réelle d’une fonctionnalité ainsi que les ressources et le temps nécessaires à sa mise en œuvre.

Une démarche itérative

Au départ, nous avons pensé que le plus logique était de confier à nos équipes opérationnelles la tâche de demander plus de détails aux clients. Mais nous avons vite compris que cette approche n’était pas non plus très claire. Nos équipes se sentaient un peu perdues, ne savaient pas quelles questions poser et si elles posaient les bonnes questions. Pour résoudre ce problème, nous avons décidé de construire un framework et d’introduire de courtes enquêtes pour chaque fonctionnalité. 

Notre solution : les formulaires

L’utilisation de formulaires nous a permis de recueillir des retours de meilleure qualité de la part de nos utilisateurs. Pour nos 20 fonctionnalités les plus demandées (ou problèmes utilisateur), nous avons créé des formulaires spécifiques auxquelles il faut moins de 3 minutes pour répondre. Ces enquêtes sont “evergreen”, ce qui signifie que nous les mettons à jour tout au long de notre phase de discovery et que nous ajoutons continuellement de nouveaux formulaires au fur et à mesure.

Nous essayons de présenter à nos utilisateurs nos courts formulaires comme un moyen de “voter” pour une fonctionnalité, afin de leur faire comprendre que leurs retours peuvent avoir un impact réel sur notre roadmap. Pourtant, il arrive que nos utilisateurs soient réticents à l’idée d’y répondre. Quoi qu’il en soit, s’ils demandent une fonctionnalité sans nous fournir plus de détails et ne veulent pas remplir le formulaire. Nous envoyons quand même ces informations dans Productboard pour qu’elles soient prises en compte.

Le fait de commencer par des questions très ouvertes nous aide à limiter les biais. Aussi, nous demandons aux utilisateurs de définir le degré d’importance de chaque “sous-fonctionnalité”. Cela nous aide à définir ce à quoi doit ressembler la première version de la fonctionnalité.

exemple de questionnaire

Pour éviter les biais, nous commençons toujours par une question très générale dans nos formulaires.

exemple de questionnaire

Nous affinons ensuite nos questions afin de recueillir des données plus structurées.

Ideas, le portail unique pour faire participer nos utilisateurs au développement du produit 

Notre portail Ideas permet à nos utilisateurs de voter pour leurs fonctionnalités préférées, de participer à des recherches utilisateur en testant des prototypes ou de s’inscrire à des bêtas privés. Tous les retours générés sur ce portail sont transmis dans Productboard. Il y a encore de nombreuses améliorations à venir, mais notre objectif est d’en faire le guichet unique pour faire participer nos utilisateurs au développement de notre produit.

Ce portail permet également à l’ensemble des équipes de Livestorm d’améliorer la collecte de retours clients. Par exemple, notre équipe Marketing en fait la promotion sur notre site web, tandis que notre équipe Growth l’inclut à nos e-mails de nurturing et que l’équipe Produit le partage directement dans notre produit.

Disposer d’un lien facile à mémoriser (ideas.livestorm.co) permet de le partager facilement à un client chaque fois qu’il demande une fonctionnalité. Lorsqu’un client demande une fonctionnalité lors d’un appel avec son Customer Success Manager, ce dernier peut simplement se rendre sur le portail et remplir un questionnaire à la place du client. Le formulaire agit alors comme un framework d’interview.

Voici un aperçu du portail Ideas de Livestorm.

Tous les retours comptent

Soyons réalistes : notre portail Ideas et Productboard ne remplacent pas la conduite de véritables entretiens avec nos utilisateurs, et nous aurons toujours besoin d’avoir des conversations qualitatives avec nos clients. Mais lorsque vous avez des dizaines de milliers d’utilisateurs actifs chaque mois, vous devez adopter une approche démocratique et donner à chacun une chance d’être entendu. 

Sans compter que cela permet de lutter contre le biais du “le dernier client auquel j’ai parlé a raison”. C’est très similaire à la vision de Maze sur la “continuous research” et le “rapid testing” avec leur approche quantitative de la recherche utilisateur ou la “continuous discovery” de Teresa Torres.

Chez Livestorm, nous nous sommes toujours efforcés de tout rendre infiniment évolutif et d’automatiser autant que possible. Cette approche nous a permis d’absorber la multiplication par 20 de l’utilisation que nous avons connue au cours des premiers jours de la pandémie. Tout en continuant à recueillir des commentaires précieux ! Dans cet article, je n’ai pas détaillé comment nous avons automatisé tout cela, mais n’hésitez pas à me contacter via LinkedIn si vous voulez en savoir plus (cela inclut un peu de magie entre Zapier, Typeform et Customer.io).

Bonus : une Google Sheet pour analyser votre collecte de retours sur Productboard

Voici un modèle de Google Sheet que vous pouvez utiliser pour analyser l’évolution de votre collecte de retours Productboard. Nous utilisons une version plus détaillée en interne avec un “taux de retour” pour chaque équipe et chaque Stormie. De cette façon, nous pouvons comprendre combien de conversations avec les clients, sur 100, aboutissent à la collecte d’informations. 

En voici un aperçu :

Voici un aperçu du Google Sheet pour suivre votre collecte de retours sur Productboard