Qui devrait vraiment posséder votre plan de suivi ?

Publié: 2022-12-22

NDLR : cet article a été initialement publié sur le blog Iteratively le 11 janvier 2021.

"Les données sont un sport d'équipe" est une chose à laquelle nous croyons fermement et dont nous parlons souvent chez Amplitude. Les plans de suivi analytique ne sont pas différents - les plans de suivi (et leur instrumentation) sont collaboratifs par nature. Ils fonctionnent mieux lorsque les équipes concernées se réunissent.

Prenons l'exemple d'une nouvelle version de fonctionnalité. L'équipe produit a défini les objectifs et les métriques de cette nouvelle fonctionnalité et aura une vue sur le suivi des événements nécessaire pour mesurer ces métriques. Les équipes de développement iOS, Android et Web sont chargées d'instrumenter (et idéalement de tester) ces événements dans le code et auront une opinion sur ce qui est faisable. Un analyste ou un ingénieur analytique est responsable de la modélisation des données et se souciera de leur structure, et vous pouvez avoir plusieurs équipes chargées de créer des rapports et d'analyser les données dans plusieurs outils. En bref, dans l'analyse d'entreprise basée sur les données, presque tout le monde est impliqué.

L'exemple montre à quel point le suivi analytique est vraiment complexe et il montre également l'importance de la collaboration lors de la définition et de la capture des bons événements, de leur mise en œuvre précise et de la facilité d'exploration des données pour les consommateurs de données. Cela dit, avec autant de personnes impliquées, le suivi analytique devient facilement une patate chaude.

S'il appartient à tout le monde, il n'appartient à personne

Avec autant de parties prenantes impliquées, le plan de suivi devient souvent une responsabilité partagée, sans propriétaire clair. Et avec la responsabilité partagée vient peu de responsabilité.

Nous avons parlé à de nombreuses entreprises qui souhaitent (re)créer des processus autour du suivi analytique. Il tourne généralement autour d'une feuille de calcul ou d'une page Confluence ou Notion. Bien qu'il soit principalement manuel et qu'il n'y ait aucun moyen d'appliquer le plan de suivi dans le code, il s'avère utile au début et oblige les équipes à réfléchir davantage au suivi des événements.

Cependant, quelques mois plus tard, la page Notion ou Google Spreadsheet devient obsolète : le suivi de la dernière version n'a été documenté que dans une histoire Jira et pour quelques autres versions de fonctionnalités, il n'est plus clair si le suivi a été implémenté ou non. Personne ne se donne la responsabilité de tenir à jour le plan de suivi.

Alors, comment changez-vous cela pour le mieux et qui est le mieux placé pour posséder votre suivi analytique ?

Commencez par mettre l'analyse au premier plan

Avant de nous plonger dans la question de la propriété, nous devons mentionner la base requise pour le succès du suivi analytique : le suivi des événements est important et sans lui, vous êtes laissé dans le noir. La réalité est que pour la plupart des équipes, l'analyse est une réflexion après coup. Voici un exemple que nous voyons tout le temps :

PM travaille sur une version
La libération a lieu
Le PDG demande au Premier ministre comment il fonctionne
PM : "Laissez-moi demander à l'équipe des données"
Équipe des données : "Vous ne nous avez jamais fait venir, il n'y a pas de données sur cette fonctionnalité."
Le PM retourne voir le PDG sans réponse
L'équipe de données et le PM sont désemparés

Si l'analytique ne fait pas partie intégrante de chaque version, cela se reproduira encore et encore et peu importe si votre plan de suivi est vraiment élégant et à jour. Vous avez besoin de l'adhésion de toutes les parties prenantes (ainsi que de vos équipes de direction) pour que le suivi analytique soit tout aussi important que la fonctionnalité elle-même. Pas de suivi, pas de libération.

Vous avez besoin d'une responsabilité claire, de temps et de ressources pour responsabiliser les équipes concernées, puis vous devez intégrer le suivi des événements et les mesures de réussite jusqu'au niveau du ticket Jira (cela n'est fait que lorsque le code de suivi est envoyé avec le reste du code).

Ce que nous avons appris de plus de 400 entretiens avec des professionnels des données et des produits

En deux ans, nous avons interrogé plus de 400 chefs de produit, équipes de données et ingénieurs. Nous avons vu certaines choses.

Bien sûr, votre plan de suivi et le processus qui l'entoure sont uniques à votre entreprise, à la structure de votre équipe et à votre secteur (et c'est probablement pourquoi il est si difficile de bien faire les choses). Un plan de suivi pour une entreprise de commerce électronique sera très différent d'un plan de suivi pour une entreprise B2B SaaS. Ils impliquent différentes parties prenantes et résolvent des réalités entièrement distinctes. Le plus souvent, nous pouvons ventiler ce que nous avons vu par taille d'entreprise.

Start-up

Pour les petites entreprises, le processus de suivi est généralement ad hoc. C'est naturel car très peu de personnes sont impliquées et rend la complexité facile (plutôt) à gérer. Le plus souvent, on voit un responsable produit ou un responsable croissance s'approprier cette étape du parcours d'une entreprise.

PME

Dans une entreprise de taille moyenne, le processus incombe généralement au responsable des données/analytiques. Il y a plus de parties prenantes impliquées maintenant, et la complexité peut facilement devenir un problème. À ce stade, il existe un besoin certain de propriété pour limiter les dommages et cela incombe généralement à quelqu'un de l'équipe des données.

Entreprises

Dans les grandes entreprises, la personne responsable du plan de suivi sera généralement le responsable de l'analyse des produits. Pour les entreprises de commerce électronique, ce sera souvent le responsable du commerce électronique. Souvent, ils ne seront pas la personne au jour le jour qui maintiendra le plan ou appliquera le processus, ce sera quelqu'un au sein de leur équipe qui en sera responsable.

Nous avons vu divers degrés de succès de ces types de configurations. Alors, selon nous, qu'est-ce qui fonctionne le mieux?

Ce qui fonctionne : L'équipe produit est le propriétaire ultime

Voici ce que nous savons : le meilleur processus de propriété se produit lorsque l'équipe produit agit en tant que propriétaire ultime. Les chefs de produit doivent être le principal moteur et s'assurer que le suivi analytique fait partie de chaque version de fonctionnalité . Selon la taille de votre équipe, il peut s'agir d'un ou plusieurs chefs de produit ou d'un analyste produit dédié. Ils doivent être tenus responsables du suivi analytique dans le cadre de leur rôle et des OKR.

Mais comme nous l'avons mentionné précédemment, les données sont un sport d'équipe et nous recommandons aux équipes de se réunir pour définir des éléments tels que la dénomination et la taxonomie des événements. Les ingénieurs et les équipes de données auront des perspectives importantes car cela influence également leur quotidien. Bien que l'équipe produit soit l'exécuteur et le propriétaire ultime, elle ne doit jamais travailler en silo ou prendre des décisions importantes sans impliquer les bonnes parties prenantes.

La mise en place d'un conseil consultatif qui représente toutes les parties prenantes concernées a bien fonctionné pour les entreprises avec lesquelles nous avons travaillé. Toutes les décisions ne sont pas prises par le conseil consultatif, mais il devrait être le moteur au début, définissant votre taxonomie et votre processus et se réunissant régulièrement en fonction du nombre de changements majeurs qui se produisent au fil du temps.

Pour que les équipes produit s'approprient cela avec succès, vous avez besoin d'un processus clair en place :

Ayez des critères de réussite clairs pour les métriques qualitatives et quantitatives dans le cadre de chaque user story. Celles-ci doivent être définies par le PM et échangées avec l'équipe de données ou les analystes.
Suivi manquant ? Échouez la construction. La notion de terminé doit évoluer pour inclure le suivi analytique dans le cadre de chaque version. Cela ne signifie pas bloquer les versions juste avant le lancement, cela signifie mettre en œuvre un processus qui inclut des considérations de suivi dès le début.
La collaboration est essentielle. Alors que le PM sera propriétaire de la spécification de suivi des événements, l'équipe de données ou les analystes doivent être disponibles pour intervenir et aider à définir les détails de ce qui doit être suivi.

Donnez à vos chefs de produit les moyens de s'approprier

Pour certains PM, posséder le plan de suivi leur vient tout naturellement. Ils veulent le contrôle et ont l'expérience. Et ils n'ont pas non plus peur de demander de l'aide quand ils en ont besoin. Mais cela ne vient pas naturellement à tous les PM.

Tout d'abord, un changement de culture doit se produire : célébrez les performances et le succès d'une nouvelle fonctionnalité ou d'une nouvelle version de produit, et non le fait qu'elle a été livrée ! Étonnamment, pour beaucoup, c'est toujours l'expédition qui reçoit des éloges, pas si le produit fonctionne ou non.

Alors, comment donner à votre équipe produit les moyens de s'approprier le plan de suivi ? Ce n'est pas une liste exhaustive, mais j'espère qu'un endroit où les gens peuvent commencer:

Formation régulière : Bien suivre les événements est autant un art qu'une science (c'est-à-dire que ce n'est pas facile), alors assurez-vous que votre équipe dispose des connaissances nécessaires pour s'approprier confortablement. La formation peut être de style lunch & learn, des ateliers ou des sessions individuelles (n'oubliez pas d'enregistrer vos sessions pour les futures embauches).
Heures de bureau : nous avons connu un grand succès lorsque les équipes de données organisent des heures de bureau régulières pour que d'autres équipes tirent parti de l'expertise et des connaissances de l'équipe de données. Assurez-vous que les équipes arrivent préparées avec un ordre du jour ou des questions spécifiques pour éviter qu'elles ne se transforment en une réunion de type "bureau d'assistance".
Processus clair et points de contrôle : nous ne saurions trop insister sur l'importance d'un processus défini. Assurez-vous d'avoir un processus clair que tout le monde connaît, comprend et suit, et incluez des points de révision réguliers pour garantir la qualité, un peu comme les révisions de code et les demandes de fusion dans le développement de logiciels.
Intégrer un analyste : Ce n'est pas toujours une option, bien sûr, mais nous avons vu des équipes performantes intégrer un analyste de données dans une équipe produit à temps partiel ou à temps plein pour posséder le suivi analytique et aider les chefs de projet à explorer et analyser les données.
Analyses en libre-service : nous pensons qu'il est préférable de donner aux PM et à tous les autres membres de l'organisation les moyens d'explorer facilement les ensembles de données et d'obtenir rapidement des réponses aux questions. Amplitude est idéal pour cela et garantit des niveaux élevés de littératie des données dans toute votre entreprise.

Un rappel : les bons PM n'ont pas besoin de connaître SQL

Pourquoi se soucier du suivi des événements si vous n'êtes pas en mesure d'explorer les données vous-même de toute façon ? Pour développer le dernier point ci-dessus, nous avons vu des entreprises dotées d'équipes de données centrales qui possèdent tous les rapports et l'analyse des données. Il a ses avantages, mais d'après notre expérience, il peut limiter les PM et les autres et ils se soucieront moins du suivi analytique ou de la qualité des données.

N'oubliez pas que donner aux PM et à d'autres l'accès à Redash ou à d'autres outils basés sur SQL n'équivaut pas à donner aux PM le pouvoir de se servir eux-mêmes. Ne vous attendez pas à ce que vos chefs de projet connaissent (ou apprennent) SQL. Ce n'est pas leur travail. Au lieu de cela, donnez-leur une interface utilisateur facile à utiliser et de nombreuses formations pour accompagner l'outil et les ensembles de données. Bien sûr, la connaissance de SQL a ses avantages évidents et si vous êtes en mesure de trouver ou de former des talents dans toute l'entreprise (pensez au produit, au marketing, à la réussite des clients, etc.), vous pouvez le faire fonctionner, mais il a ses inconvénients et ses limites évidents.

Si les PM sont en mesure de se servir eux-mêmes, ils sont plus susceptibles d'explorer les données d'une version récente, par exemple. Lorsqu'ils explorent les données, ils sont plus susceptibles de se soucier de leur qualité, de leur richesse et de leur disponibilité. Créez une culture d'autonomisation et construisez un processus solide autour du suivi analytique et vous aurez des PM heureux, des analystes heureux, une équipe de données heureuse et même des développeurs heureux.

Amplitude est là pour vous aider

Amplitude aide les équipes de données, les chefs de produit et les ingénieurs à définir, instrumenter, vérifier et collaborer sur le suivi analytique. Nous résolvons de manière proactive les problèmes de qualité des données qui découlent de la dénomination incohérente des événements et du suivi manquant et fournissons un flux de travail pour gérer l'évolution de votre suivi.

Nous donnons aux chefs de produit les moyens de s'approprier le plan de suivi et d'améliorer la collaboration entre les équipes . Si vous souhaitez essayer Amplitude pour votre entreprise, créez un compte dès aujourd'hui ou réservez une démonstration avec notre équipe pour en savoir plus.