L'équipe data gérée comme une équipe produit ?
ENTREPRISE DATA DRIVEN
PEAK LAB
2/6/20244 min read
L’équipe data gérée comme une équipe produit ?
C'est un concept qui se popularise depuis au moins 5 ans et que nous trouvons idéal pour développer la cohésion des équipes au sein de l'entreprise et faire émerger de nouveaux insights créateurs de valeur.
✨ Quelle différence avec une équipe data traditionnelle ? De manière assez banale, tout le monde s’accordera à dire que le rôle de l'équipe data est de répondre au besoin data de ses clients internes.
💡 C’est dans la définition de ce qu'est un “besoin data” que réside la différence avec une équipe classique qui traite des demandes de création de dashboards et des analyses ad hoc.
➡️ Dans le contexte d'une équipe data classique, le besoin data sera formulé comme “j'ai besoin d’une courbe représentant le taux de joignabilité en hebdo. Elle devra être rouge avec des étiquettes au-dessus”
➡️ Dans le contexte d'une équipe data gérée comme une équipe produit, le besoin sera exprimé comme une question business : “Je veux voir si mes actions de stratégie de numérotation ont porté leur fruits ?” ou encore mieux “Pouvez-vous m’aider à améliorer le taux de joignabilité de mes campagnes ? “
❓Pourquoi passer de l'un à l'autre ? Parce qu’aucun utilisateur final n’envoie à une équipe de développent logiciel la solution technique qu’elle devra appliquer, alors pourquoi procéder différemment avec une équipe data ?
Dans beaucoup d'entreprises, une équipe data traditionnelle aura toute sa place. Le but ici n'est absolument pas de dénigrer cette organisation qui peut avoir un sens dans une structure pérenne, avec peu de changements.
✅ A nos yeux, cette approche a plusieurs avantages :
➡ Profiter de l'innovation : les connaissances de l'équipe data se limitent rarement à ce que les utilisateurs finaux voient. Leur poser une question ouverte permet d'ouvrir le champ des possibles. Très souvent, les membres de l'équipe data maîtrisent les techniques de modélisation, de machine learning etc. Dans notre exemple, l'équipe data pourrait proposer de mener un A/B test pour une conclusion plus propre.
➡ Développer les équipes data et leur adhésion au succès de l'entreprise. Si on sait à quoi sert un tableau de bord et quelle décision on prend à son aide, n'est ce pas plus motivant ?
➡ Prioriser les actions de l'équipe data : Comment prioriser entre un graphique demandé par l'équipe A et celui de l'équipe B ? Il est tout de suite plus simple de trancher si l'on compare le ROI des décisions prises grâce à chaque dashboard
➡ Limiter le nombre de dashboards et d’analyses, dont chacun doit répondre à une question business et être utile à un type d’utilisateur particulier
➡ Les produits ainsi développés sont mieux réplicables d’un projet à l’autre, parce que plus légers, mieux maîtrisés par les équipes
🏃Quelques pistes pour commencer (même si l’aventure est de longue haleine)
Côté décideurs et "clients internes"
➡ Donner du sens à l’équipe data :
au travers d'expression de besoins vers l'équipe data qui devrait être construite comme un problème business. De chaque expression de besoin, l'équipe doit comprendre à quelle question le demandeur veut répondre, quel bénéfice il prévoit d'en tirer, à quel horizon.
grâce aux incursions de l’équipe data dans les équipes opérationnelles. Tous les membres de l'équipe data devraient savoir ce que produit l'entreprise, qui sont ses clients finaux, quels parcours ils utilisent, dans quels outils sont tracées les interactions, etc. Oui, en théorie, un data analyst doit pouvoir s'adapter à chaque entreprise, mais pour être plus percutant dans les analyses fournies et les dashboards construits, il est illusoire de penser qu'on peut continuer à travailler de son bureau sans jamais aller voir les opérations.
intégration l’équipe data au tour de table de décisions. Nous voyons souvent l'équipe data complètement exclue des décisions, avec de temps en temps les chiffres issus de ses études mal interprétés ou "remodelés" pour travestir la réalité. Si l'équipe data est autour de la table, elle devrait être garante de la bonne interprétation des chiffres.
Côté équipe data elle-même :
➡ L'équipe data doit définir ses personas : on ne proposera pas le même produit à un directeur qu'à un responsable logistique. Un dashboard qui est sensé servir à tout le monde, ne sert à personne dans les faits. C’est en les destinant en un type d’utilisateur particulier qu’on obtient de l’adhésion !
➡ Communiquer régulièrement sur le chantier entamé, sa roadmap, les avancées. Le chantier de "reconstruction" est long, il est donc crucial de tenir les clients internes informés, les former, prendre les inputs.
➡ Mener des ateliers de résolution de problème pour ouvrir l'esprit car passer d'une méthodologie à l'autre n'est pas chose facile
et discuter, discuter, discuter
Quelques personnes qui ont écrit sur le sujet si vous voulez développer la réflexion :
Contacts
contact@peaklab.agency
Abonnez-vous à notre newsletter
+33 (0)1 89 86 27 47
25, Rue de Ponthieu, Paris, Île-de-France 75008