Le blog des décideurs du digital sur toutes les tendances tech, architecture, organisation et produit

Comment bêta-tester son produit pour assurer son adoption ?

En octobre dernier, en tant que Lead PM pour Bpifrance, j’ai contribué à la mise en production d’un nouveau parcours visant à optimiser le temps des collaborateurs sur la banque en ligne. Concrètement, nous avons automatisé jusqu’à 6 étapes, permettant un gain de temps moyen de 1h15 par acte de gestion.

Notre démarche : dérisquer l’adoption de notre produit en lançant un pilote auprès de 20 collaborateurs sur plusieurs mois.

Un succès apparemment ? Pas du tout ! Après 7 mois et 12 actes de gestion validés sur notre plateforme, on reçoit un NO-GO des responsables qui prolongent le pilote de 3 mois. Grosse déception…

On a cherché à comprendre d’où venaient nos erreurs ; pendant le cadrage ? Le déroulé ? La généralisation ? Réponse : les 3 mon capitaine !

On en a profité pour capitaliser sur nos apprentissages en identifiant des points de contrôles pour le futur.

Ça commence par la mise en place du pilote :

  • Optez pour un pilote à chaque mise en service de fonctionnalités ou de parcours qui génère des changements significatifs dans le quotidien des utilisateurs,
  • Appliquez un pilote aux produits permettant de cibler spécifiquement les utilisateurs destinés à tester, et envisagez l'utilisation de "feature flags" d'un point de vue technique.

Et dans quel but ?

  • Pour tester en avant-première des parcours ou des fonctionnalités clés avant leur déploiement à grande échelle,
  • Rassembler des retours d'utilisateurs afin de comprendre leurs préférences et les obstacles potentiels alimentera un ensemble d'améliorations potentielles.
  • Obtenir le soutien de promoteurs qui convaincront les autres des avantages de la fonctionnalité.

 

1. Cadrage

Notre première erreur a été de n’avoir défini que des objectifs quantitatifs sans repères temporels. En leur absence, il était difficile pour nous de mesurer la progression et l'efficacité du pilote au fil du temps, mais aussi d’être réactifs pour corriger des points bloquants pour les utilisateurs avant la généralisation.

Avoir une durée limitée permet de faire un point d’étape et de se reposer les bonnes questions.

Définir et valider des objectifs quantitatifs et qualitatifs avant le démarrage du pilote est essentiel. Dans notre cas, nous avions des signaux contradictoires : un objectif quantitatif atteint mais un NPS des collaborateurs négatif. Sauf que le NPS n’était pas identifié comme un de nos objectifs ce qui ne nous a pas alerté sur le risque d’adoption de notre parcours.

Notre dernière erreur sur la phase de cadrage a été de ne pas suffisamment impliquer les managers d’équipes qui étaient pourtant décisionnaires. La clé c’est de valider au départ avec les décisionnaires des conditions qui permettront la généralisation du pilote.

Comment ? Avec un Kick-Off au début du pilote pour valider le déroulé, et des points d’échanges dédiés pour partager les avancements et capter leurs préférences.

 

2. Déroulé

La 2ème étape du processus implique de recueillir des retours pertinents pendant la durée du pilote afin d’améliorer le produit. L'un des points clés est de se rendre sur le terrain, profitant de toutes les occasions pour rencontrer les utilisateurs et observer leur interaction avec notre produit. Malheureusement, nous avions lancé des sessions d’interviews au début, et une fois l’objectif atteint mais jamais pendant le déroulé. Nous nous sommes retrouvés à la fin du pilote avec une montagne de retours à prendre en compte qui bloquait la généralisation.

La disponibilité des collaborateurs et le quotidien des équipes produit vont par définition toujours vous pousser à déprioriser l’animation du pilote par rapport au reste. Nous recommandons donc de prévoir des points de passage dans les agendas dès le cadrage pour éviter cette situation.

Lors des analyses qualitatives, nous n’avions pas creusé pourquoi nous avions un NPS négatif car le volume de répondant était tellement faible que nous pensions qu’il n’était pas représentatif. Mais si ces NPS sont là c’est justement pour capter les signaux faibles ! Si pas de répondants, c’est peut être que votre parcours n’est pas utilisé OU qu’il y a autre chose qui se cache.

Il faut toujours définir plusieurs indicateurs de santé et interroger les répondants aux NPS qu’ils soient positifs ou négatifs. C’est grâce à cela que nous creusons les vrais sujets.

 

3. Généralisation

Ce qui nous a manqué ici a été énoncé plus haut : la connaissance de nos décideurs et la validation des conditions qui permettent de généraliser en amont.

Si toutes les étapes précédentes ont bien été réalisées, un sponsorship d’un décideur sera facilement atteignable. Pour clore une phase pilote, il est important pour les sponsors :

  • de se projeter sur la suite en ayant une roadmap claire des évolutions à venir,
  • d’avoir des résultats à communiquer,
  • et surtout de voir le gain et la valeur qu’on apporte grâce à notre parcours.

Un pilote permet aussi de valider les points clés à mettre en valeur pendant la généralisation et de préparer le go-to-market de notre fonctionnalité.

 

4. Résultats

Nous avons retravaillé notre pilote et appliqué les points de contrôle ci-dessus.

Après 3 mois d’améliorations, de co-construction et d’échanges avec les équipes et les parties prenantes ;

  • nous avons mis en production 6 nouvelles fonctionnalités dont une qui a fait gagner 15 minutes de temps de traitement par acte aux collaborateurs,
  • nous avons reçu beaucoup de retours positifs des décideurs, des collaborateurs et parties prenantes,
  • nous sommes passés de 12 à 125 actes de gestion traités.

Il nous reste encore beaucoup de choses à améliorer sur le produit pour atteindre une adoption généralisée, mais grâce à ce pilote nous savons désormais sur quoi concentrer nos efforts.

 


Grâce à ce REX, j’ai pu découvrir quelques pistes pour construire un bon pilote. Que ce soit en phase de cadrage, pendant le déroulé ou à la fin du pilote vous aurez remarqué que le dénominateur commun est l’écoute de vos utilisateurs mais aussi la validation au départ des conditions qui permettent de décider de la généralisation.

Et après chaque écoute, partager ses insights pour déterminer ce que nous devons prioriser.

Bon courage pour vos pilotes !

 

Topics: Product, lean, Bêta-test