Transcription de l'épisode : "Enzo Escobar, La data science au service du produit et du business : le product analytics"
Terry : Salut Enzo.
Enzo : Salut Terry.
Terry : Merci du coup de me recevoir aujourd'hui. Donc aujourd'hui on va parler de Product Data Analytics. On va essayer de démystifier un peu.
Enzo : Exactement. Alors pour me présenter rapidement, j'ai une formation école d'ingénieur et après j'ai commencé à travailler dans ce qu'on appelle l'optimisation, la recherche opérationnelle qui est vraiment de l'optimisation mathématique. De là après je suis parti chez Criteo où j'ai découvert le métier de Product Analytics. Et après mon expérience à Criteo, je suis parti chez Unfido, l'entreprise pour laquelle je travaille aujourd'hui, pour créer le département de Product Analytics. Et donc qu'est-ce que c'est en quelques mots Product Analytics ? C'est un profil de, en général, Data Scientist, qui travaille fortement avec les Product Managers et avec les équipes Engineering. C'est vraiment le lien entre un product manager et la partie un peu plus technique des développeurs pour résoudre beaucoup de problèmes et apporter un support au product management.
Terry : Ok, très très clair comme intro du coup pour nous dire qu'est-ce que fait Onfido ? Donc même tu peux, enfin Criteo rapidement pour ceux qui n'auraient pas entendu le nom de cette entreprise mais surtout Onfido qu'est-ce que vous faites aujourd'hui ?
Enzo : Alors Criteo rapidement, donc Criteo c'est une entreprise qui fait de la pub sur internet donc quand on se balade sur des sites internet il y a des pubs souvent Criteo est derrière ces pubs là. et Onfido est une boîte qui a été créée à Londres et qui est spécialisée dans la vérification d'identité. Alors ça peut paraître un peu large, qu'est-ce que fait Onfido précisément dans ce secteur-là ? Onfido va être responsable de vérifier quand on essaye de capturer dans une application un papier d'identité, Onfido va avoir des algorithmes de machine learning pour détecter si le document est un document, un vrai document, un document original. et des algos pour vérifier que par exemple la personne qui prétend être cette personne là est la même par exemple en prenant un selfie et en comparant la photo sur une pièce d'identité.
Terry : Donc ça c'est vrai que quand tu m'avais expliqué ce que vous faisiez, cet exemple du selfie il est quand même assez parlant je pense pour toutes les personnes qui ont déjà dû prouver leur identité. sur des services notamment financiers en ligne, donc quand on prend sa photo, qu'on met la carte d'identité à côté, c'est.
Enzo : Ce type de validation. Exactement, nos clients vont être par exemple les banques, beaucoup de banques en ligne qui digitalisent énormément leur parcours. On va avoir des clients qui sont dans la cryptomonnaie, qui sont des plateformes de cryptomonnaie, qui aussi ont des obligations financières, un petit peu comme justement les établissements bancaires. On a aussi une autre partie de nos clients qui sont tous les loueurs de voitures ou les intermédiaires lors de l'allocation de voiture pour vérifier que le permis est un vrai permis, pour vérifier que telle personne a le droit de conduire ce type de véhicule ou pas, et ainsi de suite. Donc ça c'est nos principaux use case aujourd'hui.
Terry : Très clair, très clair. Donc là-dedans, pour faire ces missions, vous avez beaucoup de données. Donc pour rentrer dans le vif du sujet de ce que tu fais aujourd'hui, de l'équipe dont tu es le responsable, tu parlais un peu du product analytics en expliquant que ça permettait de faire le lien à la fois entre la partie purement technique data et la partie plus business, donc un peu à l'image du métier de product manager sur des applications plus SaaS classiques. Si tu devais replacer ce rôle dans une répartition que je vais faire par rapport à un autre épisode que j'avais fait autour du Data Engineering avec Corentin, on avait parlé du rôle Data Scientist qui était plus un rôle, je le dis avec mes mots, de statisticien qui va travailler sur les modèles d'un point de vue R&D. Il y avait ensuite le Data Engineer qui était là pour créer des pipelines entre ces modèles-là et surtout les industrialisés pour servir enfin le troisième rôle qui était plus les business analyst ou les data analyst qui eux étaient très proches du métier et parfois des profils moins techniques mais qui allaient avoir quelques dashboards et savoir plutôt comment utiliser la donnée d'un point de vue métier justement que technique. Toi où tu repositionnes le rôle du coup ?
Enzo : Alors c'est effectivement dans tous les exemples que tu donnes ça peut paraître assez loin du produit finalement Nous, on est vraiment beaucoup plus proche du produit et selon la maturité d'une feature que tu développes, on va avoir des rôles différents. Mais tous ces rôles font partie de la mission du Product Analytics aujourd'hui. Donc si on prend le début de la création d'une feature, d'où vient l'idée, comment est-ce qu'on essaye de lancer des nouvelles idées ? Nous, on est spécialiste de la donnée, on a le nez dans la donnée tout le temps. Et comme on est dans la donnée, on est capable d'avoir des insights un peu différents, d'attaquer le produit par des angles qui n'ont pas été regardés autre que par la data. Et donc, à partir de ce moment-là, on peut essayer de se dire, ah tiens, finalement, il y a une opportunité, je ne sais pas, sur ce marché, avec tel produit, on ne l'avait pas vu, mais il est peut-être un peu en dessous des autres, finalement, d'une autre verticale ou d'un autre produit qui fait à peu près la même chose. Donc, on est là pour aider à amener des nouvelles idées. Un product manager va, par exemple, être beaucoup... Nous, on n'est pas proche du client, mais un product manager va faire beaucoup d'interviews clients pour nourrir une roadmap. Nous, on va être plutôt la partie data en regardant nos données pour amener des idées. Ensuite, souvent les entreprises fonctionnent avec un processus d'OKR. Donc les OKR, c'est des objectifs trimestriels et on veut essayer de planifier un peu ces projets et on doit choisir à ce moment-là. Avant de lancer un trimestre, on doit choisir quel projet on veut faire. nous on est là pour aider à sizer les opportunités. Donc ça peut être vraiment, le product manager va nous dire tel client, il me dit qu'il a absolument besoin de cette feature, nous on va se dire tiens il y a peut-être ça. Finalement on les met sur la même balance, on trouve des KPI communs, on trouve une manière commune de les évaluer, on est là pour aider à sizer, pour prioriser la roadmap d'un point de vue opportunité data. Ce qui est différent du point de vue peut-être business qui est peut-être pour une Certification va avoir besoin d'aller vers cette, de créer cette feature alors même que ça va pas créer de la valeur d'un point de vue purement data. Mais nous on est là pour aider en tout cas à sizer toutes les opportunités au début avant de lancer une feature.
Terry : Donc une première pause ici, garde ce que tu as en tête pour continuer, mais donc une première pause là-dessus. Donc est-ce que si je dis que vous êtes, alors peut-être pas support, allez on va dire c'est comme ça, en support au product manager qui eux, au product manager plus métier, est-ce que c'est correct ?
Enzo : Oui c'est exactement ça, à la fin c'est quand même un product manager qui va prendre la décision de sa roadmap. Mais nous on lui apporte vraiment ce côté quantitatif en fait, qu'il ait toutes les données en tête pour pouvoir prendre sa décision et la meilleure décision possible. Donc de ce point de vue là on est vraiment au support des équipes produits pour qu'ils puissent construire leur roadmap le mieux possible avec le plus d'impact possible.
Terry : D'accord. Et donc, par rapport à ces insights que vous apportez au Product Manager, du coup, dans vos rôles de Product Analytics, quelles sont les différences que tu vas voir principales avec les trois métiers dont je parlais juste avant ? Donc, la partie purement Data Science, la partie plus Data Engineering et la partie plus Business Analytics. Moi, je te dis, tel que je le comprends par rapport à ce que tu m'expliques, c'est qu'en fait, il faut avoir un peu des trois. Donc, je suis curieux, voilà.
Enzo : Alors, il faut avoir un peu d'étroits. Ce qu'on a le moins, je veux dire, on va partir dans ce sens là, ce qu'on a peut-être le moins, c'est la partie vraiment infra data engineering qui arrive, selon la taille d'entreprise, après c'est dédié ou pas. On construit nos propres pipelines de données pour pouvoir regarder le produit, pour monitorer nos propres KPI aussi, pour le comprendre. Mais on est moins spécialisé sur le data engineering. Sur la partie data scientist, on n'est pas des chercheurs. Par contre, on va créer des modèles. Mais souvent, nous, on n'a pas de rôle de responsabilité de production, par exemple. On ne va pas mettre un algorithme en production. On va essayer de défricher des choses. Et ensuite, souvent, c'est des équipes recherche ou des data scientist qui sont plus proches de la prod. un peu plus loin du business, mais on va après discuter avec eux pour leur expliquer finalement quel type de modèle on a trouvé, qui peut être intéressant et essayer de faire vraiment ce lien parfois entre un product manager qui n'est pas spécialiste de ça et qui n'a pas le même langage, ça peut être compliqué parfois juste d'expliquer, d'exprimer ce qu'il veut dans un langage plus mathématique, plus scientifique, plus data scientist. Et côté business, alors là où on a nos interactions avec le business, pour nous le business, les analystes qui sont plutôt business sont vraiment souvent responsables de certains comptes ou de certains marchés. Nous on est, je veux dire qu'on est au siège entre guillemets, on est là pour supporter un peu tout le monde et on va leur expliquer sur certaines parties de produits qui ne sont pas forcément évidentes, comment est-ce qu'ils peuvent en parler aux clients, qu'est-ce qu'il faut regarder, comment est-ce que... Comment vérifier qu'un produit ou qu'un client marche bien en regardant la donnée ? Par contre, nous, on ne va pas faire les rendez-vous clients. Il y a parfois les QBR qui existent dans certaines entreprises. Chaque trimestre, souvent, par exemple, on rencontre nos clients clés et on fait un bilan du trimestre. Là-dedans, il y a pas mal d'analyses aussi. Nous, typiquement, on ne fait pas ce genre d'analyse. Par contre, sur certains points spécifiques, ça peut nous arriver d'être au début client pour vraiment des produits, enfin des parties spécifiques du produit plus techniques. Parce que nous, dans l'équipe, chaque Data Scientist est responsable de son produit. Donc il faut un peu nous voir comme un expert. Chaque membre de l'équipe est un peu expert de son produit. Là où les analystes business, ils ratissent plutôt large parce qu'ils vont avoir des questions sur tout et n'importe quoi de la part du client. Donc ils vont faire le premier niveau de support et nous on viendra supporter ces analystes là. Et c'est un peu ça la différence, c'est qu'on touche un peu à tout, mais les principales différences, on n'est pas customer facing et on n'a rien en prod vraiment qui sert le business, enfin qui sert la prod.
Terry : D'accord, donc si je devais prendre un exemple aussi de... Alors peut-être qu'après tu peux prendre un exemple sans trahir de secret ou autre, mais un exemple qui te parle d'un cas pratique que tu as pu avoir avec ton équipe et de comment vous l'avez traité. Avant d'aller sur ce cas pratique, je suis curieux de comprendre du coup, au quotidien, qu'est-ce qui va en fait driver, si tu veux, votre besoin. En gros, la semaine commence ou le mois qui vient, comment est-ce que vous allez un peu savoir ce sur quoi vous allez travailler ? Est-ce qu'on est sur un mode flux tendu ? Là, il y a une fonctionnalité qu'un product manager veut aller défendre auprès du comité de direction, et du coup, il vient vous voir pour essayer de trouver des insights qui vont pouvoir valider le fait qu'il faut la faire. Comment est-ce que vous, votre charge de travail, allez identifier ?
Enzo : C'est un mélange de deux. D'abord, on a, je dirais, On essaie de s'organiser en 70%, 30%. 70% c'est des OKR, on a nos propres OKR, donc on a nos propres objectifs du trimestre, on les présente chaque trimestre comme les produits, comme certaines équipes de dev. Donc on a vraiment nos projets qu'on essaye de planifier à l'avance et s'assurer à travers ce processus qu'on est bien aligné avec le besoin de l'entreprise dans les projets qu'on veut faire. C'est important parce que c'est vraiment cet alignement qu'on cherche à travers ces objectifs trimestriels.
Terry : Et ces projets dont tu parles, c'est des projets qui vont permettre de faire quoi ? C'est les produits qui vous sont internes qui vont permettre de faire quoi ?
Enzo : Alors, ça peut être différentes choses. Ça peut être tester, par exemple, une nouvelle future. Je reviendrai sur le cas pratique, mais ça peut être... On se dit que là, il y a peut-être de la valeur. Peut-être qu'il faut une expérience pour pouvoir réussir à faire de la valeur. créer des outils plus support pour toute l'entreprise. Par exemple, nous on a poussé les A-B-Tests beaucoup et donc on a créé une plateforme d'A-B-Tests en interne qui va être utilisée par toutes les équipes aujourd'hui. Donc ça dépend vraiment de la feature, éventuellement de la maturité aussi de la feature, mais ça peut être créer un nouveau pipeline de données pour pousser la donnée du point de vue analytique, encore une fois pas en termes de prod, s'assurer qu'on a les bonnes données pour prendre une décision le trimestre d'après. Quand ça n'existe pas, ça peut être un travail qui prend plusieurs semaines avec beaucoup d'équipes différentes. Donc on a ce genre de projet aussi. Et ensuite, par rapport à ce que tu dis, est-ce qu'il y a parfois des product managers qui ont des présentations importantes ? Effectivement, ça arrive. Et là, on est là aussi en support pour essayer de lui donner la data, essayer de parfois construire des slides, une histoire avec lui. Mais c'est vraiment pas le... On est là en support, ça fait partie de notre travail, mais c'est pas comme ça qu'on s'organise. On essaie vraiment d'avoir plutôt les projets sur le trimestre pour avoir de la visibilité. Mais ça arrive et ça fait partie de notre travail.
Terry : Ok, hyper intéressant. Du coup, si tu devais prendre là un cas pratique qui te vient en tête, avec notamment des bons apprentissages que vous avez pu avoir sur ce cas-là.
Enzo : Par exemple, pour donner un exemple qui va peut-être aller à travers beaucoup d'étapes de tout ce process dont j'ai parlé. Donc, chez Unfido, on a ces pièces d'identité. Dessus, il y a par exemple le prénom, le nom, il y a des champs qui sont ce qu'on appelle des champs, donc des entrées sur ce document. qui sont nécessaires pour nos clients d'un point de vue légal, donc on doit les extraire. Et on a un certain niveau de sécurité, dont un qui s'appelle chez nous Data Comparison, où par exemple quelqu'un remplit un formulaire avant, donc va mettre son nom, son prénom, nous on va avoir le document, on va extraire le nom, le prénom et on va vérifier si ça marche, si c'est la même chose. Parfois il ne l'écrit pas exactement de la même façon, parfois il fait des typos, parfois c'est de la fraude. Donc il y a tous les cas et la manière un peu naïve de le faire, qui était la première manière de le faire parce que c'était la plus simple, c'était de regarder exactement ces deux entrées et vérifier si ça marche exactement. Le problème c'est qu'avec ces histoires de typos ou même juste une histoire d'usage, je sais pas si par exemple moi j'ai pas l'habitude d'écrire mon deuxième prénom mais sur ma carte d'identité il y a mon deuxième prénom, quand je remplis un formulaire et je regarde ma pièce d'identité ça marche pas exactement donc c'est pour ça que je dis que c'est naïf en fait il y a plein de cas qui sont tout à fait normaux pour lequel ça match pas exactement, c'est pas exactement la même chose. Du coup nous on s'est rendu compte avec, ça vient de l'équipe, on s'est dit ok là dedans en fait on se rend compte qu'on a beaucoup d'erreurs à cause de ça, ça pourrait représenter x en automation, enfin peu importe la métrique, mais il y a de la valeur là dedans et on a commencé à du coup se dire est-ce qu'on pourrait pas essayer de trouver une meilleure méthode que cette méthode naïf pour comparer le nom et le prénom. Et on a commencé, donc on a pris un quart d'heure de notre côté à essayer différentes méthodes, vraiment essayer différentes, ce qu'on appelle des distances entre des chaînes de caractères.
Terry : Du coup, je te fais faire une pause, un désolé juste sur ça, parce que je trouve ça hyper intéressant. Là, je prends mon regard product, tu me dis, on s'est rendu compte par rapport à la donnée que l'on avait et qu'il y avait énormément d'erreurs là et enfin qu'il y avait beaucoup de données à ce niveau là et donc on s'est dit il y avait potentiellement de la valeur à créer derrière. C'est quelque chose là du coup qui est venu de votre équipe de product data analytics et pas d'une équipe de product manager.
Enzo : Ouais, alors avant de lancer, quand on fait un trimestre pour essayer de réparer, de voir s'il y a mieux, l'arbitrage est fait avec l'équipe produit. Donc c'est vraiment, l'idée va venir, donc on a une phase d'exploration dans notre travail pour essayer de trouver ce genre de choses. Et après, on passe un peu dans ce process que je décrivais avant qui est, on va essayer de mesurer les opportunités. Et ça, on le fait avec l'équipe produit, on valide aussi avec l'équipe engineering pour vérifier que, en fait, si on trouve quelque chose, c'est implémentable. Et c'est qu'on peut le faire, on peut le passer en prod. Plus ou moins, il y a parfois des gros bloqueurs et on se dit, bon, en fait, il y a peut-être de la valeur, mais ça, on n'aura jamais le droit de le faire ou, techniquement, ce sera pas possible, ça va nous coûter trop cher à faire, même si on trouvait la méthode parfaite qui donne le bon résultat. Donc cet exemple que je prends, il effectivement vient de notre équipe, mais l'équipe produit est une sorte de sponsor si on veut sur ce projet.
Terry : Très clair là-dessus, et juste pour être sûr de comprendre sur ce point, si je disais par exemple que vous avez cette capacité dans votre périmètre donné de proposer des fonctionnalités ou proposer des choses autour du produit, qui viennent d'input en fait, qui est de la donnée, d'input de la data, là où les product managers, en tout cas chez Anfindo, vont plutôt eux avoir des propositions de fonctionnalité ou d'amélioration, qui vont plutôt venir du coup de problématiques business, et donc qui viennent des clients directs.
Enzo : Ouais, exactement. Les frontières sont un peu plus poreuses que ça, mais globalement c'est vraiment ça l'idée. Chez nous, le product manager va vraiment sentir le marché, va se faire la voix du client. Là où non, on va pousser avec les données qu'on a en interne, des nouvelles idées, on va trouver des choses qui ne sont pas forcément accessibles par quelqu'un qui n'est pas à l'aise dans la data parce qu'on a des dashboards, on a des choses en self-service, mais à un moment, nous, on a l'habitude d'aller plus bas que ça quand on a des besoins particuliers.
Terry : Hyper intéressant, je trouve, comme approche. Je te laisse du coup continuer à dérouler.
Enzo : Ouais, alors là-dessus, on a travaillé pour essayer de trouver une bonne manière de réussir à trouver les cas où c'est pas écrit pareil, mais en fait c'est la même chose, des cas où c'est pas écrit pareil et c'est de la fraude. Parce qu'on essaie quand même d'arrêter de la fraude, c'est la mission d'Anfido. et là dessus donc on a plein de métriques après ça c'est vraiment très product analytics on a beaucoup beaucoup de métriques on se dit bon on veut qu'on est prêt à dégrader un petit peu sur cette métrique là là on va gagner beaucoup est-ce que l'un dans l'autre on est d'accord et à la fin on reboucle avec l'équipe produit en disant ok Si jamais on se trouve une solution qui te fait gagner ça mais qui te fait perdre ça, est-ce que toi, en tant que produit, tu es d'accord ? Est-ce que tes clients vont accepter le gain au prix de cette perte ? Quelque part, peut-être un gain de rapidité pour une qualité un petit peu moins bonne. Donc, c'est ce genre d'arbitrage. Nous, pour le coup, on ne les fait pas. On travaille beaucoup avec produit et c'est l'équipe produit qui prend la décision à la fin de se dire OK. celui-là ça marche, cette métrique qu'on va dégrader un petit peu finalement le client elle n'est pas très importante comparé à la métrique qu'on va réussir à améliorer ou ah non non non ça c'est vraiment c'est un besoin légal et donc en fait même si ça pourrait nous faire gagner beaucoup on n'a pas le droit de toucher cette partie là du produit. Donc on arrive dans ce process où avec Produ on décide quel est le juste milieu et ensuite nous on va discuter. Ensuite c'est la création de l'idée de la feature, ensuite on va vraiment l'implémenter et là on va faire le lien avec l'équipe d'engineering. pour se dire ok on veut partir là dessus on vous fait un peu des aspects techniques de notre côté il faut l'implémenter de telle façon et nous on va être responsable c'est dans cette partie là du schéma de données et de l'expérimentation c'est à dire schéma de données c'est s'assurer que la donnée qu'on va créer va être consommable par le reste de l'entreprise on veut pas quelque chose qui crée de la donnée mais on ne pourra jamais la regarder sous un autre angle. Par exemple, si je reprends cet exemple de comparaison de nom-prénom, on veut pouvoir se faire des analyses par type de document par exemple. Je veux pouvoir quand même comparer les documents français et les documents italiens, je veux pouvoir distinguer les deux. Et donc nous, c'est important, on est là pour s'assurer que la donnée va être consommable par le reste de l'entreprise.
Terry : Donc là-dessus, l'une des responsabilités que vous avez, c'est qu'au-delà de l'apport en valeur que va avoir ce que vous proposez comme fonctionnalité, il faut que ça aille au-delà puisque ça va quand même mettre des efforts derrière tech qui ne sont pas négligeables, que cette donnée ne soit pas juste utilisée pour cette fonctionnalité mais qu'elle puisse avoir un...
Enzo : Exactement, on fait partie des équipes garantes de l'intégrité de la donnée dans toute l'entreprise. Sur les features sur lesquelles on travaille, c'est important qu'on connaît le data model de toute l'entreprise et c'est important de... on est là pour spécifier les choses et du coup c'est important qu'on se soumette aussi à cette intégrité pour s'assurer que la donnée est consommable par le reste de l'entreprise. Le reste de l'entreprise est en notre équipe, mais quelqu'un qui va travailler sur une autre feature. On est les premiers utilisateurs, en fait, aussi de cette intégrité de données-là. Et pour nous, c'est très pénible dans notre travail quand on n'arrive pas à faire parler les données facilement. Donc, on a aussi un incentive fort à faire en sorte que ce soit bien. On est là sur la partie expérimentation, donc je parlais d'AB test avant, je ne sais pas si tu veux parler d'AB test. Si, bien sûr. Pour résumer un AB test, on compare, on veut essayer une nouvelle feature et puis on essaye de voir si ça marche mieux ou pas, pour simplifier. Et pour ça, en fait, on a créé des outils, des protocoles, et c'est une manière de faire qui nous... qui donne à la fin une espèce de tampon de dire, OK, cette feature apporte de la valeur à l'entreprise. Peu importe comment on définit valeur, mais c'est ce framework qu'on utilise, nous, aujourd'hui. Et quand je suis arrivé, il n'y avait pas d'AVTest à Onfido. Et une partie du rôle de Product Analytics, c'est d'amener ça pour pouvoir, à la fin, dire, OK, cette feature, elle a le tampon Product Analytics. On sait qu'elle amène de la valeur d'un point de vue data. Donc on a vraiment ce rôle data, mais à la fin c'est quand même un produit, c'est un product manager qui va décider. Parce que comme je disais, nous ça arrive souvent chez Onfido, on a besoin de nouvelles certifications. Pour ça on a besoin peut-être de rajouter une étape dans un flow utilisateur qui va créer de la friction, qui va du coup réduire le conversion rate, mais on va avoir une certification qui va peut-être déclencher du business demain. Ou juste pour pouvoir continuer à opérer. Parfois c'est des choses qui arrivent aussi, les gouvernements peuvent être de plus en plus exigeants pour pouvoir opérer sur leur territoire. Donc nous on va, typiquement là, on va dire ok, cette feature qu'on a créée pour réussir à avoir cette certification, elle va nous coûter entre guillemets X dollars, en tout cas elle va dégrader la performance de notre produit, mais c'est le product manager qui va décider du rollout ou pas à la fin pour dire ok, bon, ça nous coûte tant, cette perte elle est acceptable. Le product manager lui va voir aussi, il parle avec le business, avec les sales, donc il va se dire ok, ça va nous coûter tant maintenant mais je pense qu'avec mes équipes Sage je peux développer tel marché grâce à ça maintenant. Donc c'est lui qui va prendre notre input, prendre d'autres inputs à la fin pour pouvoir dire, pour pouvoir décider s'il fait un rollout ou pas. Mais nous on est vraiment le garant dans la data, dans l'expérimentation de dire ça ramène ou ça détruit de la valeur.
Terry : Hyper intéressant et surtout ce que je me dis c'est qu'en tant que PM vous êtes une équipe de rêve avec laquelle t'as envie de bosser parce que vous allez être source de données hyper qualitatives et quantitatives mais qui sont qualitatives pour justement derrière pouvoir prendre des décisions beaucoup plus informées et avoir une approche beaucoup plus comme on dit data-driven, enfin beaucoup plus vraiment rationnel sur les choix derrière de fonctionnalités. Du coup la question que je me pose par rapport à ça, donc tu as parlé d'A-B testing, donc comme tu le disais l'A-B testing c'est quand t'hésites par exemple, le cas le plus courant qui va parler à beaucoup de gens c'est tu vas juste avoir pour n'importe quel site une landing page sur lequel t'hésites entre mettre sur ton bouton s'inscrire ou être rappelé par exemple, tu vas tester d'envoyer une landing page à X milliers d'utilisateurs avec le bouton s'inscrire et une autre landing page être rappelé à d'autres X milliers d'utilisateurs et puis tu vas voir lequel fonctionne le mieux. Donc l'approche A-B testing c'est ça, c'est que tu testes tes... des deux fonctionnalités en parallèle sur deux sets différents d'utilisateurs. La question que je me pose donc c'est par rapport à ces... donc t'as parlé aussi en fait de Discovery, t'as parlé du fait derrière d'aller chercher des opportunités, d'aller comprendre aussi les usages des utilisateurs, donc je me demande jusqu'où votre périmètre va en termes de collecte de données pour le produit, est-ce que c'est l'ensemble des données qui peuvent être pertinentes d'un point de vue derrière design de fonctionnalité, compréhension de son utilisateur que vous vous traitez ou est-ce qu'il y a certains périmètres dont vous ne vous occupez pas. L'exemple que j'ai en tête, pour compléter cette question, c'est dans le cas, donc je ne sais pas si vous avez une version mobile du coup de votre produit, mais tu vas avoir des stats d'usage de ton utilisateur sur le nombre de temps qu'il va rester sur ton app ou sur telle ou telle page. Est-ce que l'ensemble des données sont gérées par le Product Analytics ?
Enzo : Alors, je vais dire consommer, pas gérer, dans le sens où, encore une fois, par exemple, on utilise beaucoup des données de prod. Mais ça, c'est l'équipe Data Engineering. Si j'explique un peu ça, on a de la donnée de prod qui est vraiment nécessaire pour faire fonctionner notre application. Nous, on va, par exemple, l'équipe Data Engineering va mettre en place un réplica de cette donnée-là, qui est plus pour des usages analytiques. Parfois, eux, ils vont faire des transformations de données déjà dessus pour les rendre plus facilement consommables. Parfois, nous, on va le faire. Parfois, on a aussi une équipe Analytics Engineering qui est là plus pour gérer le self-service pour que les gens dans l'entreprise soient... On utilise Looker en interne qui est un outil de BI pour s'assurer que notre self-service est utilisable par le maximum de personnes. Donc eux vont aussi faire de la propre transformation. Mais nous on va arriver sur ce point là. Mais la donnée de prod par exemple, nous on va pas... On s'y connecte pas directement et on va plutôt la consommer. Donc on n'est pas responsable de ça. Par contre souvent on aura fait les specs de cette donnée de prod en fait d'un côté. Mais on n'est pas... Si demain la donnée arrive plus, c'est pas notre équipe qui va être responsable de réparer ça. c'est des équipes plus data engineering, operations, parfois DevOps.
Terry : Oui, tu as raison de préciser et d'utiliser les bonnes terminologies. Du coup, je rephrase en disant, si je dis que si demain j'ai une question qui a à faire avec la donnée sur le produit, vous êtes le point unique d'entrée ?
Enzo : Alors non on n'est pas le point d'entrée justement tout ce qui est sales service en général tout ce qui est donné on va dire très répandu dans l'entreprise c'est plutôt une équipe qui fait le premier niveau de le premier niveau de support et nous comme je disais au début on est plutôt chacun expert sur un produit et du coup sur la donnée d'un produit on va être plutôt le niveau d'escalation le niveau d'escalade pour pour ces personnes là Mais après chacun, enfin nous on consomme en tant que data scientist, on consomme toute la donnée qui existe dans l'entreprise et forcément quand t'es responsable du produit SDK, tu vas consommer beaucoup plus de données mobiles que quand t'es responsable du produit qui te sert à traper de la fraude sur les documents, où là tu vas peut-être moins t'intéresser aux données mobiles. Donc c'est deux personnes qui sont dans la même équipe, deux personnes par exemple c'est deux zones de l'entreprise qui sont couvertes par des product analytics. Mais finalement ils n'utilisent pas exactement le même set de données. Mais dès que, là où je parlais d'intégrité avant de donner de cohérence, c'est que dès qu'il y en a un qui doit utiliser la donnée de l'autre, si jamais il doit passer trois jours pour comprendre comment fonctionne la donnée de l'autre, là ça ne va pas. Et c'est là où on parle beaucoup et c'est pour ça qu'on est la même équipe finalement. C'est-à-dire que c'est super important d'avoir le même socle commun, par exemple les mêmes conventions, les mêmes façons de travailler, pour être agile pour tout ce qui est en dehors de notre scope très spécialisé.
Terry : Très clair sur votre rôle, le rôle de Product Analytics. Donc ce que je te propose de faire maintenant sur la deuxième partie de l'échange, c'est par rapport, avec cette explication et ce cadre bien posé de qu'est-ce que tu fais en fait et qu'est-ce que vous faites dans ton équipe de Product Analytics, c'est de prendre des exemples pour d'autres boîtes qui seraient en train d'essayer de monter des pôles qui ressemblent à ce type là, des pôles de product analytics, des apprentissages que tu aurais pu avoir sur des choses qui n'ont pas marché versus d'autres qui ont bien marché, en tout cas du retour d'expérience là-dessus. Moi, une question à laquelle je pense en échangeant, c'est sur est-ce que par exemple il y a eu des cas où vous avez travaillé de la donnée, ou en réalité le problème auquel vous pensiez avoir trouvé une solution grâce à cette donnée, ça n'en était pas une parce que la donnée de base était complètement pourrie ou complètement incohérente par rapport à ce sur quoi vous cherchiez une solution. Un sujet comme ça qui me vient en tête parce que je sais que quand on parle de données souvent c'est la qualité de la donnée qui fait quand même d'abord qui est le plus important mais je sais pas si toi tu as d'autres sujets en tout cas que tu souhaiterais partager là-dessus.
Enzo : C'est intéressant ce que tu dis sur la qualité de la donnée et ça souligne par exemple une différence entre une équipe Product Analytics et peut-être une équipe plutôt Research, c'est-à-dire que nous on est quand même proche du produit, on comprend le business, on n'est pas directement avec les clients mais on comprend bien le business, ce qui est en fait une part très importante et qui fait partie des compétences requises d'un product analytics. Là où par exemple on a des chercheurs qui sont vraiment experts de leur domaine et quand nous on consomme de la donnée on se rend assez vite compte, on a un peu cette notion de est-ce que la donnée est propre ou pas. Donc pour répondre à ta question, ça arrive assez rarement qu'on aille très loin dans un projet et qu'on se rende compte qu'on a un problème de données qui n'est pas propre. Parce qu'on a un peu ce recul-là, et là c'est là où on travaille avec l'équipe engineering ou l'équipe research. en fait, pour essayer de leur prémâcher ça, parce qu'eux n'ont pas forcément cette notion là, ils sont vraiment experts de certains algos de type de machine learning. Par exemple, on a des experts de machine learning autour des images. Pour eux, c'est pas forcément évident que, je sais pas, le champ gender sur les documents de tel type, c'est mal écrit ou il y a beaucoup d'erreurs, tout ça. Donc nous, Comme on est assez proche des équipes de product management, on arrive assez vite à dérisquer ce genre de projet. Les exemples où on a plus eu du mal à avancer, c'est quand la donnée n'existe pas. Parfois on se dit, ah mais cette donnée, c'est sûr qu'elle existe. Alors il y a plusieurs cas de figure, c'est soit elle existe en prod, mais par exemple elle n'est jamais répliquée, on n'arrive pas à avoir accès à cette donnée, et donc là, ça peut être un bloqueur, et donc on va essayer de travailler pour typiquement faire en sorte que cette donnée devienne accessible avant qu'on puisse faire quoi que ce soit. Soit cette donnée, elle a été transformée d'une certaine façon qui fait qu'elle n'est pas tout à fait correcte, même si la donnée de base est plutôt correcte. Et ça, ça nous arrive parfois aussi. Mais c'est le principal bloqueur, je veux dire, où... Enfin, de mon expérience, en tout cas une Fido, je pense que c'est vraiment le genre de projet où on est allé le plus loin possible, en se disant à un moment, ah ouais, en fait, on a un bloqueur qu'on n'avait pas vu venir, qui n'est pas exactement la qualité de la donnée d'entrée, mais qui peut arriver à un autre niveau.
Terry : Ok, assez clair là-dessus du coup sur le fait que la qualité de la donnée c'est pas spécialement le premier sujet puisque ça c'est traité en amont en fait. Mais du coup que par contre vous avez, enfin le point que tu viens de dire en fait c'est, pour être sûr de bien comprendre, c'est le fait que parfois vous vous rendez compte un peu plus tard qu'il manque certaines données et que là par contre pour l'ajouter en prod c'est beaucoup plus complexe quoi.
Enzo : Je te donne un exemple très concret. On a du coup un SDK, donc on a des versions de SDK. Notre SDK il est dans une appli de nos clients, donc on dépend à la fois de nous quand on sort un nouveau SDK, mais de quand est-ce que notre client pousse ce nouveau SDK dans leur propre application, et ensuite de quand est-ce que l'utilisateur final installe la nouvelle application de notre client. Donc il y a beaucoup d'étapes et parfois on enrichit notre SDK pour mieux apprendre où est-ce qu'il y a des frictions typiquement dans un parcours utilisateur. Et ça nous arrive parfois de se dire ok, je regarde et je me dis j'ai l'impression que le client il s'arrête souvent après la capture de documents parce qu'en fait on a des données et on voit après la capture de documents j'ai plus beaucoup d'événements de mon SDK. et en fait il s'avère que s'il n'y a que certaines versions, c'est à partir de x versions de notre propre SDK que l'on commence à déclencher des événements après la capture de documents et ça parfois on s'en rend pas compte et là tu te dis ok en fait mon analyse il faut que je la scope différemment parce que finalement la donnée est partiellement accessible avant cette version de SDK et ce sera impossible d'avoir ces données pour les autres versions parce que elles ont déjà été avancées, elles existent déjà, elles sont sur le marché. Donc on a parfois des données qui manquent et c'est effectivement le piège étant quand elle est partiellement là, ça c'est la pire des situations parce qu'on en voit donc on ne s'en rend pas forcément compte qu'elle manque et c'est pour ça qu'on a besoin d'une certaine expertise pour être capable au maximum de faire attention à ces cas-là et de scoper les choses proprement Et ce qui arrive très fréquemment, c'est un vrai exemple ce dont je te parle là, c'est que des gens qui sont, bah typiquement je parlais des analystes qui sont plutôt business, eux ils ont pas cette connaissance là parce qu'ils sont pas profondément dans les données du SDK. Donc ça arrive très souvent qu'ils viennent nous voir en nous posant des questions, en disant bah je comprends pas c'est un peu bizarre pour ce client parce que j'ai un taux de conversion de 10%. ce qui est super faible mais le client se plaint jamais et puis j'ai l'impression que d'un autre côté à la fin du funnel je vois quand même des choses alors j'ai du mal à comprendre ce qui se passe et c'est là où nous on a été confronté à ce problème là plein de fois et on lui dit ah oui mais en fait regarde quelle est la version de ton client et sur cette version en fait il te manque telle data donc ce que tu es en train de regarder tu peux pas le regarder vraiment comme ça il faut que tu sois filtre soit que tu ignores ça enfin Bref, on est là pour les aider un peu et c'est là où on fait le lien, comme je parlais, on est expert là-dessus, on fait le lien avec les gens qui sont plutôt business et qui, eux, ratissent plus large mais ont une connaissance moins profonde de chaque partie du produit.
Terry : Hyper intéressant et je vois bien, enfin j'imagine bien là aussi parfois la frustration que tu peux avoir de te dire bah zut là j'ai vraiment cette donnée qui va me permettre de faire tel type de statistique ou autre mais attention à l'extrapolation parce qu'en fait on n'a que 20% de nos utilisateurs complets qui en fait ont cette capacité à remonter cette donnée parce que les autres sont sur des versions antérieures.
Enzo : Et le pire étant quand tu ne sais même pas que c'est partiel en fait. Et c'est là où il y a beaucoup d'erreurs. C'est quand tu es conscient qu'il y a des versions, même si tu ne connais pas exactement, si tu es conscient qu'il y a des versions de SDK qui ne vont pas être compatibles avec telle métrique, tu fais un peu attention et puis, premier réflexe, tu vas essayer d'aller voir les gens pour savoir lequel c'est. Quand tu ne sais pas, là ça devient compliqué parce que tu t'arraches les cheveux avant que tu poses la question, que par hasard tu trouves peut-être la bonne personne qui est capable de te donner la réponse.
Terry : Hyper clair. Et donc tu as beaucoup parlé de vos interactions avec le business et avec les product managers, donc je suis un peu curieux de savoir d'un point de vue organisationnel aussi tes retours d'expérience, que ce soit des méthodes particulières que vous mettez en place ou votre méthode maison, souvent c'est un mix entre les deux, pour interagir du coup avec le business et rester à jour à ce niveau-là.
Enzo : Alors nous, notre point d'entrée, c'est le Product Manager pour justement tout ce qui est business. C'est vraiment, on a des, chaque membre de l'équipe, c'est un peu une idée de squad finalement. On a un Data Scientist de l'équipe Product Analytics qui est dans la squad avec le Product Manager SDK par exemple, avec les Dev Lead SDK, enfin même avec les Dev SDK, ça fait vraiment une sorte de squad, on essaye de travailler de cette façon là, ce qui permet d'avoir ce contact privilégié avec le Product Manager qui va vraiment se faire l'écho du business. Et c'est comme ça qu'on a le maximum de retour de notre business, enfin du business, nous en tant que Product Analytics. D'un autre côté, on a le côté engineering avec lesquels on va expliquer, leur dire, on veut mesurer ça, cette donnée importante, il faudrait que vous arriviez à nous la créer. Ok, est-ce qu'on peut le faire ou pas ? Est-ce que c'est compliqué pour nous de le faire ou pas ? Et donc, on a ces discussions aussi avec l'équipe engineering. Mais le business, c'est vraiment le product manager qui va être notre point d'entrée.
Terry : D'accord, et côté, donc vous êtes bien évidemment, comme on le dit depuis le début, à cheval entre la partie PM, Product Manager, côté business, et équipe purement tech, Data Scientist, Data Engineer, côté tech. Est-ce que vous avez des rituels particuliers pour justement avoir ces rendez-vous, autant d'un point de vue tech que d'un point.
Enzo : De vue produit ? Souvent il y a les stand-up, il y a des stand-up tous les jours, nous on va une fois sur deux à peu près aux stand-up avec les équipes dev, souvent il y a le product manager qui est là. Il y a souvent aussi des one-one avec le pack sur le sujet et le product manager, un weekly. Pareil entre le Pax et le Dev Lead.
Terry : Le Pax, pardon.
Enzo : Le Product Analytics, pardon.
Terry : Merci.
Enzo : C'est Product Analytics. Donc il y a ces one-one réguliers, donc vraiment weekly, on essaye de rester au contact avec nos deux stakeholders les plus importants qui vont être le Dev Lead d'un côté, parce que c'est lui qui va pousser les sujets d'attaque, Nous on n'a pas de product owner, donc c'est en général le dev lead qui va gérer son propre backlog, donc c'est un peu par lui qu'on doit faire pousser nos sujets, les sujets très concrets, et le product manager pour comprendre quelle est sa roadmap, quels sont ses enjeux, ce dont il a besoin, et c'est vraiment comprendre sa stratégie là-dessus. Donc ça c'est les rituels de chaque membre de l'équipe, et ensuite un des challenges quand on est une équipe décentralisée, c'est de réussir à garder une cohésion d'équipe. Et là-dessus, en plus, on a, nous, en tant que Product Analytics, des démos, ce qu'on appelle des sharing sessions. On a des stand-up Product Analytics aussi. C'est super important de partager l'information puisque on est une équipe décentralisée. Enfin, décentralisée, ouais. On est assez décentralisé comme organisation. Et donc, c'est super important aussi de partager l'information. Donc, on a aussi nos rituels à nous d'équipe. Et tout ça en essayant de faire en sorte que ça ne te prenne pas la moitié de la semaine à faire juste des rituels et des meetings et que tu puisses un peu travailler aussi.
Terry : Yes, ça c'est le challenge toujours quand tu commences à grossir. Donc hyper, je pense que ça donne pas mal d'éléments concrets sur vous, comment vous le faites et ça peut inspirer je pense d'autres du coup qui seraient dans des situations où ils vont commencer à créer des pôles Product Analytics, là je vais volontairement me faire un peu provoquant. Je vais te dire, moi j'ai un PM qui est vachement, moi j'ai un background tech, je suis vachement end zone. Si tu as un PM en face de toi qui te dit en fait, nous nos PM ils sont assez tech, ils sont capables de mettre les mains dans de la requête SQL, d'aller comprendre la donnée, de construire quelques dashboards Power BI, Et donc on ne voit pas vraiment l'intérêt d'avoir un pôle dédié Product Analytics. Alors toi qu'est-ce que tu répondrais à ça et peut-être aussi à quel moment c'est pertinent de commencer à se dire on va mettre une équipe purement dédiée pour le Product Analytics ou peut-être des typologies de métiers ?
Enzo : Alors non, c'est une bonne question. Ça arrive souvent et ça arrive souvent quand on crée une équipe Product Analytics, comme quand tu es arrivé à Infinity. Ce n'est pas toujours facile. Souvent, c'est un peu le paradoxe de quand on a travaillé avec une équipe comme ça, tu vois très bien la valeur, mais quand tu n'as jamais travaillé avec ça, tu te dis, quelle est la valeur ? Et c'est comme les A.B. tests. Quand tu n'as jamais fait d'A.B. test, tu te dis, ah ben, il suffit que je regarde, je fais mon rollout de futures, je regarde si ça marche ou pas. Et après, quand tu t'es planté trois fois, tu te dis, OK, en fait, j'ai peut-être, il y a peut-être un truc, ça me prend beaucoup de temps à faire. Je prends parfois des mauvaises décisions. Et c'est là où, à partir du... En fait, ça dépend du niveau de maturité. Et une équipe Product Analytics ne va jamais arriver dans une startup directement. C'est un rôle assez spécialisé. Et comme une startup, en général, on veut être généraliste. Un product manager qui est très bon en Power BI et qui est très bon en SQL, c'est super pour démarrer une startup. Maintenant, quand la boîte grossit, un product manager qui ne fait que du SQL et du Power BI, ce n'est plus un product manager en fait. Il y a une histoire de scale beaucoup dans la création de l'équipe Analytics. Il y a une histoire de maturité data, c'est-à-dire qu'un product Analytics sans data, il ne fait rien. Donc si tu es une entreprise qui n'a vraiment pas de data, Souvent, il faut être vraiment gros ou alors que la data soit au cœur de ton business pour commencer à réfléchir à une équipe Product Analytics. Mais c'est comme un data scientist en général en fait. Si tu n'as pas de data, ça ne va pas te servir à grand chose. Si on se met dans une situation où pour moi on a besoin d'un product analytics, donc une boîte qui commence à avoir quelques centaines de personnes, peut-être plus petites ça dépend, mais grosso modo l'ordre de grandeur c'est ça, soit ça te fait gagner du temps pour tes product managers qui peuvent faire mieux leur travail, ça t'aide à structurer aussi la data, les data engineering vont être plus ops en fait quelque part, là où nous on va être justement un peu plus business, on va essayer de faire plus parler la data et c'est à ce moment là où on a vraiment le plus de valeur. Je sais pas si ça répond à ta question.
Terry : Ça répond si si très bien. Très bien, en tout cas pour moi ça me répond très bien à ma question donc merci. Par rapport toujours un peu dans cette logique d'équipe Product Analytics, quels sont un peu les profils toi que tu considères comme étant pertinents pour en tout cas des compétences clés que tu recherches dans.
Enzo : Des Product Analytics ? Alors c'est assez marrant parce que nous donc on est tous en fait Un Product Analytics, c'est un Data Scientist qui a un bon sens business. Du coup, on est tous Data Scientist. La base de la base, c'est de connaître les stats et d'avoir une certaine formation là-dedans. Ce qui surprend assez les gens en général, c'est que par exemple, moi, quand je crée mes interviews, mon process pour recruter des gens, je demande pas de SQL. Le SQL, c'est super important, on en fait tous les jours. Mais pour moi c'est pas un requirement parce que si on a la tête bien faite en fait c'est juste un autre langage de programmation si on a déjà fait un peu de Python, si on a déjà fait des choses comme ça. En fait le SQL c'est pas si compliqué et même si on utilise ça tous les jours c'est pas si compliqué à apprendre alors que des stats c'est beaucoup plus dur à apprendre. Et un autre truc qu'on teste et qui est vachement important c'est ce qu'on appelle le business acumen c'est en fait Est-ce que tu es un data scientist plutôt profil on va dire recherche mais peut-être le nez dans tes bouquins et finalement ce que fait l'entreprise ça t'intéresse pas trop ? Ou est-ce que tu as vraiment envie de comprendre en fait l'écosystème ? Est-ce que tu as un peu de sens business ? Est-ce que tu es capable de te mettre en fait dans les chaussures de ton client ? Et ça c'est super important comme compétence aussi de Product Analytics. J'ai envie de dire, il y a le côté stats qui est en fait difficilement... C'est plus compliqué à apprendre que le SQL, donc je le mets comme vraiment un... Ben, obligatoire. Enfin, un requirement.
Terry : Oui, c'est nécessaire, quoi.
Enzo : C'est obligatoire pour moi. Et le côté business acumen qui est quelque chose qui, en fait, ça prend pas forcément l'école, mais qui est plus une histoire de caractère et est-ce que ça va fitter avec le rôle ou pas ? Et ça, c'est deux parties qu'on teste vraiment beaucoup dans les interviews. Par exemple, on essaie de faire une rencontre avec un product manager quand on fait nos interviews pour que le product manager, qui va être le stakeholder, sache s'il y a un fit ou pas, s'il sent qu'il arrive à comprendre le client.
Terry : Et oui, parce qu'en fait il va interagir son binôme côté client, c'est le product manager. Et côté tech, par contre, est-ce que vous faites aussi des fois des interviews avec une responsable tech ou ça c'est plutôt toi qui vas t'en charger ? Qu'est-ce que tu veux dire ? Dans le fait de, comme tu l'expliquais un petit peu avant, c'est que le Product Analytics, il va faire le lien entre le product manager et un responsable purement tech, que ce soit un data engineer, un data scientist qui a les mains dans les modèles. Et donc, quand tu vas recruter un nouveau product analyst, tu vas vouloir voir comment il se comporte avec son potentiel futur partenaire côté product manager, mais est-ce que tu fais la même chose côté tech ?
Enzo : Non, côté tech, c'est plutôt nous qui allons juger à travers les exercices. On ne fait pas de coding exercise, mais si on le faisait, ce serait plus pour l'équipe. la relation est peut-être un peu moins forte. Le product manager c'est quand même un rôle très isolé souvent et très particulier donc c'est important pour nous qu'ils rencontrent le product manager. Le dev lead on a un peu moins d'interaction malgré tout et ça fait partie d'une équipe donc après on s'intègre dans l'équipe mais non on ne teste pas, on ne fait pas venir des personnes tech, enfin des développeurs pour pour.
Terry : Les interviews chez nous. Très clair et ça fait sens par rapport à ce que tu viens d'expliquer. Est-ce que, toi tu le vois évoluer comment le métier de Product Analyst ?
Enzo : C'est intéressant, il y a plusieurs... Le métier de Product Analyst ou un Product Analyst, quelle serait sa carrière ?
Terry : Ma question était d'abord sur comment tu vois évoluer le métier mais tu peux aussi commencer par comment tu vois l'évolution effectivement de la carrière d'un product analyst.
Enzo : Alors en fait c'est assez entrecroisé. Product analytics, moi j'ai vu beaucoup de personnes Product Analytics qui sont partis soit d'un point de vue plus tech, donc à un moment ils veulent rentrer plus dans la tech, devenir plus Data Engine, gérer des plateformes, se concentrer vraiment plus sur le pipeline de données ou la création d'une plateforme, d'un outil, et beaucoup de profils qui partent plutôt justement vers le produit après. On a des très bons retours, en fait les gens qui sont Product Analytics c'est un peu un mélange des deux et comme dans beaucoup de métiers à un moment il faut quand même se spécialiser c'est pas c'est bon ça arrive dans beaucoup d'endroits on développe avec nos appétences en fait on développe une certaine expertise et il ya des gens qui se tournent plus vers le product management et moi je pense que le product analytics et le product management se rapprochent de plus en plus en fait à la base c'est assez marrant parce que c'était un blog post de Airbnb je crois à l'époque qui décrivait en fait ce que c'était un data scientist chez eux et ils expliquaient en fait il y a plusieurs types de data scientist et là dedans il y a typiquement ils décrivaient peut-être pas avec ce mot exactement mais ma vision du product analytics aujourd'hui qui est un data scientist donc qui a des compétences techniques assez fortes et mathématiques assez fortes mais qui comprend le business et je pense que on va de plus en plus vers un rapprochement de ces deux métiers Et pour moi, ça ne m'étonnerait pas que l'avenir, en fait, ce soit des product managers qui sont peut-être encore plus analystes ou disons deux profils de product managers qui apporteraient des choses différentes, mais dont un qui serait en fait une évolution normale du product analytics.
Terry : Très clair, très clair. Et du coup, effectivement, tu as répondu aux deux questions en une, donc c'est parfait. Avant d'aller vers mes deux questions rituelles, on va dire, de chaque épisode, est-ce qu'il y a un sujet en particulier qu'on n'a pas abordé ou un point que tu voudrais accentuer par rapport à...
Enzo : Je pense que, on en a parlé mais je vais l'accentuer un peu plus, avoir une collaboration, on voit tout de suite, on voit la puissance que ça a en fait d'avoir des profils complémentaires aujourd'hui comme le Product Manager, le Product Analytics. Moi je le vois sur, malheureusement on ne peut pas couvrir tous les aspects de l'entreprise, mais du coup je vois, parce qu'on est une équipe trop petite aujourd'hui chez Enfido, Mais du coup, sous mon scope où je vois les gens dans mon équipe, je vois des dynamiques qui se créent avec le Product Manager. Et cette collaboration, quand elle fonctionne, elle est vraiment très puissante. C'est plus un multiplicateur qu'une addition là-dessus. Et c'est quelque chose que moi je trouve assez fantastique de voir. Aujourd'hui, on va peut-être regarder la donnée, on va avoir cette idée, et boum, dans six mois, en fait, on est en train de sortir une feature, il y a le product manager qui fait une comm là-dessus, t'as l'entreprise qui le présente, tout ça parce qu'on a eu l'idée, on a pu discuter avec le product manager, affiner cette idée, construire un premier modèle, le sortir en prod, c'est super gratifiant, ce truc-là. Du coup, j'insiste encore, mais cette relation product analytics, product manager est vraiment forte et vraiment très puissante.
Terry : Ça me plaît vachement ce que tu dis parce que ça fait toujours écho au fait qu'ensemble on est toujours plus fort et qu'effectivement 1 plus 1 ça fait 3, ça fait pas 2, voire plus. Je plus sois totalement, donc tu fais bien d'accentuer ce point. Maintenant pour aller vers les deux questions phares, la première c'est est-ce que tu as une conviction forte sur laquelle en général quand tu la partages avec tes pairs tu es en désaccord ?
Enzo : Alors, j'ai une conviction forte et parfois ça peut créer des désaccords. Il y a quelque chose que j'essaye de promouvoir beaucoup qui est la culture de l'explicite. Dans la data, parfois tu produis de la data et en faisant trois règles, tu peux réussir à deviner en fait autre chose avec ça. Quand je dis autre chose, c'est par exemple, je ne sais pas si je prends les numéros de documents français. En fait, tous les numéros de documents français, je n'en sais rien, commencent par 90. Donc, si tu regardes le numéro de document, tu peux deviner que c'est un document français. Bah ça c'est pas bien du tout en fait. Et pourquoi est-ce que... Donc moi je suis beaucoup sur la culture de l'explicite parce que derrière ça va permettre d'aller beaucoup beaucoup plus vite et de se poser beaucoup de moins de questions et de créer... de faire beaucoup moins d'erreurs. Pourquoi est-ce que ça peut créer des désaccords en fait ça ? C'est que il y a d'autres personnes, d'autres... enfin d'autres façons d'imaginer les choses qui essayent de travailler avec le, on va dire, l'ensemble minimum des informations dont tu as besoin pour faire fonctionner ton produit. Donc créer ce champ en plus qui dit c'est documents français alors que tu as le numéro de document, il y a des gens qui ne vont pas vouloir le faire parce que tu peux le deviner. Pour eux, il faut essayer d'avoir le minimum possible de data, notamment quand tu veux faire un outil de prod, moins tu pousses de data, plus ça va être rapide par exemple. il y a deux visions qui s'affrontent là-dessus et parfois ça peut créer des bloqueurs parce qu'une équipe peut te dire ben non je veux pas produire cette data parce que en fait si tu regardes si tu fais ça ça et ça et que tu croises avec cette sorte de données ben en fait t'es capable de le deviner et je fais ok mais en fait qui est capable de connaître cette règle ça va se perdre les gens font faire des erreurs tout ça et donc cette culture d'explicit c'est super important pour moi dans la data et c'est pas toujours la vision la vision commune.
Terry : Très intéressant, j'étais en train de chercher du coup où tu allais aller avec le numéro 90, maintenant je vois et pour les plus tech qui nous écoutent c'est quand notamment tu as on va dire une base de données relationnelle, tu vas avoir des champs nécessaires et certains que tu vas qualifier, je sais pas si tu fais, enfin peu importe le langage en fait, mais computed, que tu vas pouvoir calculer à la volée en fait en faisant des règles, mais autant une moyenne, bah oui tu vas pas l'écrire puisque ça se calcule à la volée et c'est évident, autant ce que tu viens de dire ton document parce que ça se finit par 90 tu infères que c'est un document français là c'est plus tricky donc je pense que je partage ton point de vue sur l'explicite même quand tu codes en fait c'est beaucoup mieux des fois d'écrire des choses peut-être basiques et pas faire des raccourcis hyper chiadés sur ton code, mais au moins t'es sûr que quand tu le relis dans deux ans ou si quelqu'un d'autre le récupère, il va comprendre tout de suite ce que t'as fait, et même si t'as pas gagné la nanoseconde, il va gagner des heures derrière. Donc c'est un peu la même approche.
Enzo : C'est exactement le même, c'est un très très bon parallèle, enfin c'est exactement la même chose pour les développeurs, entre être un peu plus verbeux mais plus explicite quand tu vas relire, ou être un peu plus rapide mais du coup beaucoup plus compliqué à maintenir et à revenir dessus.
Terry : Yes, très clair. Et du coup la dernière question c'est les ressources, les rocos, alors que ce soit lecture, podcast, enfin les choses qui t'inspirent et qui te nourrissent toi intellectuellement pour ton boulot.
Enzo : Alors, point de vue data, il y a une newsletter de Christophe Blefari qui est assez sympa. J'ai découvert ça à travers le Modern Data Network, qui est un network, un Slack à la base, qui essaye de créer des events, de s'associer à certains meetups, qui est vraiment pour les spécialistes de la data, donc ça regroupe des data analyst, des data eng, des data scientist. C'est un super réseau et là-dessus c'est assez cool parce qu'il y a des ressources très très pertinentes, ils partagent des choses très pertinentes, il y a des profils incroyables sur ce réseau. Donc ça c'est plutôt d'un point de vue professionnel. Après moi je suis un gros consommateur de petites vidéos YouTube, de chaînes type Syllabus ou des choses un peu scientifiques, de vulgarisation scientifique. Ouais, il y a pas mal de vidéos, ça me fait mes pause-déje parfois où je peux passer, je les enchaîne, c'est super sympa. Mais c'est peut-être les deux ressources où je passe pas mal de temps là-dessus aujourd'hui.
Terry : Ok, super. Et si on veut te contacter, du coup, est-ce qu'on peut te faire signe sur LinkedIn ?
Enzo : Oui, bien sûr, bien sûr. Ravi de répondre à des questions, si cette discussion a créé des questions, de prendre un café suite à ce podcast, avec plaisir.
Terry : Super. Eh bien, merci Enzo.
Enzo : Merci à toi.
