Et oui, on commence par la Data !

Si vous travaillez au sein d’une équipe Produit, vous devez utiliser les données à différents stades des développements.

Durant la phase de priorisation afin de vous aider à :

  • comprendre le problème et le sizer,
  • comprendre vos utilisateurs.

Durant la phase de spécification afin de :

  • vous aider à définir les solutions,
  • mettre en place le(s) KPI(s) que vous suivrez une fois la feature finie, et trouver les questions auxquelles vous voulez répondre quand la feature sera live.

Après le développement afin de :

  • mesurer le succès (ou l’échec),
  • monitorer,
  • suivre le projet,
  • vous aider à améliorer le projet.

Toutes les personnes qui travaillent dans le Produit que j’ai rencontrées, qu’elles soient en startups, en “scaleups” ou dans une entreprise du CAC40, ne sont pas 100% satisfaites de leurs données. J’ai pu identifier 5 raisons principales à cette insatisfaction :

  • La quantité : il n’y a pas assez de données.
  • La qualité : les données ne sont pas fiables.
  • L’accès : il est trop compliqué pour la majorité des employés d’accéder aux données.
  • La réconciliation : les données sont réparties sur plusieurs outils.
  • La pérennité : les données ne sont pas maintenues dans le temps.

Je ne suis pas non plus satisfait à 100% de la data chez nous, mais mon conseil serait de commencer petit, très petit. Ne jamais ajouter trop d’événements ou de métriques en même temps. La pire idée que vous puissiez avoir est de créer un “tagging plan” avec 47 events et 132 propriétés. Certains ne seront pas parfaitement définis et vous aurez sans nul doute au moins un des 5 problèmes listés plus haut beaucoup plus rapidement que ce que vous imaginez. La data sera votre meilleure alliée, mais il faut toujours avoir en tête qu’elle peut vite devenir votre pire ennemie voire une vraie mythomane !

Après avoir fait un certain nombre d’erreurs dont il est question ci-dessus, nous testons un nouveau fonctionnement. L’idée est d’ajouter petit à petit, des données fiables, ciblées et dont nous savons déjà l’utilisation que nous allons en faire.

Pour ce faire, j’ai mis en place un template (clairement, le “T” de cet abécédaire sera dédié aux templates!) que l’on doit compléter avant chaque kick-off de projet.

Ce document comporte 2 onglets identiques à compléter sur  :

  • l’usage (Quanti),
  • la performance (Quali).

Ces onglets sont composés chacun de 3 colonnes :

  • Questions.
  • Réponses attendues.
  • Evénements à ajouter.

L’objectif est d’identifier, avant d’entamer les développements, la data nécessaire pour évaluer le succès ou l’échec d’un développement de manière Quanti & Quali.

Pour identifier les bons événements et paramètres à remonter, l’idée de ce template est de se demander :

  • Quelle question vais-je poser à mon product analyst à J+7 de la livraison d’un projet pour évaluer l’usage / la performance ?
  • Quel format de réponse j’espère avoir (%, graph, funnel, etc.) ?

Le product analyst peut donc définir directement les événements et paramètres dont il aura besoin pour répondre à ces questions avec le type de réponses attendues.

Project Performance Tracking

Ces articles pourraient vous intéresser

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

La Newsletter des Product Managers

Recevez nos articles 2 fois par mois et devenez un top gun du Product Management!