Product Ops Manager, œuvrons depuis plus de deux ans, avec l’ensemble des équipes produit et design, à faire grandir une culture produit (vraiment) user-centric et data-informed. France Télévisions est une grande organisation avec un héritage culturel issu du media traditionnel de la télévision broadcast. La direction numérique pour laquelle nous travaillons pilote notamment 8 produits numériques et + de 100 product makers (VP Product, Heads of Product & Design, Product Managers, Product Owners, Product Designers, UX Researchers, experts QA et SEO).
La première étape a consisté à collecter les besoins utilisateur : nous avions besoin de données de qualité, de la manière la plus efficace et sous toute forme de traitement, quali ou quanti. Directement immergés au sein des équipes produit et design, nous avons entamé une démarche lean d’expérimentations et avons testé en continue de nombreux formats de workshops, multipliant les méthodologies de Design Thinking, de Product Discovery, de méthodes de cadrage et de priorisation... tout ceci dans l’objectif de trouver notre (parfait) outil et cadre produit. Très rapidement, avec l’ensemble des équipes, nous étions capables de construire notre propre modèle du
, d’intégrer complètement le Product Discovery et une culture produit user-centric au sein de notre organisation produit.
OK cool. Job is done!
Problèmes
En réalité, nous n’étions pas encore conscients que ce n’était que le début d’une belle aventure avant de pouvoir obtenir des insights utilisateurs parfaitement actionnables par les équipes produit :
Avec 8 produits et + de 30 UX Researchers et Product Managers, nous avions obtenu en très peu de temps un très grand nombre d’insights utilisateurs. En tant que VP Product, Product Manager ou Développeur, comment trouver l’information dont j’ai besoin, le + rapidement possible ?
Les insights proviennent de 8 produits différents et très souvent de personnes différentes, parfois de passage court au sein de l’entreprise. Comment conserver l’historique ? Comment assurer une cohérence dans la récolte de sorte que chaque produit puisse utiliser la donnée de la même manière ?
La user research coûte cher. Nous pourrions estimer qu’environ 20% de notre user research provenant d’un produit spécifique pourrait être exploitée pour résoudre un problème utilisateur d’un autre produit. Comment exploiter à bon escient la recherche effectuée au préalable sur un autre produit ? Comment s’assurer qu’une initiative de user research n’a pas déjà été réalisée sur un même sujet par un autre produit ?
Nos utilisateurs sont en recherche d’une expérience unifiée et fluide au sein de nos différents environnements numériques. Notre organisation devrait être complètement transparente à leurs yeux. Comment installer une vraie transversalité inter-produit et inter-équipe, de façon à ce que nos produits ne soient pas le reflet de notre organisation ?
Solution
Nous étions encore loin d’y croire il y a quelques mois, mais une seule et même solution peut répondre à l’ensemble de ces problèmes. Nous l’avons initialement testée sous le nom de “Atomic Research”, puis nous l’avons rapidement adaptée pour devenir aujourd’hui ce qu’on a baptisé le “Product Atomic Research”.
Cette approche permet de meilleur(e)s collectes, analyses et partages de la connaissance utilisateur provenant de la user research. Je vous invite à lire les articles passionnants de
pour appréhender plus facilement cette notion. Pour résumer très rapidement en une phrase :
“Le concept consiste à décomposer la connaissance utilisateur en plusieurs éléments constitutifs :
Expérimentations “Nous avons fait cela…”
Observations “…et nous avons constaté que…”
Insights “…ce qui nous fait penser que…”
Recommandations “…donc nous allons faire cela.”
En décomposant les connaissances de cette manière, on obtient des possibilités extraordinaires.”
Et aujourd’hui, nous pouvons le confirmer !
Avant toute chose, pour atteindre nos objectifs, nous avons adapté le modèle d’Atomic Research initial en fonction de nos besoins et spécificités organisationnelles. Vous comprendrez par la suite que le “Product Atomic Research” a été pour nous un moyen essentiel pour renforcer la synergie entre les équipes produit et design et pour gagner un temps considérable lors des itérations de Product Discovery.
Aujourd’hui, chez France Télévisions, les Product Managers et UX Researchers travaillent conjointement la stratégie et la construction des roadmaps produit en fonction des besoins utilisateurs et des résultats de Product Discovery. Ça n’a pas toujours été le cas, et nous savons que beaucoup de produits sur le marché travaillent encore séparément la user research de la construction des
et des roadmaps. Il était donc essentiel pour nous d’optimiser la dernière étape de l’Atomic Research, appelée “Recommandation”, et de la substituer par “
“ afin d’intégrer directement nos méthodes de priorisation. De la sorte, nous pouvons désormais aller au bout de la réflection produit avant de passer à la construction des
et des roadmaps avec les Product Managers et Product Owners. Par ailleurs, nous évitons l’écueil d’adresser directement les problèmes et opportunités identifiés avec des solutions sans avoir recours à des ateliers avec les membres de l’équipe produit.
pour prioriser. Le modèle étant largement approuvé par plusieurs de nos Product Managers, nous avons décidé de le formaliser plus concrètement au sein de notre outil de product management/repository Coda ici, via l’onglet
En quelques mois seulement nous avons pu voir d’énormes progrès au sein de l’organisation produit. Grâce au Product Atomic Research et à ce document Coda 100% fait-maison, que nous partageons avec vous aujourd'hui avec beaucoup d'enthousiasme, nous mesurons des bénéfices à plusieurs niveaux :
Synergie
transversalité de la connaissance de façon verticale et horizontale, entre les produits et au sein des produits
Nous cassons tous les silos qui pourraient exister entre les équipes produit et design (Heads of Product & Design, Product Managers, Product Owners, Product Designers and UX Researchers).
Symétrie
uniformiser nos manières de travailler lorsque cela est pertinent
Nous rassemblons toutes les connaissances au même endroit et exactement de la même manière pour chaque membre et chaque équipe.
Symbiose
traçabilité de chaque action de bout en bout de la chaîne produit
Nous organisons toutes les données de manière à ce que chacun puisse trouver l'information dont il a besoin le plus rapidement possible et revenir à la source, grâce aux bons tags, et à un référencement cohérent de l'information.
Bonnes pratiques
Voici un partage de quelques bonnes pratiques issues à notre expérience :
Ce repository est une base de données, et comme toutes les bases de données, il nécessite d'être extrêmement rigoureux et de créer et respecter certaines lignes directrices pour une base de données saine et exploitable.
Avant toute chose :
Piloter son Product Atomic Research comme un produit, avec une véritable communauté d’utilisateurs internes (Product Managers, Product Owners, UX Researchers...) : tester, apprendre, évoluer continuellement
Créer une nomenclature et la respecter rigoureusement
Renseigner toutes les données (zones, tags, supports, ressenti utilisateur...)
Un tag a pour objectif de pouvoir accéder le plus rapidement possible à une donnée issue de l’Atomic Research, via les outils de recherche disponibles pour tous (Product Managers, Product Owners, Designers…)
Un insight peut évoluer dans le temps lorsque les observations qui le corroborent nuancent progressivement l’insight
Un insight peut être découpé quand, au fur et à mesure des apprentissages, les observations se multiplient et laissent apparaître plusieurs niveaux de granularité
Qu’est-ce qu’une “Expérimentation”?
Une expérimentation est le contexte dans lequel nous avons pu observer des comportements utilisateurs
Elle peut être de plusieurs natures : qualitative ou quantitative (test utilisateur, analyse de parcours, questionnaire, analyse de performance…)
Elle est rattachée aux observations qui ont été recueillies pour en assurer la traçabilité
Qu’est-ce qu’une “Observation” ?
Une observation est l’affirmation d’un comportement utilisateur qui a pu être observé
Elle peut être recueillie sous plusieurs formes, soit via une observation de l’usage de l’utilisateur, soit directement via un verbatim
Qu’est-ce qu’un “Insight”?
Un insight est un enseignement vérifié, un constat ou une vérité identifiée basée sur les motivations ou les difficultés rencontrées par nos utilisateurs
Il est issu de l'analyse et de la synthèse d’observations
Il doit être exploitable. Une équipe doit pouvoir l’utiliser pour prendre les meilleures décisions et nourrir la roadmap (il ouvre le champ des solutions)
Il doit être clair, concis et doit déclencher une action
Quelle est la différence entre une “Observation” et un “Insight”?
Observation = affirmation de quelque chose que j’ai observé
Insight = affirmation de quelque chose que j’ai vérifié (une vérité absolue)
Comment vérifier que les “Observations” et les “Insights” sont correctement rédigés ?
Observation ✅
Nous avons pu observer que…
“L’utilisateur revient plusieurs fois sur la navigation et passe de page en page”
Insight ✅
Ce qui nous fait penser que…
“Le champ de recherche n’est pas visible”
Qu’est-ce qu’un bon tag ?
Il doit être conçu pour faciliter la recherche
Il doit faire partie d’une liste de 50 tags au maximum (tout produit/équipe confondu(e))
Se poser la question si ce tag sera le meilleur mot pour retrouver cet(te) insight/observation
Se poser la question s’il n’existe pas déjà sous une autre forme
Il ne doit pas être trop micro
Il ne doit pas contenir de fautes d’orthographe ou d’erreurs de syntaxe
Il faut être vigilant aux synonymes qui peuvent rendre la recherche difficile
Il s’agit des expérimentations qui ont été faites afin d’identifier, analyser et/ou de comprendre un besoin utilisateur. Les expérimentations peuvent être basées sur des données quantitatives ou qualitatives.
Ici sont rattachées les expérimentations à des observations utilisateurs. Il s’agit de constats/observations brutes qui ont été relevées dans le cadre des expérimentations citées précédemment.
Ici sont priorisés les insights en fonction du Reach, de l’Impact sur l’objectif business et du niveau de Confiance en ce besoin et de l’Effort. La méthodologie RICE aide dans cette démarche (Reach, Impact, Confiance, Effort).
Quelques astuces pour profiter pleinement
Filtrer
La principale spécificité et force de ce document réside dans le fait que vous pouvez filtrer en haut de chaque page en fonction de votre produit ou équipe. Cela permet de casser les silos entre les équipes et de pouvoir profiter des résultats de recherche d’autres produits ou équipes.
Tester
Sélectionner produit(s)
Sélectionner produit(s)
No results from filter
Tous les produits et équipes utilisent le même document. Cela assure une vraie cohérence entre les différents produits et expertises. Pour une consultation confortable, il est essentiel de choisir le produit ou l’équipe qui vous concerne.
Faire évoluer votre propre document Coda
La bonne nouvelle, c’est que Coda est un produit à part entière : il dispose d’une interface “front” présentant de façon fonctionnelle des données renseignées au préalable dans un espace "
DB
" répertoriant toutes les données sources. Cela signifie que l’outil évolue en fonction des besoins de chacune de vos équipes.
Tester
Pour cela, il vous suffit d’envoyer une demande grâce au bouton
feedback
présent tout au long du parcours. Ainsi, vous pourrez voir et piloter l’ensemble des feedback grâce à l’espace suivant :
Et comme nous appliquons également à nous-mêmes des principes “lean” d’évolution en continue, nous serions ravi.es de recevoir vos feedback et bonnes idées. N’hésitez pas à prendre quelques minutes pour nous faire part de vos retours 🙏