Blog

Comment écouter les utilisateurs sans vous laisser submerger

1_Vignette_HD
Complément aux vidéos / La gestion de produit en pratique

Comment écouter les utilisateurs sans vous laisser submerger

Note de l'auteur

La conduite à tenir parait simple : il ne faut pas réaliser aveuglément les demandes utilisateurs. Sans quoi vous pourrez très vite vous laisser embarquer dans des développement produit qui vous feront perdre le nord et vous mettront la tête sous l’eau. Mais alors comment choisir de prendre en compte une requête plutôt qu’une autre ? Comment dire non aux utilisateurs ? Jean-Pierre Lambert, fort de son expérience, vous présente les différentes approches possibles et vous conseille sur la posture à adopter pour gérer les retours utilisateurs sans changer le cap de votre vision produit. Découvrez vite comment faire la différence entre une demande et un besoin !

Table des matières

Introduction

Que ce passe-t-il lorsque nous écoutons aveuglément les utilisateurs ?

Cela peut être le meilleur moyen de perdre la raison d’être de votre produit et de vous écarter de votre vision. Rappelez vous la citation de shawn Carolan :

Une startup ne meurt pas de faim elle se noie

Shawn Carolan
Photo Jean-Pierre Lambert

Bienvenu dans notre série la gestion de produit en pratique dans laquelle vous retrouvez les aventures de l’inspirante équipe Panda 🐼 qui monte chaque semaine en compétence. Comme elle, vous allez découvrir que les utilisateurs n’ont pas toujours raison et qu’il ne faut pas les écouter aveuglément. Abonnez-vous à la chaine et à activer les notifications pour ne rien rater de ses aventures. Je suis le créateur de Scrum Life que je coanime avec Constantin Guay. Nous sommes soutenus par toute une communauté que je vous invite à rejoindre pour grandir, échanger et monter en compétence.

Jean-Pierre Lambert

Etude de cas : les demandes utilisateurs gérées à la manière des tickets support

C’est assez naturel d’adopter cette approche notamment lorsque vous avez un passé technique. C’est aussi le meilleur moyen de partir dans tous les sens en oubliant sa vision et la cohérence du produit. Cette méthode ne vous permet pas d’appréhender les problèmes que les utilisateurs tentent de résoudre. Vous devez approfondir et trouver la raison de leurs demandes.

Prenons l’exemple de l’équipe Panda 🐼 : elle constate que de nombreux utilisateurs demandent un service de montage de meuble. Cherchons à comprendre quels besoins les utilisateurs souhaitent satisfaire. Nous pouvons trouver des centaines de raisons différentes et les quelques cases à cocher sur un formulaire ne pourront jamais vous les décrire. Pour les découvrir, nous devons revenir aux entretiens utilisateurs lors desquels les utilisateurs exprimeront peut-être qu’ils ne sont pas très à l’aise avec le bricolage et qu’ils ne possèdent pas les outils nécessaires au montage des meubles.

Portons notre attention sur les différences des retours utilisateurs :

  • Retour avec l’approche des tickets support : Je souhaite un service de montage de meuble.
  • Retour de l’entretien utilisateur : Je ne suis pas très à l’aise avec le bricolage et je ne possède pas les outils nécessaires au montage.

Dans le premier cas, nous ciblons directement un périmètre, une fonctionnalité. Dans le second, nous focalisons notre attention sur les réels problèmes et besoins de l’utilisateur ce qui nous ouvre des perspectives pour trouver les différents moyens d’y répondre. Le récit utilisateur (user story) est un très bon outil pour structurer cette approche qui consiste à :

  • Préciser le type d’utilisateurs auxquels nous nous adressons
  • Déterminer le problème fondamental que l’utilisateur cherche à résoudre et le gain qu’il en attend
  • Définir ce qu’il convient de mettre en place en conséquence des deux premiers points

Si vous souhaitez utiliser les récits utilisateurs comme un moyen de comprendre vos utilisateurs, visitez la formation Scrum Life qui traite précisément de ce sujet : construisez le bon produit plutôt que celui que vous voulez.

Quoi qu’il arrive vous n’échapperez pas à parler à vos utilisateurs ! C’est la clé !

La gestion des retours utilisateurs avec une approche « ticket support » n’est pas magique !

Pour commencer, enfonçons le clou en rappelant que vous recevrez forcément des demandes émanant d’utilisateurs qui ne correspondent pas à votre cible. Votre vision produit doit piloter vos décisions et déterminer le type d’utilisateurs que vous souhaitez contenter.

Non seulement l’utilisateur peut avoir une vision différente de la vôtre mais en plus il vous faudra assumer les conséquences de vos décisions : ajouter une fonctionnalité engage à la maintenir, la faire évoluer, l’intégrer à toutes les autres fonctionnalités du produit, accepter la complexité et les risques techniques inhérents, etc. Ajouter un élément qui semble simple cache souvent des coûts énormes. Un bon produit n’a ni besoin de plaire à tout le monde ni besoin de savoir tout faire. Ainsi, il sera probablement plus performant dans ce qu’il offrira et conservera son caractère différenciant.

Si vous êtes le leader sur le marché, le standard de fait, vous pouvez ne pas tenir compte de ce qui précède mais attention tout de même à ne pas vous faire surprendre par un nouveau venu…

Le choix d’implanter une nouvelle fonctionnalité est un calcul rationnel qui doit trouver sa motivation dans la vision produit. Celle-ci sera chalengée par les retours utilisateurs. Vous devrez d’une part savoir assumer pleinement votre vision et d’autre part, savoir accepter la rétroaction en changeant de cap si votre vision ne fait pas sens.

N’attendez pas passivement : Cherchez les raisons profondes des retours utilisateurs

Vous l’avez compris, il s’agit de réaliser ce dont l’utilisateur a besoin et non pas ce qu’il vous demande. Il existe de nombreux moyens de collecter l’avis des utilisateurs et nous pouvons les classer en deux catégories :

  • Qualitatif – le QUALI : Il s’agit par exemple des avis client sur les applications mobiles, de ce qu’il se raconte à propos de votre produit sur les réseaux sociaux ou encore des problèmes et demandes qui remontent au support utilisateurs. Ce dernier, qui vous place au plus près des utilisateurs, se révèle être très puissant.
  • Quantitatif – le QUANTI : Nous pouvons ici évoquer les tests A/B, l’approche MVP ou encore l’analyse des comportements utilisateurs via la mise en place d’un plan de marquage. Nous avons abordé ces notions et outils en détail dans l’épisode Comportement utilisateur et son article compagnon Pourquoi mesurer vous aide à comprendre vos utilisateurs ?

Nous cherchons à obtenir les deux aspects : qualitatif et quantitatif. L’un sans l’autre ne vous donnera qu’une vision tronquée. Vous devez être acteur de la gestion de votre produit. Product Owner et Product Manager sont de vrais métiers qui demandent d’investir du temps. Il vous faudra sûrement fournir des efforts particuliers pour bien comprendre les besoins de vos utilisateurs et cela commence par aller à leur contact. Rassurez-vous, cela s’apprend, mais vous comprendrez aisément qu’être Product Owner ou Product Manager avec deux heures par semaine est tout simplement impossible. Il vous faudra prendre le temps de construire votre expertise, d’écouter les retours utilisateurs, et de contextualiser les demandes en prenant du recul pour déterminer leurs raisons profondes.

Comment utiliser les retours utilisateur ?

Répétons-le encore une fois : les retours utilisateurs doivent être considérés comme des données et surtout pas comme des demandes auxquelles il faudrait répondre à tout prix. C’est aussi pour cette raison que nous ne les intégrons jamais directement dans le backlog produit qui sera plutôt alimenté par des hypothèses.

Les demandes d’utilisateurs nous permettent avant tout de :

  • Comprendre le fonctionnement des utilisateurs, d’identifier des problématiques concrètes et de se projeter dans les solutions à mettre en place. Elles seront également une source d’inspiration.
  • Trouver les hypothèses à formuler dans le backlog produit.
  • Chalenger le niveau de certitude que nous accordons à nos hypothèses. La quantité de retours vous donnera une indication sur la pertinence de vos hypothèses mais cela ne vous dispensera pas de les tester.
  • Factualiser pour nous permettre de prioriser nos actions, en faisant le rapport entre d’une part le niveau de certitude et d’autre part le gain attendu.

Assumez votre vision et communiquez vos décisions !

Dans cette vidéo, nous avons passé le plus clair de notre temps à expliquer pourquoi il ne fallait pas réaliser à l’aveugle ce que les utilisateurs vous demandent. Il vous faudra donc trouver des solutions pour leur expliquer. Il s’agit de vivre, et d’assumer pleinement, cette posture de l’approche produit. Le plus gros risque serait de ne pas communiquer sur votre stratégie, sur les raisons de vos décisions.

Alors pour réussir votre communication, soyez clair avec votre plan de route et informez sans attendre vos utilisateurs surtout si vous savez que vous ne prendrez pas en compte leur demande qui viendrait en contradiction avec votre vision.

Bien sûr vous ferez des mécontents mais s’agit-il vraiment d’utilisateurs qui correspondent à votre vision, à votre cible ?

Soyons parfaitement honnête, lorsqu’une demande ne vous permet pas de vous rapprocher de votre vision, vous n’avez que trois options !

  • Vous développez votre produit de manière à répondre à la demande alors que cela vous éloigne de votre vision. En vous engageant dans cette voie, vous renoncez à travailler sur autre chose qui vous rapprocherait de votre vision. Rappelez-vous de cette citation attribuée à André Gide :

Choisir c’est renoncer

André Gide
  • Vous indiquez clairement que vous ne donnerez pas suite à la demande de l’utilisateur. Vous devrez alors lui expliquer les raisons en assumant votre vision produit et, pourquoi pas, en leur faisant savoir que ce produit n’est pas pour lui.
  • Vous décidez de ne pas agir et n’informez pas l’utilisateur. Vous pensez que l’ignorance est une bonne option et un gain de temps ? Vous vous méprenez. Cela vous demandera bien plus de temps que de leur répondre car il vous faudra gérer l’affluence des demandes d’utilisateurs qui aurons le sentiment de ne pas être compris. Cette situation est particulièrement contreproductive car elle vous éloignera de votre vision sans parler de l’image de votre produit qui pourra en pâtir lourdement.

Soyons clairs, seule la deuxième option est pertinente ! C’est la seule option qui vous permet de ne pas perdre de temps et rester concentré sur votre vision. Assumez votre vision !

Glossaire

Backlog produit (product backlog)

Élément du cadre de travail Scrum. Une liste d’options envisagées pour l’avenir du produit.

MVP (produit minimum viable – PMV en français)

Un produit minimum viable est la version d’un produit qui permet d’obtenir un maximum de retours client avec un minimum d’effort.

Product Manager - chef de produit

En charge du succès d’un produit, au travers de la recherche marché, des études utilisateurs, du positionnement et de la stratégie du produit.

Product Owner

Élément du cadre de travail Scrum. Le ou la Product Owner apporte la vision produit, la vision marché, et l’alignement avec les objectifs d’entreprise (rentabilité par exemple).

Récit utilisateur (User story)

Une expression du besoin et du gain attendu d’un groupe d’utilisateur exprimés avec ses mots.

Test A/B

Mise en concurrence de deux versions du produit pour découvrir objectivement quelle option est la meilleure.

Faites votre veille : Sources et liens complémentaires

Vous avez aimé cet article ?

Alors vous allez adorer

Le guide du Scrum Master compétent

Entrez votre adresse mail pour rejoindre la liste d'attente :