Data driven (mobile) product par Matthieu Reboul, PM @ChauffeurPrivé
•
4 recomendaciones•994 vistas
Matthieu Reboul, PM @ChauffeurPrivé nous explique comment la Data se retrouve à chaque étape du développement produit. Retrouvez nous ici pour plus de meetup : https://www.meetup.com/fr-FR/laproductconf-x/
Recomendados
Recomendados
Más contenido relacionado
Más de Thiga
Más de Thiga (20)
Data driven (mobile) product par Matthieu Reboul, PM @ChauffeurPrivé
- 1. Data-driven Product Management Data-driven Product Management Matthieu Reboul Mobile Product Management Meetup Mars 2018
- 3. Qui suis-je ? Matthieu Reboul Lead Product Manager @Chauffeur Privé
- 4. Chauffeur Privé : leader français des applications VTC
- 5. Mon parcours Ecole de commerce
- 9. Mon parcours Chauffeur Privé Lead Product Manager
- 10. Data-driven PM : Quand ?
- 11. La courbe Succès / Temps Temps Succès
- 12. Phase 1 : recherche du market fit Temps Succès
- 13. Phase 2 : (hyper-)croissance Temps Succès
- 14. Phase 2 : le bon moment pour démarrer une approche data-driven (en théorie) Temps Succès
- 15. Temps Succès Phase 2 : tout est génial Feature géniale #1 Feature géniale #2
- 16. Temps Succès Sauf que … Feature géniale #2
- 17. Temps Succès Phase 3 : gérer la phase de maturité du produit Feature géniale #3 Qui implique de factoriser Feature #2
- 18. Temps Succès Phase 3 : gérer la phase de maturité du produit Feature géniale #3 Qui implique de killer Feature #2
- 20. Roadmap et priorisation La méthode classique : manipuler des projets Projet 1 Projet 2 Projet 3 Projet 4 Projet 8Projet 5 Projet 6 Projet 7 Projet 11 Projet 12Projet 9 Projet 10
- 21. Roadmap et priorisation La méthode classique : manipuler des projets Projet 1Projet 2Projet 3 Projet 4 Projet 8 Projet 5 Projet 6 Projet 7 Projet 11 Projet 12 Projet 9Projet 10
- 22. Roadmap et priorisation La méthode classique : la loi du plus haut placé convaincant
- 23. Roadmap et priorisation La méthode classique : la loi du plus haut placé convaincant
- 24. Roadmap et priorisation La méthode data-driven : rationnaliser et objectiver la priorisation Comment rationnaliser et objectiver la priorisation ?
- 25. Taux de conversion Trafic Roadmap et priorisation 1 - Définir un indicateur principal CA
- 26. Roadmap et priorisation 2 - Décomposer son indicateur principal en indicateurs actionnables Taux de conversion Trafic Panier moyen
- 27. Roadmap et priorisation 2 - Décomposer son indicateur principal en indicateurs actionnables Taux de conversion
- 28. Roadmap et priorisation 2- Décomposer son indicateur principal en indicateurs actionnables % Visites qualifiées (2 pages et +) % Visites avec fiche produit % Visites avec ajout panier % Succès du tunnel de paiement
- 29. Roadmap et priorisation 3 - Mesurer et (si possible) benchmarker 50% 45% 2% 75%
- 30. Roadmap et priorisation 4 - Prioriser 1 2 3 4
- 31. Roadmap et priorisation Bâtir sa roadmap en déclinant ses objectifs en projets % Visites qualifiées (2 pages et +) Vitesse du site Pertinence du réf. naturel Look & Feel Merchandising …
- 32. Conception
- 33. Conception Partir d’hypothèses plutôt que d’assomptions Hypothèses
- 34. Conception Valider au plus tôt ses hypothèses - Approche data-centric - Exemple d’Etsy
- 35. Conception Valider au plus tôt ses hypothèses - Approche data-centric Comment booster la conversion ? Plus de produits Plus vite
- 36. Conception Valider au plus tôt ses hypothèses - Approche data-centric Vs
- 37. Conception Valider au plus tôt ses hypothèses - Approche data-centric Fail
- 38. Conception Valider au plus tôt ses hypothèses - Approche data-centric Comment booster la conversion ? Plus de produits Plus vite
- 39. Conception Valider au plus tôt ses hypothèses - Approche data-centric Plus de produits -> bien ou pas bien ?
- 40. Conception Valider au plus tôt ses hypothèses - Approche data-centric Vs
- 41. Conception Valider au plus tôt ses hypothèses - Approche data-centric Plus de produits -> pas d’impact sur leurs utilisateurs
- 42. Conception Valider au plus tôt ses hypothèses - Approche data-centric Plus vite -> bien ou pas bien ?
- 43. Conception Valider au plus tôt ses hypothèses - Approche data-centric Plus vite -> pas d’impact sur leurs utilisateurs
- 44. Conception Valider au plus tôt ses hypothèses - Approche user-centric - Parler à des vrais gens
- 45. Conception Le nombre idéal de tests utilisateurs - Jakob Nielsen (2000) # utilisateurs testés Problèmes identifiés 100% 75% 50% 25% 3 6 9 12
- 46. Conception Le meilleur moyen trouver son produit au top : ne pas le tester # utilisateurs testés Problèmes identifiés 100% 75% 50% 25% 3 6 9 12
- 47. Conception 5 tests utilisateurs permettent d’identifier 80% des problèmes liés à une feature # utilisateurs testés Problèmes identifiés 100% 75% 50% 25% 3 6 9 12
- 48. Conception 15 tests utilisateurs : le chiffre parfait ? # utilisateurs testés Problèmes identifiés 100% 75% 50% 25% 3 6 9 12
- 49. Conception 15 tests utilisateurs : le chiffre parfait ? # utilisateurs testés Problèmes identifiés 100% 75% 50% 25% 3 6 9 12
- 50. Conception 15 tests utilisateurs : le chiffre parfait ? # utilisateurs testés Problèmes identifiés 100% 75% 50% 25% 3 6 9 12
- 51. Conception Le nombre idéal de tests utilisateurs : 5 x 3 5 x 3
- 52. Execution
- 53. Exécution Remettre la valeur utilisateur au centre du développement
- 54. Exécution Fail - Développement de l’app Sarenza Je veux acheter un produit en payant par CB et me faire livrer à domicile Je veux filter/trier une liste de produit Je veux trouver un produit Je veux des infos sur un produit Je veux payer avec PayPal Je veux me faire livrer en point relais Je veux payer en utilisant un code promo Je veux faire un retour Je veux faire un échange pour une autre taille Je veux trouver le site sur les moteurs de recherche Je veux naviguer dans une langue étrangère Je veux payer avec un chèque Je veux me faire livrer en express Je veux payer avec une carte cadeau Je veux payer en 3 fois Je veux faire un échange pour une autre couleur Je veux parrainer un ami Je veux ajouter un favori Je veux m’abonner à la newsletter du site Je veux modifier mes informations personnelles Je veux trouver un produit complémentaire Je veux trouver une réponse à une question fréquente Je veux postuler dans votre entreprise … 80% du développement
- 55. Exécution Fail - Développement de l’app Sarenza Je veux acheter un produit en payant par CB et me faire livrer à domicile Je veux filter/trier une liste de produit Je veux trouver un produit Je veux des infos sur un produit Je veux payer avec PayPal Je veux me faire livrer en point relais Je veux payer en utilisant un code promo Je veux faire un retour Je veux faire un échange pour une autre taille Je veux trouver le site sur les moteurs de recherche Je veux naviguer dans une langue étrangère Je veux payer avec un chèque Je veux me faire livrer en express Je veux payer avec une carte cadeau Je veux payer en 3 fois Je veux faire un échange pour une autre couleur Je veux parrainer un ami Je veux ajouter un favori Je veux m’abonner à la newsletter du site Je veux modifier mes informations personnelles Je veux trouver un produit complémentaire Je veux trouver une réponse à une question fréquente Je veux postuler dans votre entreprise … 80% du développement 0% de la valeur
- 56. Exécution Success - Refonte technique Je veux acheter un produit en payant par CB et me faire livrer à domicile Je veux filter/trier une liste de produit Je veux trouver un produit Je veux des infos sur un produit Je veux payer avec PayPal Je veux me faire livrer en point relais Je veux payer en utilisant un code promo Je veux faire un retour Je veux faire un échange pour une autre taille Je veux trouver le site sur les moteurs de recherche Je veux naviguer dans une langue étrangère Je veux payer avec un chèque Je veux me faire livrer en express Je veux payer avec une carte cadeau Je veux payer en 3 fois Je veux faire un échange pour une autre couleur Je veux parrainer un ami Je veux ajouter un favori Je veux m’abonner à la newsletter du site Je veux modifier mes informations personnelles Je veux trouver un produit complémentaire Je veux trouver une réponse à une question fréquente Je veux postuler dans votre entreprise … Valeur
- 57. Je veux acheter un produit en payant par CB et me faire livrer à domicile Je veux filter/trier une liste de produit Je veux trouver un produit Je veux des infos sur un produit Je veux payer avec PayPal Je veux me faire livrer en point relais Je veux payer en utilisant un code promo Je veux faire un retour Je veux faire un échange pour une autre taille Je veux trouver le site sur les moteurs de recherche Je veux naviguer dans une langue étrangère Je veux payer avec un chèque Je veux me faire livrer en express Je veux payer avec une carte cadeau Je veux payer en 3 fois Je veux faire un échange pour une autre couleur Je veux parrainer un ami Je veux ajouter un favori Je veux m’abonner à la newsletter du site Je veux modifier mes informations personnelles Je veux trouver un produit complémentaire Je veux trouver une réponse à une question fréquente Je veux postuler dans votre entreprise … Exécution Success - Refonte technique
- 58. Je veux acheter un produit en payant par CB et me faire livrer à domicile Je veux filter/trier une liste de produit Je veux trouver un produit Je veux des infos sur un produit Je veux payer avec PayPal Je veux me faire livrer en point relais Je veux payer en utilisant un code promo Je veux faire un retour Je veux faire un échange pour une autre taille Je veux trouver le site sur les moteurs de recherche Je veux naviguer dans une langue étrangère Je veux payer avec un chèque Je veux me faire livrer en express Je veux payer avec une carte cadeau Je veux payer en 3 fois Je veux faire un échange pour une autre couleur Je veux parrainer un ami Je veux ajouter un favori Je veux m’abonner à la newsletter du site Je veux modifier mes informations personnelles Je veux trouver un produit complémentaire Je veux trouver une réponse à une question fréquente Je veux postuler dans votre entreprise … Exécution Success - Refonte technique
- 59. Je veux acheter un produit en payant par CB et me faire livrer à domicile Je veux filter/trier une liste de produit Je veux trouver un produit Je veux des infos sur un produit Je veux payer avec PayPal Je veux me faire livrer en point relais Je veux payer en utilisant un code promo Je veux faire un retour Je veux faire un échange pour une autre taille Je veux trouver le site sur les moteurs de recherche Je veux naviguer dans une langue étrangère Je veux payer avec un chèque Je veux me faire livrer en express Je veux payer avec une carte cadeau Je veux payer en 3 fois Je veux faire un échange pour une autre couleur Je veux parrainer un ami Je veux ajouter un favori Je veux m’abonner à la newsletter du site Je veux modifier mes informations personnelles Je veux trouver un produit complémentaire Je veux trouver une réponse à une question fréquente Je veux postuler dans votre entreprise … Exécution Success - Refonte technique
- 60. Je veux acheter un produit en payant par CB et me faire livrer à domicile Je veux filter/trier une liste de produit Je veux trouver un produit Je veux des infos sur un produit Je veux payer avec PayPal Je veux me faire livrer en point relais Je veux payer en utilisant un code promo Je veux faire un retour Je veux faire un échange pour une autre taille Je veux trouver le site sur les moteurs de recherche Je veux naviguer dans une langue étrangère Je veux payer avec un chèque Je veux me faire livrer en express Je veux payer avec une carte cadeau Je veux payer en 3 fois Je veux faire un échange pour une autre couleur Je veux parrainer un ami Je veux ajouter un favori Je veux m’abonner à la newsletter du site Je veux modifier mes informations personnelles Je veux trouver un produit complémentaire Je veux trouver une réponse à une question fréquente Je veux postuler dans votre entreprise … 80% du développement 90% de la valeur Exécution Success - Refonte technique
- 62. Mesure de la performance Méthode 1 - L’AB test A B
- 63. Mesure de la performance Méthode 1 - L’AB test Temps Succès On garde
- 64. Mesure de la performance Méthode 1 - L’AB test Temps Succès On jette
- 65. Mesure de la performance La valeur d’un AB test va au-delà de la mesure de la performance
- 66. Mesure de la performance La valeur d’un AB test va au-delà de la mesure de la performance
- 67. Fail Mesure de la performance La valeur d’un AB test va au-delà de la mesure de la performance
- 68. Mesure de la performance La valeur d’un AB test va au-delà de la mesure de la performance
- 69. Success Mesure de la performance La valeur d’un AB test au-delà de la mesure de la performance : monitoring de feature
- 70. Mesure de la performance AB test fail #1 - Comparer des choux et des carottes
- 71. Test Mesure de la performance AB test fail #1 - Comparer des choux et des carottes Taux de conversion Témoin
- 72. Test Mesure de la performance AB test fail #1 - Comparer des choux et des carottes Taux de conversion Témoin
- 73. Mesure de la performance AB test fail #1 - Comparer des choux et des carottes
- 74. P Test Mesure de la performance AB test fail #1 - Comparer des choux et des carottes Taux de conversion Témoin
- 75. Test Mesure de la performance AB test fail #1 - Comparer des choux et des carottes Taux de conversion Témoin P
- 76. 123 Mesure de la performance AB test #2 - Choisir la mauvaise mesure / le mauvais indicateur CTA Value proposition Logo Footer
- 77. 123 Mesure de la performance AB test #2 - Choisir la mauvaise mesure / le mauvais indicateur Logo CTA Value proposition Footer
- 78. Mesure de la performance Méthode 2 - Le bon vieux avant/après Temps Succès Avant Après
- 80. Ecueils et challenges d’une stratégie data-driven Ne pas confondre culture data et culture data-driven Culture data : > Je fais des assomptions lors de la conception de mon projet > Je développe ma fonctionnalité > Je mesure l’impact a posteriori > Je jette ou je conserve Culture data-driven : > Je fais des hypothèses > Je les (in)valide a priori à moindre coût > Je développe ma fonctionnalité > Je la déploie progressivement en monitorant la performance > Je déploie ou j’itère
- 81. Ecueils et challenges d’une stratégie data-driven Apprendre à gérer l’échec
- 82. Ecueils et challenges d’une stratégie data-driven Revoir son organisation Avant Conception Réalisation Déploiement
- 83. Ecueils et challenges d’une stratégie data-driven Revoir son organisation Avant Conception Réalisation Déploiement Après Conception Réalisation Déploiement AB test
- 84. Ecueils et challenges d’une stratégie data-driven Revoir son organisation Avant Conception Réalisation Déploiement Après Conception Réalisation Déploiement AB test C’est génial
- 85. Ecueils et challenges d’une stratégie data-driven Revoir son organisation Avant Conception Réalisation Déploiement Après Conception Réalisation Déploiement AB test C’est la cata
- 86. Ecueils et challenges d’une stratégie data-driven Revoir son organisation Avant Conception Réalisation Déploiement Après Conception Réalisation Déploiement AB test Encore Après Conception Réalisation AB test Déploiement AB test Réalisation
- 87. Ecueils et challenges d’une stratégie data-driven Revoir son organisation Encore Après Conception Réalisation AB test Déploiement AB test Réalisation Conception Prototype AB test Réalisation AB test Déploiement Probablement mieux Go/No Go Go/No Go
- 88. Ecueils et challenges d’une stratégie data-driven Revoir son organisation Encore Après Conception Réalisation AB test Déploiement AB test Réalisation Conception Prototype AB test Réalisation AB test Déploiement Probablement mieux Optimisation AB test … …
- 89. Ecueils et challenges d’une stratégie data-driven Revoir son organisation Encore Après Conception Réalisation AB test Déploiement AB test Réalisation Conception Prototype AB test Réalisation AB test Déploiement Probablement mieux Conception Prototype AB test Réalisation AB test Déploiement Conception Prototype AB test Réalisation AB test Déploiement
- 90. Ecueils et challenges d’une stratégie data-driven Conserver de la bande passante (10% ?) pour valider ses intuitions
- 92. Data-driven Product Management Take Away Roadmap et priorisation Conception Exécution Mesure de la performance Ecueils et challenges d’une approche Data-driven
- 93. Data-driven Product Management Take Away Roadmap et priorisation Conception Exécution Mesure de la performance Ecueils et challenges d’une approche Data-driven • Manipuler des objectifs plutôt que des projets • Décliner vos objectifs en projet APRES la priorisation
- 94. Data-driven Product Management Take Away Roadmap et priorisation Conception Exécution Mesure de la performance Ecueils et challenges d’une approche Data-driven • Des hypothèses validées plutôt que des assomptions • Des tests utilisateurs au plus tôt
- 95. Data-driven Product Management Take Away Roadmap et priorisation Conception Exécution Mesure de la performance Ecueils et challenges d’une approche Data-driven • Séquencer le développement selon la valeur business des stories • Stopper les développements une fois l’objectif atteint
- 96. Data-driven Product Management Take Away Roadmap et priorisation Conception Exécution Mesure de la performance Ecueils et challenges d’une approche Data-driven • AB test autant que possible • Bien construire son groupe test • Bien choisir son indicateur
- 97. Data-driven Product Management Take Away Roadmap et priorisation Conception Exécution Mesure de la performance Ecueils et challenges d’une approche Data-driven • Culture Data <> Culture Data-driven • Apprendre de ses erreurs (et les accepter comme un mal nécessaire) • Adapter son organisation • Stay (10% ?) foolish & hungry
- 98. Data-driven Product Management Ressources Roadmap & priorisation : > Case in Point, Cosentino Conception : > L’infinite scroll chez Etsy, Dan McKinley > Why you only need to test with 5 users, Jakob Nielsen Orga > Data-driven product now, Dan McKinley
Notas del editor
- Background école de commerce généraliste, que j’ai complété plus tard par un Coding Bootcamp (le Wagon)
- Travaille depuis 8 ans …
- Dont 4 en temps que product manager.
- Chez Sarenza d’abord, avec la double casquette PM / Webanalytics. L’essentiel de la présentation s’appuie sur cette expérience.
- Puis depuis 6 mois chez Chauffeur Privé en tant que lead PM sur la partie chauffeur. PM -> je conserve un rôle de PM au quotidien avec une équipe de devs dédiée Lead -> j’encadre 2 autres PMs
- Avant de partager mon XP sur une approche produit Data-driven, revenons rapidement sur le bon moment pour adopter une telle approche.
- Pour tous les boites qui ont réussi, la courbe succès / temps ressemble à ça :
- Une première phase à la recherche du market fit, où mieux vaut aller parler à ses clients, prospects ou utilisateurs que de se lancer dans une stratégie data alors qu’on en a pas suffisamment.
- Puis une fois le market fit trouvé, une deuxième phase où le produit décolle.
- Ce point d’inflexion dans la croissance de sa boite / de son produit est : > génial > dangereux C’est (en théorie) le meilleur moment pour démarrer une approche data-driven (en théorie parce que c’est aussi un moment où l’entreprise a malheureusement rarement le temps de se poser sur des questions d’organisation, ou d’investir du temps et de l’argent des outils d’analyse ou de stockage des données.
- En effet, sans approche data-drive, toute feature semble géniale dans cette phase de croissance, puisque, justement, sa release s’accompagne de croissance.
- Sauf que cette croissance peut parfois masquer des énormes fails lors de l’implémentation d’une feature…
- …et il faudra vivre avec cette feature une fois la phase d’expansion terminée. > Dans le meilleur cas il faudra la factoriser pour pouvoir itérer dessus
- > dans le pire des cas, il faudra la killer et nettoyer ses différentes ramifications dans le code Dans les faits, l’approche data-driven est souvent mise en place en réaction à la suppression de plusieurs features ou un gros refacto, l’idée étant de ne pas revivre ce qui a été (mal) vécue en implémentant uniquement des features dont la valeur (potentielle) a été démontrée. Sur cette phase de maturité, le produit est également suffisamment complet pour que soit challengée l’implémentation de la moindre feature supplémentaire, d’où l’intérêt d’une approche data-driven.
- Du coup, c’est quoi une approche produit data-driven ? Ça commence dès la construction de la roadmap, via la priorisation.
- La méthode classique de construction de roadmap implique 2 choses : 1. établir une liste de projet
- 2. Discuter pour les prioriser La priorisation qui en ressort reflète en général l’opinion du plus convaincant ou du plus haut placé dans l’entreprise…
- … ce qui est parfait quand cette personne tient de Steve Jobs dans sa version post traversée du désert…
- … mais est risqué quand elle tient plutôt de l’homme qui a viré Steve Jobs et failli coulé Apple.
- La méthode data-drive vise à réduire ce risque en rationalisant et en objectivant la priorisation.
- L’étape 1 consiste à identifier la mission de l’entreprise et le ou les KPI qui peuvent matérialiser le succès de cette mission. Ca peut-être : > mettre toute l’information du monde à un clic de son utilisateur (Google) > connecter l’humanité (Facebook) > Faire + de CA (l’essentiel des entreprises) Dans le dernier cas, l’indicateur qui matérialise le succès de cette belle mission est … le CA.
- Prenons un e-commerçant. Son CA est décomposable en 3 sous-indicateurs : > Le trafic (# de visiteurs) > Le taux de conversion > Le panier moyen
- Laissons de côté trafic et panier moyen pour se focaliser sur le taux de conversion, qui décrit plutôt bien le périmètre d’une équipe produit chez un e-commerçant.
- Et re-décomposons cet indicateur en 4 > % visites qualifiées (= toutes les visiteurs à 2 pages ou plus), qui mesure la pertinence des pages d’arrivées par rapport au besoin exprimé initialement par l’utilisateur > % visites avec fiche produit, qui mesure la capacité du site à rapidement proposer à l’utilisateur les produits qu’il souhaite voir > % visites avec ajout au panier, qui mesure la performance de la fiche produit > % succès du tunnel de paiement, qui mesure la capacité du site à transformer un potentiel acheteur en véritable client Ces 4 indicateurs peuvent former le squelette de n’importe quelle stratégie data-driven d’un e-commerçant
- Une fois les indicateurs choisis, il faut mesurer leur état à l’instant t. Cette mesure doit permettre : > d’identifier les points d’amélioration > de calculer a posteriori les incréments des différents projets Dans l’idéal, un benchmark permettra d’identifier là où le site/l’appli sous-performe par rapport à ses concurrents.
- Enfin, il s’agit désormais de prioriser les indicateurs que l’on souhaite améliorer…
- …puis de les décliner en projets. L’intérêt de cette méthode de priorisation est de dépassionner la priorisation en ne parlant pas de projets, mais uniquement des indicateurs que l’entreprise cherche à améliorer. Elle réduit la discussion aux seuls projets qui impacte l’indicateur priorisé.
- On a désormais une belle roadmap priorisée -> la prochaine étape est la conception du projet en tête de liste.
- Le mot important de cette partie est HYPOTHESE. Une partie importante de la conception doit passer par la validation des différentes hypothèses sur lequel le projet repose. 2 approches possibles : > l’approche data-centric, lorsque l’hypothèse est vérifiable via des métriques disponibles sans développement majeur > l’approche user-centric lorsque l’approche data-centric n’est pas possible (techniquement ou financièrement)
- Etsy est une énorme marketplace US sur lequel des particuliers bricoleurs vendent à d’autres particuliers leur création maison. Dans un article (dispo dans les ressources), un de ses anciens lead tech explique l’intérêt d’une approche data-drive via le récit d’un gros fail .
- La question que se pose à l’époque Etsy est celle que se pose tout e-commerçant : comment booster la conversion sur son site. Les équipes priorisent le développement d’un scroll infini sur ses pages-liste en se basant sur 2 assomptions fortes : > les utilisateurs veulent voir plus de produits > les utilisateurs veulent voir des produits plus vite
- Une fois les développements effectués sur le scroll infini, l’équipe tech/produit d’Etsy déploie sa nouvelle page-liste en AB test
- L’ab-test est concluant : la nouvelle version est un gros fail. Persuadées du bien fondé de leur projet, les équipes creusent les données et corrigent quelques bugs, mais le résultat de l’AB test ne change pas : le scroll infini chez Etsy ne fonctionne pas.
- L’équipe décide alors de revenir sur ses assomptions de départ.
- Montrer plus de produits est-il une bonne ou une mauvaise chose pour les clients d’Etsy ? L’équipe choisit de vérifier cette hypothèse en engageant un minimum de développement.
- Etsy déploie alors en AB test 2 versions de sa page liste historique : > une version avec 80 produits > une version avec 40 produits
- Et se rend compte que montrer plus de produits à ses utilisateurs n’a pas d’impact sur la conversion.
- Pour valider son autre hypothèse de départ, Etsy ralentit artificiellement l’affichage de ses pages catalogue sur une fraction de son audience…
- … et se rend compte que de la même manière, la vitesse d’affichage n’a que peu d’impact sur ses utilisateurs (NB :ne pas en conclure que la perf. n’est pas un sujet important pour un site e-commerce ou une app. Mais seulement qu’à partir d’un certain seuil et sur le business d’Etsy, la vitesse n’a pas d’impact sur le comportement des utilisateurs) Conclusion de l’exemple Etsy : valider ses hypothèses au plus tôt permet de prioriser les bons développements, et d’écarter au plus tôt des développements qui n’apportent pas de valeur
- Toute hypothèse n’est pas aussi simple à valider que celles qu’Etsy aurait dû faire dans l’exemple précédent. Le travail de développement nécessaire à l’analyse à travers les chiffres d’un comportement utilisateur peut parfois être aussi lourd que le projet lui-même. Pour ces cas, l’approche user centric peut apporter de nombreux enseignements, en proposant à quelques utilisateurs bien choisis des prototypes dès le début du projet. Cette présentation étant dédiée à une approche data-drive, la question se pose alors de savoir sur combien d’utilisateurs le test doit être réalisé pour un apprentissage optimal.
- Voici la réponse. Dans une étude qui date de 2000, Jakob Nielsen s’intéresse à la question et aboutit au graphique présenté dans ce slide. 3 points importants sur ce graphique.
- Le premier : avec 0 test utilisateur, on trouvera 0 problème quelque soit la feature ou l’interface testé. Le meilleur moyen de trouver son idée géniale est donc de ne pas la tester. Je ne recommande pas.
- Le second : 5 tests utilisateur bien fait permettent de trouver 80% des problèmes d’usabilité d’une feature ou d’une interface.
- Et le dernier : des tests menés auprès de 15 utilisateurs permettent d’identifier 98% des problèmes présentés par une interface, les 2% restants n’étant en général pas identifiables par des tests utilisateurs 15 est-il le chiffre parfait ? Oui si vous avez le temps et les ressources.
- Non sinon. En effet, l’essentiel des problèmes qui vont être identifiés lors des tests 6 à 15 …
- … ont déjà été identifiés lors des tests 1 à 6.
- Dans son papier, Nielsen en conclut : > que le test utilisateur qui apporte le plus de valeur est conduit sur 5 tests utilisateurs et permet d’identifier 80% des problèmes > que l’idéal est de conduire 3 itérations de 5 tests, en proposant à chaque itération une version qui tient compte des retours faits sur l’itération précédente.
- La phase de développement est celle sur laquelle il peut sembler le plus difficile d’opter pour une approche data-driven. Et pourtant…
- … les méthodologies agiles (Scrum ou Lean) ont toutes mis en place des suivis d’indicateurs de performances. A travers les calculs de vélocité (SCRUM) ou les mesures de gaspillage (LEAN), elles visent à optimiser la phase de développement pour maximiser la valeur créée.
- Un contre-exemple et un exemple avec 2 projets menés chez Sarenza. Le premier est le développement de l’appli mobile (2015). Une approche cycle en V est retenue, avec une volonté d’aller au plus vite. Toutes les stories font l’objet de spécifications détaillées en amont des développements. Ceux-ci sont parallélèlisés au maximum afin de raccourcir les délais de livraison du projet. Le problème habituel se pose en fin de projet. Alors que 80% des développements théoriques sont effectués …
- … 0% de la valeur peut être livrée, puisqu’aucune story « importante » n’est terminée. De plus (et pire), aucune story n’est testable avant la fin des développements -> la recette finale aboutira sur la création de plus de 1000 tickets.
- Les approches agiles n’évitent pas les bugs. Le projet de refonte technique de Sarenza (2016-2017) a probablement abouti sur la création d’autant de tickets (avec pourtant un score plus large). En revanche, la méthode choisie aurait pu permettre une livraison plus rapide d’un maximum de valeur utilisateur. Une première phase a consisté à lister les stories souhaitées, et à les trier par valeur business décroissante.
- Pour certaines stories c’est évident (part du CA réalisé par des ventes payées par CB et livrées à domicile)
- Pour d’autres c’est moins simple. Le CA représenté par les favoris a été estimé via les ventes réalisées par les visites générées par la newsletter favori.
- Pour d’autres, il faut faire preuve d’imagination. Une approche possible pour évaluer la valeur business de la FAQ est de faire une hypothèse sur le nombre de contact client qu’elle permet d’éviter, et de multiplier par le cout de gestion d’un contact. L’important n’est pas la précision des évaluations, mais de pouvoir évaluer relativement la valeur de chaque story par rapport aux autres.
- Cette approche permet : > de démarrer les développements plus rapidement, puisque les spécifications peuvent être rédigées au fur et à mesure du développement des stories. > et de décider AVANT la fin des développements de releaser une nouvelle version du site (ou une fonctionnalité) si le PM estime que l’essentiel de la valeur business est apportée par les développements réalisés.
- Une fois le projet livré, il s’agit ensuite d’en mesurer la performance, afin : > d’éviter de déployer une version sous-performance > d’éviter de déployer un version bugguée > d’évaluer si le projet permet d’atteindre les objectifs fixés ou nécessite une nouvelle itération
- La méthode la + adaptée : l’AB test.
- L’AB test est en effet, sur un produit digital, la seule méthode permettant d’affirmer avec une certaine certitude (dépendant des paramètres choisis pour le test) qu’une feature apporte de la valeur et doit être déployée sur l’ensemble des visiteurs
- Ou qu’il faut la jeter (ou la retravailler)
- Au delà de la mesure de perf, l’AB test permet aussi de monitorer le bon fonctionnement d’une feature. Un exemple avec un projet de refonte des filtres sur les pages catalogue de la version mobile du site de Sarenza. La version désignée lors du passage du site au format responsive design générait de nombreuses plaintes de la part des utilisateurs (tout en étant bien plus performante que la version précédente, absolument pas mobile friendly).
- Une nouvelle version avait été implémentée résolvant les principaux problèmes utilisateurs, ce qu’une série de tests avait permis de valider. Confiant mais prudent, nous poussons la fonctionnalité revue et corrigée en production via un AB test.
- -> c’est un échec.
- Une analyse poussée de nos analytics nous permet d’identifier que la nouvelle version performe davantage sur Android, comme anticipé, mais que les chiffres sont mauvais sur iOs. Coïncidence (pas vraiment), l’UX ET le product manager en charge du projet possèdent un Android. Une série de test plus poussée est alors réalisée sur iOs, et fait apparaître de nombreux bugs sur cette plateforme. Ceux-ci sont corrigés, l’AB test est relancé
- Et devient un des succès de l’année. Dans cette exemple, au-délà de la mesure de performance, l’AB test a permis : > d’identifier des bugs non corrigés lors de la recette initiale > d’améliorer nos process interne de recette, en intégrant systématiquement une recette avancée sur les 2 plateformes mobiles.
- Attention toutefois aux AB test mal réalisés. Un exemple avec l’implémentation d’une feature d’aide au choix de la pointure sur les pages produit de Sarenza. L’outil est proposé par un prestataire, et permet à l’utilisateur de trouver sa pointure pour la chaussure qu’il envisage d’acheter, en se basant sur une grille de correspondance avec un catalogue de chaussure de marques diverses et variées. Il peut renseigner sa pointure pour la paire qu’il a aux pieds et l’outil lui renvoie sa pointure pour la paire consultée.
- Nous déployons cette feature en AB test, avec de grand espoir > sur une amélioration du %age d’ajout au panier, le choix de la taille étant un des freins principaux à l’achat d’une paire de chaussure en ligne > sur une réduction du taux de retour, dont l’un des principaux motifs est une pointure inadaptée. En // de la mesure effectuée par le prestataire, nous déployons notre solution d’AB test maison. Les indicateurs sont similaires pour le groupe témoin (= qui n’utilise pas l’outil du prestataire)
- En revanche, le prestataire mesure un incroyable incrément de performance, alors que notre solution maison ne nous permet pas d’affirmer que l’outil créé de la valeur ( pour la petit histoire, nous détectons bien un incrément de performance avec l’outil testé, mais qui n’atteint pas le seuil de significativité que nous avons fixé en interne pour nos tests.
- Après une collaboration plus poussée dans l’analyse de nos chiffres respectifs, nous nous rendons compte que : > notre groupe test est composé de l’ensemble des utilisateurs à qui la feature est proposée (qu’ils l’utilisent ou non) > que le groupe test du prestataire ne comprend QUE les utilisateurs effectifs de son outil. Or, un test précédent nous a appris que les visiteurs interagissant avec la zone des pointures composent déjà un sous groupe de nos visiteurs dont les performances sont largement supérieures à l’ensemble de nos visiteurs.
- L’erreur de méthodologie du prestataire est donc d’avoir comparé : > un groupe témoin représentatif de l’ensemble de nos visiteurs > un groupe test représentant un sous groupe de nos visiteurs, beaucoup plus proche de l’achat que notre visiteur moyen
- Autre risque lors de l’implémentation d’un AB test : le choix d’un mauvaise indicateur. Ce slide ainsi que le suivant montrent 2 implémentations de la même page, où le temps total de chargement de la page est rigoureusement identique. Pourtant, la vitesse de chargement perçue par l’utilisateur est supérieure sur une des 2 implémentations, où l’affichage des éléments composant la page se fait progressivement versus l’autre, où cet affichage est fait en un seul bloc au terme du chargement.
- Les indicateurs pour lesquels la perception de l’utilisateur entre en compte (typiquement, la vitesse d’un site) sont à manier avec précaution lors d’un AB test. La meilleure façon de se prémunir de ce type d’erreur est de toujours choisir des indicateurs business (taux de conversion, taux d’ajout au panier …), plutôt que des indicateurs visant à évaluer un ressenti utilisateur (temps, nombre de pages vues …)
- Dans certains cas, ou faute de moyens, on pourra toujours se contenter d’une comparaison de la situation AVANT implémentation de la feature versus APRES. Cette méthode montre clairement ses limites dans les cas > où l’indicateur suivi fluctue fortement dans le temps (exemple : le taux de conversion) > où l’incrément de performance espéré est marginal (exemple : la plupart des features implémentées pour des motifs de branding plutôt que de performance.
- Si l’approche data-driven est probablement l’approche la plus rationnelle pour optimiser un produit existant, elle n’en reste pas moins difficile à implémenter. Quelques exemples dans cette partie.
- Tout est dit sur ce slide.
- Tout mesurer implique de souvent se rendre compte qu’on s’est trompé -> une approche date-driven doit reposer sur la volonté d’apprendre et sur la perception de l’échec comme moteur d’apprentissage. NB : se tromper n’est pas une fatalité mais ne doit pas non plus devenir une fin en soi. Arriver à son objectif du 1er coup doit rester la priorité ;)
- Le plus gros challenge d’une approche date-driver est probablement la nécessité de refondre ses process (et probablement son organisation). Alors que la progression attendue d’un projet est habituellement : > conception > réalisation / développement > déploiement
- L’ajout d’un AB test vient perturber cet enchaînement en reportant de quelques semaines / mois le déploiement attendu.
- Si ce décalage reste limité dans le cas où le test s’avère positif,
- Il peut également montrer la nécessité de redémarrer une phase de conception ou de développement sur la fonctionnalité que l’on espérait déployer.
- Auquel cas le déploiement est encore reporté.
- Pour éviter les projets dans fin, l’organisation produit doit alors être repensée pour limiter au maximum la durée des phase de conception et le périmètre des fonctionnalités livrées. Une première itération peut être déployée simplement pour valider une hypothèse ou tester un prototype. L’analyse des premiers chiffres doit ensuite permettre de donner un go ou un no go sur la poursuite des efforts de l’équipe. Etc.
- La méthode data-driven devient alors une suite sans fin d’optimisation sur le produit existant. L’approche projet est complètement abandonné au profit de multiples itérations sur le produit,
- Afin de conserver une vélocité cohérente avec les impératifs de l’entreprise, l’équipe produit peut dans ce cas dédier plusieurs streams de développements à un objectif en particulier (= ne pas mettre tous ces oeufs dans le même panier)
- Dernier point. La méthode data-driven optimise incroyablement bien un produit existant. En revanche, elle pêche à identifier de nouvelles opportunités disruptant l’existant. Les entreprises data-driven les plus innovantes pallient le problème en dédiant une bande passante à des projets de R&D dont la finalité n’est pas d’améliorer le produit existant, mais de concevoir le produit de demain. Voir Google avec son laboratoire Google X et ses produits « moon shot »