L'approche produit au service de l’IA

A quoi ressemble le cycle de vie des produits IA ? Les problématiques des Product Managers (PM) qui le pilotent ? Voilà ce que j’ai découvert en interrogeant des PM data et IA.

Démarche : je suis Product Manager, dois-je me spécialiser en IA ?

Depuis quelques mois, ChatGPT est sur toutes les lèvres et sur tous les écrans. Les intelligences artificielles génératives ou genAI (comme chatGPT) sont des outils générant automatiquement des contenus (code, texte, images…). Je trouve leurs applications très concrètes et faciles à comprendre. Par exemple, je peux demander à chatGPT de me générer un résumé en 2000 mots d‘un roman. En revanche, le jargon technique (LLM, RAG, MLops…) m’a d’abord empêchée de me sentir concernée en tant que Product Manager. Le sujet semblait réservé aux initiés (data engineers, data scientists…) qui en maîtrisaient le jargon et les rouages techniques.

Face à la vague IA, je me suis vite rendue à l’évidence : l’IA impacte et va transformer nos métiers puisqu’elle est source d’innovation et de valeur pour les utilisateurs et les entreprises, avec d’innombrables applications potentielles. J’ai décidé d’embrasser le changement, et d’envisager comment le développement de l’IA allait impacter mon métier de Product Manager !

Je distingue deux façons dont l’IA impacte le Product Management :

• L’IA au service du Produit : L’IA peut impacter mes gestes métiers de Product Manager. En tant que PM je peux utiliser l’IA pour plus de productivité ou d’efficacité dans mes tâches quotidiennes (par exemple : utiliser chatGPT pour écrire une User Story ou faire la synthèse d’entretiens utilisateurs)
• Le Produit appliqué à l’IA : En tant que PM je peux être amenée à travailler sur des produits dont la solution technique s’articule autour de l’IA (par exemple un produit de détection de fraude bancaire).

C’est sur ce deuxième impact que j’ai voulu aller plus loin : Quelles sont les spécificités du Product Management des produits IA ? Cela me plairait-il de développer cette spécialité ? Quel serait son intérêt ?

Pour y répondre j’ai interrogé des Product People travaillant sur de la data et de l’IA, dans le cabinet où je suis consultante, OCTO Technology, et dans d’autres organisations :

• Yoan Eynaud, Product and User-Focused Data Science Manager chez OCTO Technology
• Marine Dussaussois, Product Owner data chez OCTO Technology
• Emmeline Ciuti, Product Manager IA chez France Travail,
• Charlotte Bouakline-Le Naour, lead Data Product Manager chez Invivo
• Yoann Benoît, co-founder et Head of Data&Product chez Hymaïa

Un grand merci à vous pour vos retours d’expérience ! Cet article est le fruit de nos discussions.

Quelques exemples de questions qui ont guidé nos entretiens :

• De qui est composée ton équipe ?
• Parle-moi de ton produit
• Qu’est-ce qui est différent quand on travaille sur de la data / IA ?
• Quelles sont les compétences nécessaires pour travailler sur ce type de produit ?
• Qu’est-ce que tu aimes dans les produits data/IA ?

Définitions

Quand je parle de produit data, je veux évoquer les produits dont la proposition de valeur est basée sur de la donnée analytique, c'est-à-dire traitée et avec une dimension temporelle. Par exemple des produits qui apportent de la valeur car s’appuient sur des données de stocks (nombre de stocks restants à un instant t) : un dashboard de visualisation des stocks ou un algorithme de recommandation de commande basé sur le niveau de stock.

De tels produits data sont à distinguer d’une démarche data-driven (Utiliser la data — taux de clic, taux de mise en panier — pour améliorer le produit) qui peut s’appliquer quel que soit le type de produit, ou d’un produit “data-as-a-product” (Traiter la donnée comme un produit et ses consommateurs comme des utilisateurs).

J’élargis ici le sujet aux produits data car les produits IA sont un type particulier de produit data et partagent donc avec les produits data quelques spécificités.

Dans la suite de l’article, je vous partage ce que j’ai appris sur le cycle de vie d’un produit IA et les spécificités du product management sur de l’IA.

Le cycle de vie d’un produit IA : qu’est ce qui change ?

1. Le discovery : comment la data ou l’IA pourrait apporter de la valeur ?

Pour commencer, la définition d’un cas d’usage permet de définir un problème utilisateur que l’IA pourrait résoudre et qui apporterait de la valeur à l’utilisateur et à l’organisation.

Chaque cas d’usage peut être pensé comme un produit avec son persona, son customer journey.

Par exemple, l’une des personnes interrogées m’a raconté qu’une problématique dans son contexte était de mieux mesurer la satisfaction des utilisateurs. Une solution envisagée a été de détecter le niveau de satisfaction client grâce à une IA qui analyse les verbatims usagers captés lors d’appels téléphoniques.

La donnée brute (non exposée à l’utilisateur dans un dashboard) peut elle aussi être considérée comme un produit en soi (la data-as-a-product) qui nécessite donc de passer par l’étape de Discovery. C’est la conviction de Marine Dussaussois, Product Owner data chez OCTO. Dans ce cas, les utilisateurs sont les équipes tech ou métier qui utilisent la donnée. Co-construire le parcours utilisateur avec ces équipes permet d’appliquer les règles métiers pertinentes lorsqu’on transforme la donnée et donc de répondre au mieux au besoin des équipes utilisatrices.

Célia Fischbach, Data Manager chez Blablacar, raconte (dans le podcast Datagen) que sur un produit data qui optimise les réseaux de bus et dont les utilisateurs sont des équipes internes, la phase de Discovery initiale a pris trois mois pour comprendre le besoin utilisateur et cadrer un premier cas d’usage. Une fois les équipes Produit plus familières des utilisateurs et de leurs problèmes, cette phase prend plutôt un mois pour les nouveaux cas d’usage.

Quelle différence avec un cadrage sur un produit classique ?

Pas beaucoup de différences ! Comme souvent les stakeholders peuvent arriver avec une solution (l’IA) et il faut repartir du problème et de l’utilisateur.

2. Le cadrage : a-t-on vraiment besoin d’IA ?

Une fois le cas d’usage défini, on cadre la solution. Les produits basés sur l’IA sont soumis à une forte incertitude : les données sont-elles disponibles ? fiables ? exploitables ? L’approche produit permet de réduire cette incertitude en validant rapidement des hypothèses. Une des premières hypothèses à valider est de savoir si l’IA est la solution au problème défini.

Dans le cas de la mesure de satisfaction cité plus haut, l’équipe produit IA lance une étude de faisabilité sur un sprint. Elle valide que les données (verbatims usagers) sont bien disponibles… mais pas exploitables ! Les data scientists découvrent en un sprint que les verbatims sont trop courts pour être analysés (seulement deux ou trois mots) ne donnant pas assez d’informations contextuelles à l’IA pour déterminer la satisfaction client.

Quelle différence avec un cadrage sur un produit classique ?

Sur tout produit, on étudie la faisabilité. Le temps consacré à ces études est plus important sur de l’IA en raison de l’incertitude inhérente à la technologie. Les Product Managers doivent veiller à prioriser ces études dans les roadmaps et les sprints, aux côtés de User Stories classiques. Pas forcément beaucoup de temps pour chaque étude (un sprint par exemple) mais de façon régulière (à chaque sprint) ! Une Product Manager m’a raconté que cela représentait l’équivalent du travail d’un 1 data scientist sur 5 à chaque sprint.

3. L’exploration : l’IA apporte-t-elle de la valeur ?

Si le produit nécessite de l’IA, il arrive en phase d’exploration (ou POC pour Proof of Concept), pour vérifier rapidement que le produit développé répond efficacement au besoin utilisateur, autrement dit qu’il lui apporte de la valeur, monétisable pour l’entreprise.

Le Product Manager, par sa connaissance de l’utilisateur et des enjeux business, délimite un premier périmètre prioritaire. En effet, afin d’obtenir rapidement des enseignements, il est nécessaire de réduire la complexité, notamment en limitant le nombre de données à traiter, et donc le périmètre fonctionnel. Ainsi, chez Blablacar, sur un produit data qui optimise les réseaux de bus, Célia Fischbach, Data Manager, explique qu’un produit pilote a été validé sur le réseau Normandie avant d’élargir au reste de la France.

Dans cette phase exploratoire, la mesure de l’impact est clé !

Prenons l’exemple d’un produit qui détecte les fraudes bancaires. Il est important de mesurer :

• le taux de rappel : l’IA se déclenche-t-elle bien quand on a besoin d’elle ? sur des détections de fraude, quand il y a fraude, le produit l’identifie-t-il ?
• le taux de précision : Apporte-t-elle des résultats fiables ? Les fraudes détectées sont-elles vraiment des fraudes ?
• le ROI (retour sur investissement) : Le produit est-il rentable ? Les économies liées aux fraudes détectées valent-elles l’investissement dans l’IA ?

Le Product Manager doit s’appuyer sur les bons KPI pour mesurer l’apport de l’IA. Un produit efficace et fiable pour détecter les fraudes peut ne pas être rentable ! Au contraire, une IA moins performante peut néanmoins avoir de l’impact. Le Product Manager définit les indicateurs mesurant la valeur utilisateur et business, au-delà des indicateurs de performance.

Selon cette mesure, à la fin de l’exploration, le Product Manager décide s’il faut aller plus loin ou s’arrêter. Limiter temporellement cette phase permet d’aller en production ou d’arrêter les frais si l’exploration n’est pas concluante. Dans mes entretiens, une PM évoquait une durée maximale de 3–4 sprints.

Quelle différence avec un MVP ?

Un MVP comme un POC permettent de valider un produit sur un périmètre réduit censé apporter de la valeur à l’utilisateur.

Un MVP est pensé comme une première itération d’un produit que l’on va continuer à construire alors que le POC est pensé comme un test où la possibilité de s’arrêter est davantage envisagée dès le début. En effet, les gains des produits IA sont plus incertains et la démarche plus exploratoire.

4. L’industrialisation : diffuser et itérer

Si le POC prouve la valeur du produit, on passe à la phase d’industrialisation plus sereinement. Le périmètre est élargi progressivement, par itérations, et le produit IA durablement intégré au reste du produit.

Quelle différence avec une phase de Growth sur un produit classique ?

Dans les organisations où les fonctionnalités data et IA sont centralisées au sein d’une ou plusieurs équipes, ces dernières rencontrent les défis propres aux équipes transverses.

Industrialiser le produit nécessite de s’interfacer avec les autres équipes produit via des contrats d’interface ou data contracts, de gérer les dépendances et/ou d’acculturer les autres équipes au fonctionnement de ces produits. Ainsi, dans un exemple découvert lors de mes entretiens, quand un produit IA est en “run” depuis 1 ou 2 ans par l’équipe IA, il passe dans le périmètre des équipes produit qui l’utilisent. Les Product Managers data/IA ont un rôle clé de pédagogie pour démystifier la data et l’IA auprès des autres équipes et de communication pour s’aligner autour d’une roadmap commune.

Takeaways

1. A quoi sert l’approche produit sur un produit data/IA ?

Les produits IA sont de nature “exploratoire” avec des usages émergents. L’approche Produit, par son obsession de boucle de feedbacks en vue d’analyser les résultats (plutôt que les moyens), est donc appropriée. Le Product Manager pilote son produit par la valeur et l’impact, que ce soit en étudiant le problème en phase de Discovery, en pensant “MVP” en phase d’exploration et en mesurant l’impact des expérimentations.

2. Les spécificités du Product Management de l’IA

Au long de son cycle de vie, le produit IA soulève des défis spécifiques pour le Product Manager. Certes, on retrouve parfois un de ces défis sur d’autres types de produits. Je fais l’hypothèse que la spécificité du produit data/IA serait peut être la combinaison de ces défis et leur criticité (qu’en pensez-vous ?).

Optimiser le time-to-market

La culture de l’exploration fait que peu d’expérimentations partent en production, ou que cela peut être très long car soumis à une forte incertitude (est ce que ça va marcher techniquement ? comment tester ? quel impact pour l’utilisateur ?). Ces questions se posent quel que soit le produit mais sont encore plus importantes souvent qu’on travaille sur une nouvelle technologie, et l’incertitude est inhérente aux produits IA. La démarche agile de tester des hypothèses rapidement en prod permet d’optimiser le time-to-market.

Gérer les dépendances liées à une équipe transverse

Une organisation avec une équipe produit data/IA centralisée génère des dépendances avec d’autres équipes (qui portent par exemple la partie front des fonctionnalités basées sur la data ou l’IA).

Ces dépendances existent dès que le produit au sein d’une organisation est découpé par technologie et non par impact (par exemple une équipe mobile vs une équipe web qui travaillent sur un même produit). Aujourd’hui les organisations tentent de décentraliser cette organisation pour responsabiliser les équipes sur l’IA et les rendre plus autonomes.

Le défi de communication lié à la complexité technique

Comme sur d’autres produits techniques (API) qui nécessite un effort de compréhension et vulgarisation de la part des Product Managers.

3. Le métier de PO/PM data/IA, une spécialisation ?

Ce que les PM data/IA aiment dans leur métier ? Piloter des produits innovants, consacrer du temps au Discovery et travailler au sein d’équipes pluridisciplinaires (data engineers, data scientists, data analysts, développeurs, designers…), tout en collaborant avec des interlocuteurs variés (autres équipes produit, utilisateurs internes tech ou métier).

Les Product Managers travaillant sur de la data et IA sont curieux de comprendre le fonctionnement technique de leur produit. Pour cela, leur meilleure arme est de discuter avec leur équipe !

En effet, comme me l’a expliqué Yoann Benoît, head of Product & Data chez Hymaïa, la communication est clé : les PM doivent vulgariser leur produit auprès des parties prenantes et convaincre de l’approche produit auprès de personnes habituées à une démarche plus “Recherche et développement” qui arrive plus rarement jusqu’au pilotage d’un produit en prod. Plus que jamais, quand ils travaillent sur de la data et de l’IA, ils doivent penser impact plutôt que solution pour s’assurer que le produit soit “utile, utilisable et utilisé” (Yoan Eynaud, PM data chez OCTO).

Bref, des qualités que l’on retrouve chez les bons PM quel que soit le type de produit !

Aujourd’hui, dans le Produit, la data et a fortiori l’IA sont encore vues comme de simples spécialisations. Or développer des compétences data/IA, ce n’est pas s’enfermer mais s’ouvrir à des perspectives d’innovations, de nouveaux interlocuteurs, toujours dans une démarche produit. Et si on voyait plutôt la data et l’IA comme des dimensions supplémentaires à piloter quels que soient nos produits ?