La data, amie ou ennemie ?

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 ainsi 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 difficile pour la majorité des employés d’accéder aux données.
• La réconciliation : les données se répartissent sur plusieurs outils.
• La pérennité : les données ne se maintiennent pas 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 alors de créer un “tagging plan” avec 47 events et 132 propriétés. Certains ne se définissent pas parfaitement et vous aurez donc 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 alors d’ajouter petit à petit, des données fiables, ciblées et dont nous savons déjà l’utilisation que nous allons en faire.

Ainsi, j’ai mis en place un template (clairement, le “T” de cet abécédaire se dédiera 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).

De plus, ces onglets se composent chacun de 3 colonnes :

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

L’objectif est donc 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.

Ainsi, 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.