Le Data Product Owner est le nouveau Product Owner

Les origines : émancipation de la data et Data Science sans sens

Les premiers rôles de Data Product Owner clairement identifiés apparaissent au tout début des années 2020 dans des entreprises avancées aussi bien sur l’agile que la Data (Booking.com, CarNext.com et Sony PlayStation par exemple). 

Ce phénomène est d’abord le résultat de la séparation progressive des équipes Data avec les équipes IT. En effet, depuis plusieurs années maintenant, nous assistons de plus en plus à la création d’équipes Data et Data Science dédiées et internalisées. Les possibilités offertes par la Data sont de plus en plus comprises par les entreprises. Celles-ci, de plus en plus autonomes, cherchent à exploiter au mieux leurs données pour construire une offre de valeur en interne en s’affranchissant de conseil externe ou d’une équipe interne non-spécialiste. 

L’agilité est rarement mise en œuvre lors de la construction de ces équipes dédiées à la Data. Ces équipes sont souvent davantage concentrées sur les phases de run plus que celle de build. Aussi, le manque de prévisibilité de leurs tâches empêche la construction d’une véritable vision produit adossée à une roadmap rassurante et partagée. Elles sont confrontées aux affres traditionnelles des projets d’IA : des explorations de données à l’infini sans réels objectifs ni besoins clairement exprimés. Beaucoup de temps perdu et des Proof of Concept qui font plouf sans passage à l’échelle (souvenez-vous, 85% des projets Data Sciences ne vont pas en production - Gartner 2018). Face à ce gâchis, la nécessité d’un cadrage avec une réflexion sur la valeur Produit s’impose comme une évidence. C’est donc dans ce contexte que naît le concept (salvateur) de Data Product Owner.

Une boussole dans la forêt de la Data

Les projets Data au sens large possèdent des spécificités critiques qui les distinguent des projets logiciels plus traditionnels. Le rôle de Product Owner doit lui aussi s’adapter en conséquence.

Si aujourd’hui la logique de produit software est plutôt bien comprise par les entreprises qui utilisent les méthodologies agiles, les projets Data restent souvent obscurs et c’est encore plus vrai des projets Datascience & IA. Avec didactisme, le Data Product Owner a la responsabilité de guider les parties prenantes à travers un écosystème complexe et foisonnant. Il s’agit de faire le tri entre le nouveau et le pertinent tout en évitant des explorations inutiles de solutions tendances. Mais il ne doit pas être pour autant un expert technique déconnecté de l’aspect fonctionnel de son produit.

“Les projets Data sont trop souvent abordés par l’aspect technique, il faut toujours voir le produit en priorité.”, Jérôme Le Louët - Data Product Owner à Direct Assurance

Profondément polyvalent, le Data Product Owner doit être vecteur de vulgarisation et capable de décrypter les différents insights produits par l’équipe, tout en étant capable de cadrer les demandes d’exploration des stakeholders.

Les mains dans la data et la tête dans le produit

A la différence du Product Owner, le Data Product Owner se doit ainsi de posséder un solide socle d’expertise technique pour comprendre et interpréter les résultats fournis par ses équipes. Autonome, il est capable aussi bien de réaliser ses propres analyses, écrire des requêtes SQL, monter ses propres dashboards que d’interpréter ses propres expériences. 

C’est le premier à remettre en cause ceux qui clament que “les données parlent d’elles même” puisqu’il sait que ce n’est jamais vrai. Les analystes sont toujours les porte-paroles des données. Connaître la méthode d’analyse est tout aussi important que de connaître les données elles-mêmes. Le Data Product Owner n’est pas aveuglément “Data Driven” à suivre inconditionnellement des nombres. C’est un sceptique raisonnable, à la fois producteur et consommateur de données. 

Quand je perds, je gagne

L’échec du déploiement d’une fonctionnalité pour des raisons techniques, le manque de compétences dans l’équipe ou même l’immaturité de l’écosystème technologique sont considérés comme des choses à éviter à tout prix lors de la conception agile d’un produit traditionnel …

C’est le contraire pour un produit avec une forte dose de datascience ou IA. L’échec documenté d’un modèle, ou d’une technologie est non seulement parfaitement naturel mais attendu. Cela représente même une avancée dans la précision des objectifs et le choix des éléments techniques conduisant à la réussite du projet. L'exploration des différents algorithmes et possibilités fait partie intégrante du processus de réalisation d’un projet DS / IA, alors que l’exploration aveugle et sans certitude de fin de tâche est une des choses les plus à éviter pour un Product Owner traditionnel...

Le Data Product Owner doit donc être capable d’évaluer la valeur de chaque tâche si elle est réalisée mais également si elle est abandonnée ou échouée et de prendre en compte cette valeur d’échec dans les priorisations.

Done, t’es sûr ?

La finalité d’une tâche, sa Definition Of Done, bien que complexe, comprend souvent la vérification que la fonctionnalité souhaitée est obtenue, testée et stable. Le problème est que l’obtention d’un algorithme fonctionnel, testé et stable mais avec une précision de 55% ne peut pas et ne doit pas être considéré comme Done, dans la plupart des cas. C’est encore plus compliqué dans le cas d’un modèle avec une précision de 90%, est-il considéré comme Done ? Doit-il être entraîné plus longtemps ? Les données d'entraînement doivent-elles être plus diversifiées ? Cela dépend de très nombreux critères aussi bien fonctionnels que techniques ou encore budgétaires.

Le Data Product Owner doit être capable de définir un objectif minimum de performance du modèle qui est adapté à l’utilisation de l’algorithme et doit avoir une connaissance plus précise de l’effort d'entraînement de modèle nécessaire pour atteindre cet objectif.

Un Product Owner augmenté

« Le Data Product Owner est avant tout un Product Owner » comme le précise Elie Zemmour, Data Product Owner à L'olivier Assurance.

Il conserve la totalité des responsabilités d’un Product Owner et doit avoir les mêmes connaissances et qualités qu’un Product Owner. Il est parfaitement compétent pour gérer un produit non-Data mais il doit également posséder toutes les compétences suivantes, évoquées plus haut :

1. Pouvoir vulgariser les concepts et les résultats obtenus

2. Savoir analyser les données et leur processus d’analyse

3. Savoir évaluer la valeur de l’apprentissage en cas d’échec d’une feature

4. Savoir évaluer le minimum de performance d’un modèle et d’une source de donnée acceptable

Ces 4 compétences clés sont très souvent des compétences partagées par les Data Scientists, ML engineers, AI Scientists et autres professionnels de la Data et de l’IA.

Pour ces raisons, il y a souvent deux profils type de Data Product Owner : les Data/AI Scientists devenus Product Owners et les Product Owners qui ont réalisé plusieurs projets Data Science / IA et acquis ces compétences au contact des projets et des équipes. 

Le Data Product Owner est un Product Owner qui se spécialise sur la gestion de produit DS / IA et Data, pour cela il a besoin de compétences supplémentaires ce qui complexifie sa recherche et son recrutement mais qui aident à garantir le succès de ses produits Data.

Vous avez un projet ?