Comment booster sa stratégie Product-Led Growth grâce l'expérimentation

Shagun Aulakh  exerce dans le domaine de l’expérimentation depuis près de dix ans, et a développé des programmes d’expérimentation pour de nombreuses entreprises, en interne et en tant que consultante. Elle est actuellement Director of Product Management & Experimentation chez American Express.

Comment utiliser la feature experimentation pour booster sa Product-Led Growth (PLG) ? 

La Feature Experimentation peut être considérée comme moteur principal de la stratégie produit.

Avec une méthode agile, on peut délivrer un maximum de produits et de fonctionnalités en un minimum de temps, mais sans expérimentation, impossible de booster l’innovation suffisamment pour obtenir le produit le plus performant possible. L’expérimentation continue vous permet d’obtenir de meilleurs résultats en vous permettant d’obtenir des datas fiables sur les performances d’une fonctionnalité.

Gardez en tête que la vitesse de release ne doit pas se faire au détriment du reste. Si l’expérimentation peut ralentir la delivery, une fonctionnalité ou un produit testés et validés via un processus d’expérimentation auront un impact bien supérieur et seront plus facile à optimiser. En plaçant l’expérimentation au cœur de votre stratégie Growth, vous aurez une vision plus claire de ce qu’il faut créer et quand. Vous pourrez ainsi réagir plus rapidement et ainsi économiser des ressources et gagner du temps.

Voici quelques conseils pour booster vos pratiques :

PENSEZ “LIVRAISON CONTINUE”

Expérimentez de manière régulière et stratégique dans le cadre de vos process déjà en place. Votre démarche doit être continue et non occasionnelle. Expérimentez pour déterminer votre backlog de fonctionnalités, créer des MVP, délivrer vos nouvelles features à des segments précis de votre audience avant de les rendre disponibles pour l’ensemble de vos visiteurs et utilisez les données issues de vos tests pour itérer ou valider. La conception et l’optimisation de vos produits doivent être challengées en permanence.

SÉLECTIONNEZ LES BONS OUTILS POUR OBTENIR DES INSIGHTS

Constituez une stack technique complète pour tirer le meilleur parti des datas que vous obtenez et utilisez la méthode d’expérimentation la plus adaptée pour en tirer les meilleurs enseignements possibles. A/B testing, feature flagging, déploiement Canary ou progressive delivery vous permettront d’itérer plus facilement selon l’expérience que vous souhaitez faire.

CONCENTREZ-VOUS SUR LE VÉRITABLE OBJECTIF : APPRENDRE

Votre objectif principal doit être de mieux comprendre le comportement de vos utilisateurs. L’expérimentation est la seule opportunité de découvrir l’impact de vos nouvelles fonctionnalités sur le parcours client, avant même qu’elles ne soient déployées, et comment adapter votre stratégie en conséquence. Apprendre de vos expériences est capital. En vous concentrant sur les données, une variante gagnante, perdante ou même des résultats non-significatifs vous permettront d’identifier des failles ou des réussites et d’apporter de nouvelles idées.

ALLEZ AU-DELÀ DES APPARENCES

Avec la Feature Experimentation, il est possible de mener des expériences plus poussées qu’avec l’expérimentation Web. S’il reste indispensable de tester des éléments visuels et les interactions de vos visiteurs avec vos pages, ne négligez pas le testing de vos fonctionnalités et de vos algorithmes. Avec une stratégie de testing à 360°, toutes les variables susceptibles d’impacter le parcours d’un utilisateur sont challengées. 

Comment utiliser les feature flags pour expérimenter ?

Le feature flagging vous permet de limiter les risques associés au déploiement en pratiquant la progressive delivery. Avec les feature flags, vous pouvez activer ou désactiver une fonctionnalité sans devoir déployer du code ou faire un rollback complet, car vous agissez précisément sur le code lié à cette nouvelle fonctionnalité. Vous pouvez ainsi lancer des tests sans risquer de créer une instabilité dans la production. Avec les Feature Flags, la maîtrise de vos expérimentations est plus grande, car vous avez la possibilité de créer votre fonctionnalité derrière un flag et maintenir ce flag désactivé jusqu’à ce qu’elle soit prête et de déployer vos nouvelles features auprès d’un segment d’utilisateurs précis afin d’en tester la pertinence et la stabilité avant de la rendre disponible progressivement à l’ensemble des visiteurs.

Néanmoins, il est à noter que les feature flags demandent une gestion du code rigoureuse afin d’éviter de creuser votre dette technique.

J’ai en mémoire l’exemple d’une société financière qui a fait les frais d’un feature flag oublié pendant huit ans. Une équipe qui procédait à une release a accidentellement activé le flag, déclenchant ainsi des transactions involontaires qui ont entraîné pas moins d’un demi-milliard de dollars de pertes ! Évitez ce genre de scénario catastrophe en supprimant minutieusement les flags obsolètes et en mettant en place une nomenclature claire afin de permettre à l’ensemble des équipes de les reconnaître.

Comment mettre en place la feature experimentation au sein de mon entreprise ? 

Tout dépend de la raison pour laquelle votre organisation n’a pas encore mis en place la feature experimentation. Commencez par sensibiliser votre direction au sujet. Vous aurez besoin du soutien de votre hiérarchie pour les mettre en place.

Proposez aux leaders une vision concrète des stratégies et des innovations possibles avec les feature flags et l’expérimentation. Dans la mesure du possible, commencez à utiliser les feature flags et l’expérimentation de fonctionnalités dans votre équipe. Partagez les enseignements clés et laissez entrevoir ce que vous pourriez obtenir en extrapolant cette stratégie à l’échelle de l’entreprise.

Comment faire collaborer les équipes Produit, Dev et Marketing en feature expérimentation ?

Je ne pense pas qu’il existe une seule bonne réponse à cette question. Cela dépend de la façon dont votre organisation et vos équipes sont structurées et de leurs différents besoins.

D’après mon expérience, la pratique de l’expérimentation est souvent gérée isolément au sein des équipes Produit d’un côté et Marketing de l’autre, avec les développeurs en soutien. Dans un de mes premiers postes, nous étions structurés ainsi, puis le service marketing a commencé à partager ses plans de test et ses idées avec l’équipe produit. Nous avons réalisé qu’en collaborant, nous pourrions aller beaucoup plus loin. Le service Marketing a commencé à participer aux réunions Produit, et nous avons mis en place des espaces d’échanges pour partager nos difficultés ou nos retours d’expérience, discuter de nos besoins, et même partager des ressources. Nous en avons retiré une bien meilleure compréhension de la stratégie produit et collaboré sur des décisions stratégiques clé concernant les promotions et la politique de livraison de l’entreprise.

Au lieu de dire « tel test a permis d’améliorer tel indicateur », préférez une explication plus concrète : « D’après nos expérimentations, nous avons identifié que si nous réduisons les frais de livraison pour tous nos visiteurs, nous risquons de perdre plusieurs millions d’euros. En revanche, si nous proposons un programme fidélité avec livraison gratuite aux clients réguliers, cela pourra améliorer l’acquisition et la valeur vie client. » Vous attirerez immédiatement l’attention de la direction !

Comment rassembler plusieurs équipes Produit dans une dynamique Product-Led Growth ? 

Là encore, tout dépend de votre organisation et de la façon dont vos équipes sont structurées. Certaines entreprises répartissent le Product Management entre différentes équipes indépendantes, chacune ayant son approche et ses programmes. D’autres optent pour une organisation très centralisée où chaque équipe devra respecter les normes, les modèles et les process de l’entreprise. Il existe, bien sûr, une large palette entre les deux.

Il n’y a pas de méthode parfaite, mais centraliser les bonnes pratiques et les process donne certains avantages. Cela permet notamment :

• de faciliter le partage entre équipes
• d’éviter les erreurs dues à du code complexe et confus
• de mieux gérer la suppression et le nettoyage des feature flags
• de comprendre l’impact et les difficultés de chaque équipe