Avec l'émergence des données dans la majorité des aspects de nos vies, de nombreux produits alimentés par de la data voient le jour : Produits d’intelligence Artificielle, Data Plateformes et Produits de Business Intelligence.
Après avoir fait quelques lancements de produit de Business Intelligence, je me suis rendu compte que l’importance de la data dans ces produits impactait fortement mon rôle de Product Manager (PM). Au point que j’en suis arrivé à la conclusion qu’être PM d’un Data Product, c’était surtout un métier d’équilibriste. Il fallait trouver l’équilibre aux 3 moments clés de conception Produit :
- En Problem Discovery, où l'identification précise des besoins des utilisateurs se confronte à la disponibilité des données.
- En Solution Discovery, où l'équilibre est recherché entre l'analyse détaillée et la facilité d'utilisation.
- En Delivery, qui nécessite une coordination soignée entre les Data Engineers et les Software Engineers.
Problem Discovery : L’équilibre entre le besoin utilisateur et la qualité des Données
Un produit de Business Intelligence permet à ses utilisateurs de prendre des décisions « data-driven ». Il accompagne l'utilisateur à prendre la bonne décision sur un sujet. Comme chaque décision requiert des données de qualité pour être prise, la facilité d'obtention de ces données de qualité doit être étudiée dès la phase de Problem Discovery. Pour illustrer, si je souhaite lancer un produit permettant aux utilisateurs de savoir s’ils doivent prendre un parapluie pour sortir, je dois vérifier que je peux exploiter des données météorologiques ou des proxies de celles-ci.
Le Product Manager doit identifier le besoin en trouvant le juste équilibre entre le niveau de besoin de l'utilisateur pour prendre une décision et la difficulté d'obtenir des données de qualité pour y répondre.
Dans notre exemple, il faut estimer à quel point les utilisateurs ont besoin de savoir s’ils doivent prendre un parapluie et l’opposer à la difficulté d’exploitation des données météorologiques. Si l’équilibre n’est pas pertinent, il faudra identifier un autre besoin sur lequel positionner son produit.
Lors de mes lancements produits, je n'avais que peu de certitudes sur les besoins des utilisateurs et la qualité des données disponibles. Pour remédier à cela, j'ai adopté des méthodes de référence du marché telles que celles partagées dans Continuous Discovery Habits et Discovery Discipline pour identifier les décisions que ma cible d'utilisateurs devait prendre, mesurer l'importance de chaque prise de décision, et estimer mon niveau de confiance dans ces mesures.
Une fois les besoins des utilisateurs identifiés, j'ai collaboré avec les Data Engineers de la squad pour enquêter sur la qualité et la disponibilité des données permettant d'y répondre. À l’aide de POC simples où nous réalisions manuellement ces transformations, nous avons pu déterminer si des données de qualité existaient et dans quelle mesure elles devraient être transformées pour être exploitées.
C'est finalement à ce moment que j'ai trouvé le bon équilibre du Problem Discovery, en maximisant le besoin utilisateur et la facilité d'accès aux données.
Solution Discovery : L’équilibre entre la complétude des analyses et la simplicité d'utilisation
Le deuxième équilibre se manifeste au moment de concevoir les fonctionnalités et d'identifier comment permettre aux utilisateurs de prendre des décisions. Plus je simplifie mon produit, moins il est complet, et inversement, plus mon produit est complet, moins il est simple à utiliser.
Lorsqu'on crée des produits d'aide à la décision et qu'on se contraint à livrer rapidement de la valeur, on est souvent tenté de donner accès à notre base de données via un grand tableau, en pensant que l'utilisateur pourra comprendre toutes les situations. Cependant, cela ne signifie pas nécessairement qu'il le fera. Et s'il le fait, ce sera souvent pour exporter vos données et effectuer ses analyses manuellement chez un concurrent redoutable : Excel. Vous obtenez alors un produit qui permet des analyses complètes mais qui est peu utilisable.
Inversement, l'émergence des plateformes BI et leur facilité à créer des Dashboards en No Code ont créé le problème opposé : pour chaque situation, un dashboard simple a été créé. La multitude de Dashboards couvre la complexité des analyses mais ne la supprime pas, rendant complexe pour l'utilisateur la tâche de trouver le bon Dashboard pour prendre sa décision.
Pour trouver le bon équilibre, je m'efforce d'identifier le moment où intervient la prise de décision et ce qui différencie une bonne décision d'une mauvaise. Je me suis alors immergé dans le quotidien des utilisateurs avec l'objectif de comprendre le processus mental qui leur permet d'identifier la bonne décision à partir des produits et informations à leur disposition. Une sorte de vis-ma-vie que l’on appelle “Aller sur le Gemba” en Lean.
Dans la solution choisie, j’ai dû faire des choix concernant la navigation, la hiérarchisation des données, leur représentation (courbes, graphiques, scorecards, etc.), et nous agrégeons des données ensemble afin de reproduire la réflexion des utilisateurs et simplifier la prise de décision. Finalement, j’accepte qu'un produit ne couvre pas tous les cas d’analyse pour qu’il soit utilisable.
Delivery : L’équilibre entre la vélocité Data et la vélocité Applicative
Le dernier équilibre se trouve au moment du Delivery des fonctionnalités envisagées. Dans la squad d'un produit d'aide à la décision, il y a les Data Engineers et les Software Engineers. Les Data Engineers fournissent aux Software Engineers les données utilisées par les fonctionnalités.
Imaginons une situation de déséquilibre dans une squad avec des Software Engineers livrant 2 fonctionnalités par mois alors que les Data Engineers délivrent les données d’une seule fonctionnalité sur la même période. Une fois la première fonctionnalité livrée par les Software Engineers, celle-ci n’est plus en mesure de créer de la valeur avec la fonctionnalité suivante. Dans la situation où les vélocités sont inversées, l’équipe data va créer du stock en continuant de délivrer des données qui ne seront jamais exploitées par les utilisateurs pour prendre une décision.
Le Product Manager doit alors trouver le bon équilibre pour que les Data Engineers livrent les données juste avant que les Software Engineers ne commencent le développement des fonctionnalités qui nécessitent ces données. En Lean, ce rythme de production idéal s’appelle le Takt time.
Pour me rapprocher de cet équilibre, j’ai d’abord dû identifier indépendamment pour la partie Data et la partie Applicative la vélocité de l’équipe à l’aide des méthodes de mesure issues des méthodes Scrum. Ensuite, j’ai collaboré étroitement avec les Lead Développeurs Data et Applicatifs pour mesurer et comprendre la complexité des fonctionnalités envisagées. Et finalement, j’ai pu ajuster la conception de mes fonctionnalités et séquencer mon Plan de Release afin d’équilibrer la delivery de la partie Data et Applicative de la squad.
La bonne synchronisation des équipes devient élément clé dans la conception et la priorisation des fonctionnalités du produit
Conclusion
En conclusion, pour maximiser la valeur livrée, le Product Manager doit trouver le bon équilibre à chaque étape de la conception et développement de son produit Data.
Pour m'aider dans cette tâche, je me suis fortement inspiré du Lean, consistant à penser la conception du produit comme un flux avec plusieurs étapes, où chaque étape possède des critères de qualité pour pouvoir passer à la suivante.
En Problem & Solution Discovery, j'ai adapté le flux FOCUSED du livre Discovery Discipline pour m'assurer, tout d'abord, de comprendre en profondeur les besoins des utilisateurs tout en évaluant la disponibilité et la qualité des données et, ensuite, de trouver le juste milieu entre la complétude des analyses et la simplicité d'utilisation.
En Delivery, j'ai utilisé des méthodes éprouvées par Theodo : une succession de Kanban puis de Scrum, permettant de réduire au maximum le lead time grâce à la synchronisation des Data Engineers et des Software Engineers.
