REX : J’ai testé la Continuous Discovery chez Decathlon

Contexte

En tant que Product Owner ou Product Manager, combien de temps passez-vous chaque semaine à faire de la recherche utilisateur et à construire votre stratégie produit ?

Quand on a la tête dans le Delivery, avec des fonctionnalités à livrer, des bugs à corriger, en étroite collaboration avec l’équipe de développeurs, cela peut être un défi de trouver le temps de faire de la Discovery !

De la quoi ? Selon Teresa Torres, coach en Discovery, la Product Discovery (littéralement,”découverte du produit”) est “le travail que nous faisons pour prendre des décisions sur ce qu’il faut construire”, tandis que le Product Delivery ( “livraison du produit”) est le travail que nous faisons pour construire, livrer et maintenir un produit de qualité en production.

Concrètement, la Discovery peut prendre la forme d’activités et outils variés : entretiens et tests utilisateurs, enquêtes, ateliers, AB tests… Mais comment trouver le temps ? Par où commencer ?

Lors de ma dernière mission de Product Manager (PM) chez Decathlon, j’étais responsable à la fois de la Discovery et du Delivery de mon produit.

Je travaillais sur un produit qui permettait aux équipes internes d’animer le site e-commerce au fil des opérations commerciales.

Nous avons intégré une nouvelle fonctionnalité dans mon périmètre, responsabilité jusqu’alors partagée entre plusieurs équipes. Les premiers résultats d’AB test montraient que cette fonctionnalité augmentait la conversion de 2%. Comment capitaliser sur cette fonctionnalité ?

Pour comprendre les besoins des utilisateurs et déceler des opportunités, mon Group Product Manager (manager de 4 Product Managers) m’a suggéré d’utiliser une méthode utilisée par les autres Product Managers de notre équipe : la Continuous Discovery, proposé par

Teresa Torres pour faire de la Discovery “en continu”, en articulation avec le Delivery.

Dans cet article je raconte comment j’ai testé cette méthode pendant sept mois en l’adaptant à mon terrain.

Mission au coeur de l’animation commerciale du site de Decathlon

Etape 1 : Récolter les besoins terrains

Selon Teresa Torres, un bon PM doit rencontrer ses utilisateurs toutes les semaines, pas juste avant de lancer une nouvelle fonctionnalité ! Elle recommande de le faire en trio, avec un tech et un designer.

Dans la pratique, j’ai interrogé une dizaine d’utilisateurs, pendant des entretiens de 30min à 1h, souvent avec des développeurs, parfois seule ou avec une designer. J’ai initié le questionnaire sans suivre les bonnes pratiques de Teresa, notre designer l’a ensuite amélioré.

Quand utilisez-vous cette fonctionnalité ? Pour quoi faire ? A quelle fréquence ? Qui d’autre l’utilise ? Comment savez-vous ce qui performe le mieux ?

Je me suis rendue compte que mes questions étaient trop génériques et risquaient d’amener des réponses biaisées.

Teresa Torres recommande de demander plutôt des cas d’usages concrets. J’ai donc ajusté mes questions :

Quelle est la dernière fois que vous avez utilisé cette fonctionnalité ? Pour quoi faire ? Qu’est ce qui a été facile ? Difficile ? Quel a été le résultat ?

J’ai aussi utilisé le format atelier pour construire un Customer Journey avec les utilisateurs et l’équipe, ce qui a été efficace : beaucoup de personnes impliquées et de retours. Nous avons réutilisé le livrable par la suite pour écrire nos user stories.

Mon conseil : commencez avec ce que vous avez

Le plus important c’est de commencer ! Listez vos questions, interrogez des utilisateurs que vous connaissez (en interne), en invitant des membres de l’équipe qui sont motivés par la Discovery.

Vous pourrez affiner votre méthode au fur et à mesure !

Il y a beaucoup de points d’amélioration dans ce que j’ai mis en place, comme je le décris plus bas. Néanmoins, tout comme le produit parfait n’arrive jamais en production, la Discovery parfaite est un objectif inatteignable ! En m’appropriant quelques pratiques faciles à mettre en place j’ai pu avec des efforts limités tirer plusieurs bénéfices :

Les bénéfices :

• 1er bénéfice : mieux comprendre les besoins des utilisateurs pour diriger notre stratégie dans la bonne direction. Par exemple, mieux comprendre le rythme d’animation commerciale (nombre de campagnes simultanées, durée…) nous a aidés à mieux concevoir notre produit.
• 2ème bénéfice : impliquer les développeurs. Ils ont compris les points de douleurs des utilisateurs et les ont gardés en tête pendant leurs développements, même pour les sujets plus techniques (par exemple : choisir une solution permettant les évolutions fonctionnelles attendues par les utilisateurs lors d’une migration technique). Le produit était donc aligné avec les besoins utilisateurs. Cela a donné du sens à leur travail et donc été source de motivation.
• 3ème bénéfice : initier une relation avec les utilisateurs. Les premiers entretiens ont initié une relation entre les utilisateurs et l’équipe. Les utilisateurs nous ont remonté des besoins spontanément par la suite ! Et vice-versa, les développeurs ont parfois creusé des sujets auprès des utilisateurs sans passer par moi.

Une illustration de Product Trio générée en discutant avec une IA

Ce que j’aurais aimé faire pour aller plus loin :

Mon produit avait deux types d’utilisateurs : les utilisateurs internes qui paramètraient des contenus d’animation commerciale et les clients finaux qui voyaient le rendu sur le site.

J’ai pris le parti de faire confiance à mes utilisateurs internes (webmarketers) pour formuler des hypothèses sur les besoins des utilisateurs finaux (externes), car c’était à eux que j’avais accès. Le garde fou de la Continuous Discovery est : j’ai formulé des hypothèses, pas des certitudes. J’ai pu ensuite les confronter au terrain par des expérimentations pour les valider ou infirmer.

Les hypothèses auraient été plus fiables si j’avais interrogé à la source les clients finaux sur leurs besoins, comme le recommande Teresa Torres.

Je me suis renseignée sur les outils internes que je pouvais mobiliser pour cela (enquêtes d’opinion, plateformes de tests utilisateurs) mais le coût d’entrée était élevé : trouver les bons outils (Medallia, Contentsquare et un outil interne dans mon contexte), obtenir une licence, prendre en main l’outil ou attendre que l’équipe en charge mène le test pour moi… Pour aller plus loin, l’aide d’un designer qui maîtrise ces outils et techniques serait précieuse, pour guider le PM et les tech.

Etape 2 : Mapper les opportunités

Dès la récolte des premiers feedbacks utilisateurs, j’ai suivi la méthode de Teresa Torres qui consiste à centraliser les opportunités dans un support visuel appelé “Opportunity Solution Tree” (arbre d’opportunités et de solutions)

Parenthèse théorique

Voici le modèle préconisé par Teresa Torres :

L’arbre d’opportunités et de solutions. Source : producttalk.org

Quelques définitions :

• Impact souhaité (desired outcome) : “L’impact que nous voulons que notre travail ait sur les clients ou sur notre entreprise. Il s’agit souvent d’une mesure (…)”

Exemple dans mon contexte : Permettre aux utilisateurs de choisir le meilleur produit pour eux (mesuré par le taux de clic en page de résultats)

• Opportunité : “un besoin utilisateur non satisfait, une douleur ou un désir”.

Exemple dans mon contexte : Les utilisateurs veulent trouver le produit au meilleur prix

• Solution : “un produit, une fonctionnalité, un service, un processus, une documentation ou toute autre chose que nous offrons à nos clients pour les aider à répondre à une opportunité”.

Il faut bien distinguer opportunité et solution (la fonctionnalité ou produit qui y répond).

Par exemple : pour l’opportunité “Les utilisateurs veulent trouver le produit au meilleur prix” la solution peut être “voir les produits soldés dans une autre couleur”

• Hypothèse (assumption) : “une croyance qui doit être vraie pour que notre idée soit un succès”.

Par exemple : si les produits en solde ont une couleur différente, les clients vont davantage avoir envie de cliquer dessus.

• Test d’hypothèse : “une activité structurée que nous menons pour évaluer le risque d’une hypothèse.”

Quelques exemples : prototypes, questionnaire en une question, analyse data…

Mon conseil : rendez votre arbre visuel !

J’ai eu du mal à faire en sorte que l’équipe s‘approprie l’Opportunity Solution Tree. Au début, j’étais la seule à consulter et mettre à jour l’arbre. Je le présentais à mes stakeholders, Group Product Manager ou designer avec un impact limité.

Grâce au feedback de la Product Manager avec laquelle j’ai travaillé, j’ai ajouté des screenshots ou des maquettes pour chaque solution.

Bingo ! L’arbre est devenu beaucoup plus concret. Je l’ai présenté à l’équipe et cela a suscité beaucoup plus de questions et d’idées. Le lendemain, des développeurs avaient spontanément complété l’arbre en y ajoutant des estimations du coût de chaque solution.

Voici un exemple du rendu sur Miro :

Arbre de solutions et opportunités avec des exemples visuels

Bénéfices : pourquoi un arbre plutôt qu’un backlog?

Bénéfice 1 : Elargir le champ des solutions possibles

Formuler des opportunités et des hypothèses m’a obligée à faire un pas de côté par rapport aux demandes de solutions. Il est important de revenir à ce dont les utilisateurs ont besoin, pas juste ce qu’ils veulent !

Par exemple, certains webmarketeurs avaient demandé à mettre en avant les nouveautés pendant plus de temps sur le site. C’était une solution. L’opportunité était “les utilisateurs qui viennent régulièrement sur le site veulent connaître les nouveautés”. En repartant de celle-ci, nous avons identifié d’autres solutions, comme mieux regrouper les nouveautés ou les rendre accessibles en un clic.

L’arbre permet de voir les liens entre les différentes solutions, et d’identifier que plusieurs chemins sont possibles pour répondre à une opportunité.

Bénéfice 2 : Un outil de communication polyvalent

Contrairement à un backlog qui peut être très “micro” ou une roadmap plus “macro”, l’arbre permet d’échanger sur le produit à plusieurs niveaux selon l’interlocuteur : on peut rester au niveau de l’impact et opportunités pour les parties prenantes, zoomer sur les tests d’hypothèses avec des membres de l’équipe.

Enfin, j’ai pu faire l’expérience en tant que consultante que c’était un bon outil de passation ! En effet, au terme de ma mission, j’ai pu l’utiliser pour échanger avec la Product Manager que je remplaçais sur la stratégie produit.

Ce que j’aurais aimé faire pour aller plus loin :

Nous avons beaucoup utilisé la faisabilité (le coût de développement, les contraintes liées aux autres équipes) plus que l’impact pour prioriser.

J’aurais aimé pouvoir chiffrer l’impact potentiel de chaque solution pour prioriser.

Une piste pour faire cela : mon Group Product Manager m’a conseillé de relier les objectifs de mon arbre aux OKR de l’équipe (objective key results, le format d’objectif utilisé par les équipes e-commerce pour piloter leur produit).

Etape 3 : Prioriser

Après avoir récolté du feedback utilisateur et construit mon arbre (c’est en réalité un processus continu, la récolte et l’arbre évoluent par itérations), est venu le moment de tester mes hypothèses.

J’ai mis du temps avant de me lancer : je ne savais pas par quelle opportunité ou solution commencer.

Parenthèse théorique :

Teresa Torres propose un ensemble de critères pour prioriser les opportunités :

• Taille : “combien de clients sont concernés et à quelle fréquence ?”
• Marché : “Comment la réponse à chaque opportunité affecterait-il la position de votre produit sur le marché ?”
• Entreprise : “Comment chaque opportunité soutient-elle la mission, la vision et les objectifs stratégiques de votre entreprise ?”
• Clients : “Quelle est l’importance de chaque opportunité pour vos clients et dans quelle mesure sont-ils satisfaits des solutions existantes ?”

Mon conseil : gardez vos habitudes de priorisation

Si vous êtes déjà adeptes d’une méthode de priorisation (MOSCOW, RICE…) je vous conseille de garder la même. Pour que la Continous Discovery soit adoptée, il est préférable de l’ancrer aux habitudes existantes plutôt que de tout bouleverser.

Pour ma part, j’ai utilisé un simple arbitrage coût (estimé par les développeurs) / impact.

J’ai aussi composé avec une contrainte liée à mon organisation : les dépendances avec d’autres tests par d’autres équipes.

Par exemple, nous voulions tester l’impact d’afficher notre feature en rouge. Le coût était faible, l’impact potentiel grand (au vu des AB tests similaires effectués). La priorité de cette expérimentation était haute mais nous avons dû attendre qu’une expérimentation par une autre équipe se termine car elle impactait aussi la couleur sur une feature proche. Nous voulions aussi capitaliser sur les apprentissages du test en cours pour affiner notre stratégie de test.

Bénéfice : pivoter rapidement

A cette étape, l’arbre a été précieux car il nous a permis de pivoter plus facilement sur d’autres hypothèses à valider. D’où l’intérêt d’identifier plusieurs hypothèses et solutions par opportunités ! Pas possible de tester le rouge ? Pas de problème, nous avons pivoté sur le test d’une autre hypothèse liée à la visibilité de la fonctionnalité : jouer sur la taille des boutons.

Ce que j’aurais aimé faire pour aller plus loin

Nous avons beaucoup utilisé la faisabilité (le coût de développement, les contraintes liées aux autres équipes) plus que l’impact pour prioriser.

J’aurais aimé pouvoir chiffrer l’impact potentiel de chaque solution pour prioriser.

Une piste pour faire cela : mon Group Product Manager m’a conseillé de relier les objectifs de mon arbre aux OKR de l’équipe (objective key results, le format d’objectif utilisé par les équipes e-commerce pour piloter leur produit).

Etape 4 : Tester ses hypothèses

Pour tester des hypothèses, la méthode privilégiée chez Decathlon est l’AB test. Ce n’est pas la méthode privilégiée par Teresa Torres car elle nécessite beaucoup de trafic (pas possible dans tous les contextes) et du développement : “Nous ne voulons pas faire tout le travail pour construire quelque chose avant d’apprendre que nous avons construit la mauvaise chose”. Néanmoins, les expérimentations par AB test avaient du sens dans mon contexte : il y avait le trafic nécessaire sur le site, l’outil était en place et mon équipe était autonome pour l’utiliser. Plusieurs hypothèses à fort potentiel pouvaient être testées à faible coût.

Au contraire, les méthodes privilégiées par Teresa Torres avaient dans mon contexte un coût d’entrée élevé et rallongeaient la boucle de feedback. Par exemple, les tests utilisateurs nécessitaient des licences pour UserTesting, une plateforme de tests non modérés (tests non encadrés par un modérateur et où les participants effectuent des tâches en toute autonomie). Mon équipe n’était pas autonome pour y accéder : j’avais donc besoin que mes tests soient priorisés par les équipes Design et User Research, ce qui augmentait les délais et n’était pas compatible avec l’idée d’une Discovery “continue”.

Bénéfice : prendre du recul sur ce que l’on veut tester

Nous avons donc privilégié les AB tests. Au-delà d’un outil efficace, cela m’a obligé à me poser de bonnes questions avant chaque expérimentation :

• Quelle est l’opportunité que je veux tester ?

La réponse était facilitée par l’Opportunity Solution Tree, car l’opportunité y était listée, j’ai du simplement l’étoffer et la rendre intelligible au plus grand nombre.

• Quelle métrique utiliser pour valider la solution ?

C’est une des questions clés sur lesquelles j’ai passé du temps. Dans un contexte e-commerce, est-ce que la réussite de mon test sera mesuré par le taux de mise en panier, le taux de conversion ? Y-a-t-il un lien assez direct entre mon test et ces mesures pour que j’ai des résultats probants ?

L’équipe expérimentation avait ainsi listé des questions pour aider les équipes produit à bien cadrer leurs tests. Cette phase préparatoire nous a poussés à améliorer notre stratégie.

Ainsi, une simple question a remis en question la pertinence d’un test :

• Le changement est-il notable en moins de 5 secondes ?

Cela nous a questionné plus largement sur la visibilité de notre test.

Pour y répondre, nous avons utilisé Contentsquare, un outil qui analyse le comportement des utilisateurs sur le site, pour mesurer la visibilité des encarts que nous souhaitions tester. Seulement 3% des clients scrollaient jusque là !

Au vu de ces chiffres, nous ne pouvions pas espérer que les efforts de développement soient compensés par un gain commercial. Nous avons dépriorisé cette expérience et évité de perdre du temps à développer une fonctionnalité à l’impact business limité.

Ce que j’aurais aimé faire pour aller plus loin

Comme expliqué plus haut, j’aurais aimé testé d’autres méthodes d’expérimentations que l’AB test, avec une boucle de feedback plus rapide (un AB test avait besoin de tourner pendant minimum 4 semaines pour avoir des résultats statistiquement fiables), par exemple les tests utilisateurs, avec des utilisateurs finaux.

Conclusion

J’aurais aimé vous raconter une jolie histoire et vous partager tous les résultats de cette démarche mais étant consultante ma mission s’est terminée avant de vivre la suite. Je ne peux qu’appeler de mes vœux un happy ending ou plutôt happy continuing : des apprentissages au fil des tests, des progrès vers l’objectif recherché, bref, une success story !

Néanmoins, sans avoir vécu ces succès finaux, j’ai vu les bénéfices de cette approche dès les premiers petits pas :

• permettre au Product Manager de faire de la Discovery au fil de l’eau tout en restant focus sur le Delivery
• dérisquer notre stratégie produit en repartant des besoins utilisateurs plutôt que de nos belles idées
• identifier de nouvelles solutions en formulant des opportunités et des hypothèses

D’un point de vue plus personnel, voici ce qui m’a particulièrement plu :

• tisser des liens avec les utilisateurs lors des entretiens
• nourrir ma curiosité en comprenant leurs besoins au-delà de l’utilisation de mon produit
• mener la recherche utilisateur main dans la main avec les développeurs

Je ne peux donc que vous encourager à vous lancer !

Sortez 2 h la tête du Delivery la semaine prochaine : 20 minutes pour faire un premier questionnaire, 40 minutes pour interroger un utilisateur et 1h pour initialiser votre arbre, même avec une seule opportunité. Ça y est, votre Continuous Discovery est lancée !

Et une Discovery imparfaite vaut mieux que pas de Discovery du tout !

Pour aller plus loin

• Continuous Discovery Habits: le livre de Teresa Torres pour appréhender toute la méthode
• Résumé du livre en 15 minutes par Le Ticket pour les plus pressés (disponible en entier seulement pour les abonnés Premium)
• le blog Product Talk de Teresa Torres, mine de ressources pour améliorer des points précis ou se nourrir de retours d’expérience pratiques
• la formation Product Discovery par Octo Academy pour s’approprier l’approche par la pratique