Qu’est-ce qu’un produit Data ?

Introduction 

Le nombre de données récoltées et exploitées par nos systèmes informatiques ne cesse d’augmenter, ce qui favorise l’essor de produits data, terme de plus en plus présent dans la littérature produit.

Dans cet article, nous allons définir ce qu’est un produit Data et aborder les différences qui existent par rapport à un produit dit “classique”, afin que vous puissiez aborder vos futurs produits data avec les idées plus claires ! 

Pour commencer, il faut avoir en tête les différentes caractéristiques qui définissent une approche produit : 

Pour en savoir plus : https://blog.octo.com/passer-du-mode-projet-au-mode-produit/

Ainsi, lorsque nous parlons d’un produit data, nous nous inscrivons dans une démarche produit, c’est-à-dire dans une démarche qui place les utilisateurs au centre et qui cherche à créer de la valeur de façon incrémentale et continue.

Cette première clarification étant faite, il règne souvent une certaine confusion autour des produits data, concept derrière lequel beaucoup mélangent à la fois les produits qui sont de la data et les produits qui exploitent leur data pour prendre des décisions produit (produit data driven).

Or, ces deux notions sont différentes, voici la distinction que nous vous proposons : 

Nous ne traitons volontairement pas l’aspect “data as a product” dans cet article car il fera l’objet d’un article dédié.

Ainsi nous distinguons : 

  • Produit Data : la proposition de valeur du produit repose sur de la data, qui est un “enabler” pour le produit : si je n’ai pas de data ou que je n’arrive pas à l’exploiter, alors la feature ne fonctionne pas, ou alors il n’y a carrément pas de produit. 

Exemple : je souhaite développer un algorithme de recommandation, si je n’ai pas de données, je ne suis pas en mesure d’entraîner mon modèle et il ne pourra pas faire de recommandations personnalisées à mes utilisateurs

  • Produit Data Driven : c’est une façon de conduire le développement de son produit, en exploitant la data pour driver les décisions produit, mais ce n’est pas une propriété qui définit en elle-même le produit. Dans ce cas-là, la donnée est utilisée de façon informative.

Exemple : je peux développer un site web sans mesurer l’usage de mes utilisateurs,  il ne sera alors pas développé de façon “data-driven”. A l’inverse, je peux décider de développer ce même site en mesurant l’usage qu’en font mes utilisateurs pour guider ma priorisation et la prise de décision : mon site sera développé selon une approche “data-driven”.

A noter qu’il existe un continuum entre les deux : un produit data peut aussi être data driven et inversement. Par exemple, un algorithme de recommandation est un produit data qui exploite les données du produit pour s’améliorer continuellement.

Dans la suite de cet article, nous allons aborder les produits Data afin de comprendre les différences qui existent avec les produits dits “classiques”, puis dans un second temps nous parlerons des produits Data Driven, afin de comprendre l’apport de cette approche, illustrée par quelques exemples issus de nos retours d’expérience.

Les produits Data

Les produits data sont des produits dont la proposition de valeur repose sur la donnée. C’est le cas par exemple pour un algorithme de détection de fraude bancaire, d’un dashboard de pilotage ou encore d’une pipeline de données en vue d’une utilisation ultérieure. 

Par rapport à un produit dit “classique”, nous avons identifié 3 grandes différences pour un produit data.

1ère différence : Un produit data repose sur des données et… il existe une véritable incertitude quant aux données

Ces incertitudes sont à la fois techniques (les données sont-elles disponibles ? Quelle est leur fraîcheur ? Quel est leur niveau de qualité voire de fiabilité ?) et métier (avons-nous la capacité d’atteindre des résultats suffisants pour apporter de la valeur sur un sujet de prédiction ? La taille de l’échantillon est-elle représentative ?). 

Ces incertitudes nécessitent d’investir du temps sur des explorations de données et des expérimentations, ce qui peut modifier le rythme de delivery.

 Pour en savoir plus sur le spike, vous pouvez consulter cet article du blog OCTO (point 4).

2ème différence : Exploiter les données n’est que la face immergée de l’iceberg …

En effet, pour pouvoir exploiter des données, il faut d’abord : 

  • Les récupérer
  • Les stocker
  • Les nettoyer 
  • Les exposer
  • Les protéger et les gouverner

Ce travail est long et va nécessiter d’avoir dès le début des réflexions et discussions concernant le traitement à appliquer aux données. 

Cette face immergée de l’iceberg nécessite également une forte acculturation technique au traitement, nettoyage, stockage et exploitation des données pour tous les membres de l’équipe, mais aussi aux sujets de gouvernance et de sécurité de la donnée, ce qui n’est pas toujours le cas pour un produit classique. La compréhension de tous ces enjeux est un des piliers de la réussite du produit.

C’est ce traitement préalable qui va permettre de transformer une simple donnée en une information utilisable pour pouvoir comprendre son produit et prendre des décisions comme illustré dans le schéma ci-dessous.

Plus d’infos sur cette pyramide : ici

3ème différence : Un produit data nécessite des profils Data

Pour développer des algorithmes de machine learning, construire des pipelines de données ou encore analyser et mettre en forme la donnée à exploiter, il faut construire une équipe avec des profils spécifiques en fonction de ses besoins, comme par exemple des : 

Ces nouveaux profils peuvent impacter l’organisation et le rythme de l’équipe, notamment du fait de la place de l’expérimentation mentionnée plus haut (si le sujet vous intéresse, ces deux articles abordent les sujets d’expérimentations et de travail par petits incréments dans des contextes de Delivery de Machine Learning).

Mais il faut garder en tête que même avec une équipe faite de profils data, comme pour tous les produits informatiques, il s’agit de répondre à une problématique métier et de s’inscrire au mieux dans les usages des utilisateurs.

Malgré – ou plutôt même – grâce à ces différences, nous pensons qu’il est nécessaire d’avoir un Product Owner (PO) pour les produits Data (plus d’infos sur le PO data ici). Aujourd’hui encore, beaucoup de produits data n’embarquent malheureusement pas de PO, alors que pourtant avoir un PO, c’est : 

Passons maintenant aux produits Data Driven

D’autres types de produits exploitent de la donnée afin d’en tirer de la valeur même s’ils ne l’utilisent pas nécessairement au cœur de leur processus de développement. C’est ce qu’on appelle un produit Data Driven. Ces produits exploitent par exemple leurs données d’utilisation pour prendre des décisions.

Et bien sûr qui dit data, dit également profils spécifiques, processus de retraitements de la donnée, stockage, expérimentation, incertitude … comme on pourrait le retrouver dans un produit data !

Pourquoi exploiter la data de son produit ? 

Pour avoir une meilleure connaissance de ses utilisateurs en accolant des éléments quantitatifs à des analyses qualitatives dans le but de : 

La data s’inscrit elle aussi dans le cycle de vie du produit, elle agit comme un accélérateur permettant :

  • Durant la phase de Discovery : d’explorer les données afin de creuser les problèmes et bien cerner les besoins utilisateurs,
  • Durant la phase de Delivery : de prioriser les fonctionnalités selon les données récoltées et de mesurer l’écart d’impact
  • Durant la phase de Growth : d’améliorer significativement la viabilité du produit en favorisant son adoption.

Quelques prérequis pour exploiter les données de son produit et adopter une approche Data Driven

  • Réfléchir aux métriques dès le cadrage d’une nouvelle fonctionnalité afin de savoir ce que l’on souhaite mesurer et quel est l’impact attendu,
  • Avoir accès aux données récoltées en production et avoir la capacité de les collecter, et traiter. Ce qui nécessite d’investir du temps dans la mise en place d’une pipeline data,
  • Établir des objectifs clairs et quantifiés pour prioriser les cas d’usage et l’impact des équipes: par exemple grâce à des méthodes types OKR ou North Star Metric,
  • Sensibiliser toutes les parties prenantes (Sponsor, client, heads of…) sur la notion d’incertitude dans les résultats si nécessaire,
  • Toujours embarquer les équipes métier et les designers dans la démarche afin d’être pertinent dans l’analyse des données,
  • S’aligner sur la définition et la compréhension des données afin d’être sûr de bien parler tous de la même chose ! 
  • Définir l’ambition stratégique de la data sur le produit (roadmap) pour en déterminer les outils, process et organisation, et surtout ne pas hésiter à les faire évoluer dans le temps !

Mais quelles données exploiter ? 

Il existe plusieurs types de données que l’on peut exploiter dans son produit (application mobile, site internet etc.) : 

Les données de navigation 

Ce sont les données collectées grâce aux tags et au tracking implémentés dans le produit . Elles permettent d’analyser les parcours effectués par les utilisateurs sur le produit en collectant des informations telles que le nombre de pages vues, le nombre de clics sur les boutons etc.

Attention toutefois, ce sont des données qui doivent être conformes à la règlementation RGPD, elles doivent donc être généralement anonymisées et ne prendre en compte que les utilisateurs qui ont accepté les cookies, ce qui fait qu’elles ne sont donc pas toujours totalement représentatives. Ces données ne permettent pas non plus de suivre un utilisateur récurrent dans son usage spécifique du produit (on pourra savoir s’il est revenu – s’il n’a pas supprimé ses cookies – mais pas s’il a réalisé plusieurs fois la même action).

Les données applicatives

Ce sont les données provenant de la base de données de production. Elles permettent d’analyser les actions réellement réalisées par les utilisateurs (ex : nombre d’inscription, nombre de réservations sur une plateforme d’e-commerce etc.).

Attention ces données ne donnent pas d’informations sur les parcours utilisateur, elles se concentrent uniquement sur le résultat final de son opération.

Données issues de bases de données externes

Ce sont comme leur nom l’indique des données provenant de bases de données externes qui peuvent être open source ou achetées. Ces données peuvent être croisées avec les données applicatives ou de navigation pour obtenir des données enrichies (ex : données de la base SIREN, données géographiques etc.)

Quelques exemples d’exploitation de la data pour améliorer le produit 

Les tableaux de bord

Il est intéressant de construire des tableaux de bord basés sur des KPI Produit déterminés en amont afin de suivre l’acquisition, la rétention ou encore la fidélisation des utilisateurs de son produit.

Exemple de tableau de bord d’une application de réservation de spectacles

Tunnel de conversion

Un tunnel de conversion correspond au parcours effectué par un utilisateur pour arriver sur le produit jusqu’à sa finalité, c’est-à-dire jusqu’à l’étape de conversion. 

Analyser ces tunnels a plusieurs bénéfices : 

  • Comprendre les comportements des utilisateurs grâce à des données quantitatives et objectives (il n’y a pas de biais comme on peut parfois en avoir lors d’entretiens ou de tests utilisateurs puisque l’utilisateur est seul avec le produit),
  • Analyser les pages ou boutons qui convertissent le mieux et essayer de les décortiquer pour comprendre pourquoi et pouvoir le reproduire (design, texte explicite etc.)
  • Comparer plusieurs façons d’accéder à une page, pour capitaliser sur ce qui convertit le mieux ou à l’inverse développer le parcours le plus fragile.

A/B Testing

L’A/B Testing expose la moitié des utilisateurs à une version et l’autre moitié des utilisateurs à une autre version du produit avec des variations sur une fonctionnalité, ce qui permet de valider une hypothèse. Ces variations peuvent concerner 2 pages, 2 boutons, 2 textes, 2 algorithmes etc.

Attention, il est important de ne faire varier qu’un seul élément afin de déterminer précisément l’impact d’une version et de limiter les effets de bord, en réalisant cet A/B Testing “toutes choses étant égales par ailleurs”. Il faut également déterminer des métriques en amont pour faciliter la prise de décision en aval.

Cette méthode permet de prendre des décisions éclairées par la donnée  de façon quantitative et non qualitative comme pourraient l’être des tests utilisateurs par exemple.

Red Routes

L’analyse des  “red routes” permet de placer les fonctionnalités d’un produit en fonction de : 

  • Leur nombre de visites 
  • La fréquence de ces visites 

Dans le coin supérieur droit, on retrouve les fonctionnalités les plus fréquemment et largement utilisées ; celles qui ont donc une forte valeur ajoutée pour les utilisateurs. Tandis que le coin inférieur gauche regroupe les fonctionnalités les moins utilisées ; celles qui sont à retravailler ou à abandonner. Il peut être intéressant de confronter les red routes aux tests utilisateurs, notamment pour repenser les parcours en mettant en valeur certaines fonctionnalités peu utilisées mais demandés par les utilisateurs lors des interviews de cadrage.

A noter qu’il est également possible d’exploiter une version simplifiée uniquement basée sur l’un des deux axes si cela est plus simple à réaliser ou que l’une des données est manquante. Cela permet une première analyse déjà pertinente. 

Quelques conseils pour que votre produit data ou data driven soit un succès

Embarquez les équipes ! 

Pour rendre son produit Data driven, une des choses les plus importantes est d’embarquer son équipe ! Chaque profil (Product Owner, Product Manager, Designer, Développeur etc.) doit être sensibilisé à l’importance des données.

Pour cela, nous vous partageons plusieurs conseils issus de nos retours d’expérience : 

Comprendre les données 

Le frein principal que nous constatons est souvent le fait d’être peu à l’aise avec les données : les profils qui se disent “peu scientifiques” ou “peu matheux” ont souvent une certaine appréhension avec le fait de devoir lire et interpréter des données. 

N’hésitez pas à organiser des sessions pour expliquer clairement les données, les processus de votre pipeline data et même de façon très précise comment lire un graphique, interpréter un chiffre, les questions à se poser sur un graph, les pièges à éviter etc. Il faut acculturer tous les profils !

Si vous souhaitez vous former, OCTO Academy propose d’ailleurs une formation Fondamentaux de la Data Literacy.

S’aligner sur les définitions

Rien de pire que de ne pas parler de la même chose ! 

Il faut par exemple s’aligner sur la définition d’un utilisateur actif : est-ce celui qui s’est rendu sur le produit ? Celui qui s’est créé un compte ou qui a réalisé une certaine action ? A quelle fréquence ? Il n’y a pas de bonne réponse intrinsèque, cela dépendra du produit et de ce que l’on souhaite mesurer.

Vous pouvez organiser des ateliers pour définir chaque métrique ainsi que la façon de la calculer afin d’être sûr d’avoir le même résultat et la même analyse. 

Communiquer un maximum 

Exhibez la donnée ! Plus la donnée est facile d’accès et visible, plus il sera facile de s’en emparer. Voici une liste d’exemples (non exhaustive) pour créer de l’émulation autour de la donnée : 

  • Créer du management visuel, par exemple en affichant un tableau de bord produit dans les locaux si vous êtes en présentiel ou visible sur un outil numérique que vous utilisez (page d’accueil de l’application, slack etc.)
  • Avoir des rituels pour étudier/analyser la donnée : à chaque démo produit, en point roadmap etc.
  • Communiquer à l’oral par exemple au daily stand-up les métriques les plus pertinentes, mais aussi à l’écrit par mail
  • Organisez des sessions sous la forme de d’initiations/tutos pour inciter chacun à prendre en main les dashboards, comprendre les données du produit et se créer ses propres tableaux de bord selon son périmètre.

Conclusion

En conclusion, vous aurez compris que parler de produits data est parfois un abus de langage et qu’il faut bien penser à dissocier : 

  • Les produits Data dont le cœur de la proposition de valeur repose sur l’exploitation de données. Ces produits là ont quelques spécificités par rapport aux produits dits classiques, notamment car ils reposent sur beaucoup d’incertitudes liées à l’essence même des données, qu’ils nécessitent des traitements spécifiques ainsi que des profils dédiés dans une équipe de delivery.
  • Les produits Data Driven peuvent être en revanche n’importe quel type de produits mais pour lesquels une approche data driven est adoptée. Cette démarche permet de récolter des retours utilisateurs de façon quantitative, et de mettre ainsi les utilisateurs au centre des développements pour améliorer leur expérience. 

Deixe um comentário

O seu endereço de e-mail não será publicado.


This form is protected by Google Recaptcha