Business : La dure vérité de la raison pour laquelle nous avons besoin de gestionnaires de produits de données

Ce ne sont pas seulement des idées de ciel bleu – c’est un processus de navigation dans des possibilités infinies

Les données sont une priorité pour la plupart des chefs de produit. Les modèles courront le monde, les grands gagnants étant les organisations axées sur le modèle qui créent des produits qui collectent des données et apprennent en permanence à optimiser la croissance, accélérant ainsi ce cycle. Mais le dessous de ce phénomène est qu’au cœur de tout modèle réussi se trouve données représentatives. Bien que l’idée et le produit final puissent être impressionnants et géniaux pour les OKR trimestriels, cela nécessite beaucoup d’efforts non sexy. Tout comme les logiciels, les données ont besoin de leurs propres cadres pour gérer ce processus afin d’obtenir des résultats positifs – entrez dans le Data Product Manager.

Le cas du Data Product Manager

J’aime considérer les solutions technologiques comme Maya – Équipe de philosophie indienne pour le monde synthétique des faits et des événements, imposée au monde par des abstractions telles que la mesure, la classification, la division. Le cycle de vie de ces solutions est son propre type de technologie Karma (un peu comme la dette technologique) – chaque fois que nous construisons une solution, cela nécessite des actions supplémentaires de contrôle de la qualité, de maintenance, d’extension. L’acte de forcer technologique Maya sur le monde est intrinsèquement anti-équilibre, créant des conséquences karmiques pour l’équipe et les clients.

Dans cette optique, le rôle de tout bon chef de produit est de choisir les bons problèmes, de les mettre en relation avec les bonnes solutions et de préparer les pistes pour l’équipe. Obtenir la «qualité» des modèles fonctionnant sur des données représentatives n’est pas différent: alors que les avantages d’un modèle réussi sont énormes, il existe un potentiel encore plus grand pour un trou noir de complexité.

Les données ne font plus que des rapports – les données deviennent leur propre domaine de produits, avec leurs propres livrables, clients, cycle de vie de développement et besoins en infrastructure. Afin de répondre aux attentes et d’éviter le chaos des analyses de l’espoir pour le meilleur, nous avons besoin de chefs de produit pour diriger ces produits de données de l’idéation à l’achèvement.

Qu’est-ce que la gestion des produits de données?

La «gestion des produits», encore plus dans les «données», est nébuleuse. Définissons ce que c’est.

Certaines organisations distinguent les «chefs de produit» plus stratégiques et axés sur le client des «propriétaires de produit» plus axés sur la mise en œuvre. Heureusement il y a une petite industrie artisanale de blogs qui dénigrent ce modèle «horizontal», car nous avons une situation où le Product Owner ne comprend pas le client, et le Product Manager ne sait pas ce qui est techniquement possible. Le résultat final:

• Le propriétaire de produit aveugle a du mal à fournir de bonnes exigences aux ingénieurs, ou pire, cède le contrôle total de la feuille de route de l’ingénierie, ce qui entraînera généralement des luttes intestines, une perte de valeur et peut-être même une perte d’emplois.
• Le chef de produit aveugle technique fournit des produits de qualité inférieure aux clients (et ils ne sont peut-être même pas assez profonds dans les détails pour le reconnaître).

C’est bien que nous ayons essayé d’établir des responsabilités claires, mais nous nous sommes retrouvés avec un jeu à gros enjeux de téléphone cassé.

Nous avons besoin de chefs de produit capables de se connecter entre l’analyse de rentabilisation et les détails techniques, servant de partenaire aux clients et aux ingénieurs. Cela signifie que le chef de produit assume un rôle de bout en bout plus important, axé sur la stratégie produit, la priorisation, la solution et la livraison. Naturellement, le chef de produit ne peut pas tout faire, et c’est là que les opérations / analystes des produits entrent en jeu, servant d’interfaces quotidiennes avec les clients, évaluant les problèmes de priorisation et assurant la livraison en douceur des solutions via l’UAT et les déploiements.

Cela devrait avoir du sens pour toute équipe produit, mais plus encore pour une équipe produit de données. Étant donné que le produit de données est fondamentalement un modèle de réalité, les chefs de produit doivent être en contact avec la réalité des clients, mais également capables d’adapter une solution technique à cette réalité. Le Data Product Manager doit être en mesure de voir le concept technique du début à la fin, en travaillant avec les équipes de produits front-end pour collecter des données utiles, avec l’ingénierie des données sur les processus ETL, avec l’ingénierie ML sur le développement du modèle, jusqu’au déploiement. À ce lien, le Data Product Manager est responsable des étapes suivantes du cycle de vie du produit de données:

• Le chef de produit identifie les opportunités pour ce qui peut et doit être modélisé – c’est le stratégie de produit de données.
• Priorisation devrait être un effort conjoint, en partie à l’écoute des clients, en partie le dimensionnement des problèmes avec les analystes, le chef de produit définissant les attentes autour de ce qui peut être modélisé avec combien d’effort.
• Solutioning est un jeu de freins et contrepoids amicaux. Le chef de produit crée des spécifications conceptuelles (flux de données, ERD, témoignages d’utilisateurs), les ingénieurs forent des trous («vous avez raté ce cas de bord»), le chef de produit se charge de toute suringénierie («pourquoi avons-nous besoin de Spark pour cela») , les deux étant finalement d’accord sur une conception technique et des délais. Avec les ingénieurs ML, cela est plus axé sur le cadrage des problèmes et l’exploration des données, mais peut être considéré comme un processus analogue.
• dans le livraison phase, l’équipe décompose la conception en tâches, gère les sprints, exécute les tests et exécute globalement la conception et les délais. Cependant, ce n’est jamais aussi simple, car la complexité se glisse – cela nécessite sa propre finesse pour hiérarchiser et atténuer ces problèmes. En fin de compte, le chef de produit travaille avec les opérations / analystes de produits pour effectuer des tests d’acceptation de la solution par les utilisateurs et garantir un déploiement réussi aux clients.

Les produits de données sont essentiellement des modèles de réalité, et la modélisation de la réalité est difficile. À mesure que ces modèles deviennent plus répandus, nous avons besoin de bons gestionnaires de produits de données pour mener ce processus à partir de la ligne de front, et nous devons être clairs sur ce qu’est ce processus. J’espère que cet article a aidé à clarifier ce que cela devrait impliquer.