Pourquoi votre équipe produit doit adopter l’expérimentation

Spécialiste et Leader CRO chez Decathlon, Mathieu Fauveaux recommande vivement l’utilisation de l’AB testing au sein des équipes Produit.

Dans cet article, il vous explique pourquoi l’expérimentation Produit est aujourd’hui une pratique incontournable pour optimiser efficacement l’expérience de vos visiteurs.

1. Quel est le modèle d’organisation CRO x Produit idéal ?

L’expérimentation est avant tout une méthode, pas une équipe à part entière. Elle doit s'intégrer aux équipes existantes qui conçoivent les projets de l’entreprise : les équipes Produit. Elles pourront ainsi obtenir des données qui leur permettront de s’assurer qu’elles créent réellement de la valeur. 

Il est facile d’intégrer l’expérimentation aux process existants d’une équipe Produit, mais il est nécessaire de mettre en place quelques éléments indispensables :

• La création de Feature Teams avec toutes les compétences nécessaires pour pouvoir expérimenter et être autonomes. Cela signifie un PO, un DA, un UX researcher, un conception / UI designer, des développeurs et quelques ingénieurs QA.
• La formation de ces Feature Teams à l’expérimentation : Chaque profil de l’équipe a un rôle à jouer dans cette nouvelle démarche et doit comprendre comment s’y intégrer. Une équipe Produit solide et complète peut mettre en place l’expérimentation en 3 à 6 mois. Après 1 à 2 ans, ses stratégies seront bien plus solides.
• L’évolution de la phase de Discovery : Cette nouvelle méthode modifie les process au sein de l’équipe produit. La phase de recherche se fait en binôme UX et DA. Certaines méthodes de recherche sont délaissées pour en privilégier d’autres. Les recommandations se transforment en hypothèses structurées et discutées par l’ensemble de l’équipe. On ne cherche plus à trouver une solution, mais plutôt à définir une bonne hypothèse.

2. Quelles sont tes recommandations pour engager toutes les équipes dans une démarche d’expérimentation ?

On parle souvent de la présentation des projets aux leaders pour permettre à la démarche de prendre de l'ampleur. C’est effectivement essentiel pour l’officialiser et demander des ressources ou des changements d’organisation.

Néanmoins, les équipes aussi ont un rôle important à jouer. Elles doivent accepter ces évolutions tout en les utilisant pour justifier leurs décisions et donner du sens à la démarche. Par exemple, on peut refuser une demande de test A/B de la direction ou d’une autre équipe en expliquant le manque de trafic. On peut aussi challenger la demande en recommandant de découper le sujet autrement pour limiter la prise de risque ou pour favoriser les enseignements. Ces petites actions encouragent la montée en compétences des équipes et les emmènent doucement vers l’expérimentation.

Cette pédagogie est essentielle pour intégrer les curieux et rassurer les méfiants. Si vous faites des points CRO hebdomadaires entre équipes pour discuter méthodes, résultats ou encore recherches, laissez la porte ouverte à toutes les personnes de l’organisation. C’est un excellent moyen de les former de manière passive.

Dans des organisations plus matures, nous travaillons actuellement sur des processus d’onboarding. Il n’existe quasi aucune formation sur ces sujets. C’est à l’entreprise de transmettre son expertise.

3. Déployer sans expérimenter, est-ce encore possible ?

Je dirais qu’une fois qu’une équipe a été surprise par ses performances avec un A/B test, elle ne peut plus revenir en arrière. Il faut dire que depuis quelques années, les méthodes Produit évoluent rapidement et il est impossible de tout appliquer. Je vois aujourd’hui 3 niveaux de maturité pour les équipes : 

• Le niveau de maturité n°1 : L’équipe délivre et lance la feature en même temps. Elle valide sa nouvelle feature par un test utilisateur simple ou une comparaison de période analytics avant/après. Ces approches ne garantissent pas la qualité de l’expérience utilisateur, ni l’adoption de la feature. Les performances de celle-ci ne sont pas assurées. Si la fonctionnalité crash ou est abandonnée, l’équipe aura perdu du temps et gaspillé des ressources.
• Le niveau de maturité n°2 : L’équipe sépare le déploiement du lancement et utilise le test A/B pour valider la feature avant de la rendre disponible à tous les utilisateurs. C’est un pas en avant pour maîtriser le risque, mais on se prive des avantages de l’expérimentation pour la phase de discovery et on risque de n’itérer que rarement, car la roadmap est chargée.
• Le niveau de maturité n°3 : L’équipe utilise l’expérimentation, du brief initial au déploiement final d’une feature. Sa conception s'intègre dans une stratégie en plusieurs temps pour atteindre un objectif donné. La cible du projet n’est pas entièrement connue et ce sont les données à chaque itération qui viennent guider les décisions. Le test A/B devient alors un moyen de validation et surtout, un moyen de recherche pour guider les décisions des équipes. 

Pour atteindre ce niveau, l’entreprise doit donner un maximum de liberté aux PO/PM et accepter de faire passer au second plan les délais de déploiement. Faire une feature avec de l’impact peut se faire en 1 itération, en 10 ou même ne jamais fonctionner. C’est le comportement des utilisateurs et l’impact qui permettent de valider le déploiement d’une feature ou non. L’équipe Produit travaille pour atteindre des objectifs chiffrés et non plus pour respecter une roadmap.

Bien que l’expérimentation demande un grand investissement des équipes Produit (des profils, des compétences, un mindset, le soutien de la hiérarchie, du temps pour se former, pour développer ses compétences…) l’impact des features et des parcours construits par les équipes devient visible et mesurable. Elles prennent un vrai sens qui permet de dynamiser et de motiver les équipes, autant que de mesurer la croissance de l’entreprise en suivant des KPIs précis.