Data as a product : Comprendre ses utilisateurs finaux pour maximiser l’adoption

Résumé de cet article par ChatGPT :

"Cet article traite de la notion de "Data as a Product" et explique pourquoi les entreprises doivent considérer leurs données comme un produit à part entière. L'article explique que les données peuvent être utilisées pour créer de la valeur pour les clients et pour l'entreprise elle-même, et qu'elles doivent donc être gérées comme un produit stratégique plutôt que comme un simple effet secondaire des opérations de l'entreprise. Il met en avant l'importance de la qualité des données et de la gouvernance des données pour garantir leur fiabilité et leur cohérence. Enfin, l'article souligne que la réussite de la stratégie "Data as a Product" dépend de l'implication de tous les départements de l'entreprise, et pas seulement de l'équipe Data."

Un des défis majeurs des projets data-driven en entreprise reste leur adoption par les utilisateurs finaux. Selon une étude de NewVantage de 2021, pour 92% des entreprises du Fortune 100, le plus grand obstacle à une organisation data-driven reste la culture c.a.d les personnes, process et organisations. Ainsi, que ce soit dans la mise en place de programmes de transformation digitale, le développement d’une data platform pour centraliser un vaste volume d’information ou la mise en place d’un projet basé sur du machine learning, les équipes techniques doivent in fine se confronter à l’évaluation et aux critiques des utilisateurs finaux. “Je ne vois pas ce que ça apporte de plus par rapport à l’existant” ou “Je préfère mes méthodes ou outils actuels” continuent de porter des coups meurtriers aux initiatives des projets data.

Ces échecs sont trop souvent attribués au manque de maturité data des personnes concernées et deviennent des opportunités manquées pour trouver de nouvelles solutions à des problèmes complexes. Or, lorsqu’on se penche sur les phases de cadrage réalisées en amont, la compréhension du besoin utilisateur et la recherche de la valeur apportée sont les parties les moins investiguées au détriment des recherches techniques. L’aspect intangible de la donnée rend ce travail d’identification de la valeur ajoutée beaucoup plus ardu que sur un projet web ou sur une application. Les phases de cadrage se contentent soit de définir au mieux une corrélation entre l’usage et le produit développé (plus on met à disposition des nouvelles données plus les utilisateurs vont utiliser notre produit) soit au pire de déléguer cette responsabilité aux utilisateurs eux-même (“Mettons à disposition une quantité immense de données et les utilisateurs trouveront bien une utilité pour leurs cas d’usage.”).

Comment alors remettre les besoins et problèmes des utilisateurs au centre des phases de cadrage sur les projets data ? La conception d’un produit data autour du besoin utilisateur est un enjeu crucial pour qui vise l’adoption du produit développé tout en évitant de tomber dans le piège de la surenchère des fonctionnalités. Chez Sicara, nous nous appuyons sur la méthodologie des “Jobs To Be Done” de Clayton Christensen pour mieux comprendre nos utilisateurs finaux et construire des produits data qui ont réellement un impact.

La Job Theory au service des produits data

Dans son ouvrage Competing Against Luck, Clayton Christensen défend qu’un produit est avant tout la promesse d’un progrès au sens littéral du terme. Un produit est choisi car il permet de réaliser un avancement pour atteindre un objectif. Ainsi, le produit devient solution pour un problème donné et entre en compétition avec d’autres produits ou services qui traditionnellement ne seraient pas considérés comme des concurrents directs. Par exemple, si je dois me tenir informé des dernières nouvelles, je peux acheter en kiosque Libération, Le Figaro ou Le Monde, mais je peux aussi scroller sur Twitter pour lire les réactions des personnalités suivies ou juste discuter avec des amis plus “calés” en politique. Selon Christensen, nous embauchons donc des produits pour nous aider à réaliser un travail qui consiste en un objectif donné dans une situation bien précise. L’enjeu devient alors de comprendre ces “Jobs To Be Done” dans le cadre d’un projet data.

Plus précisément, selon Christensen, un “Jobs To Be Done” est la combinaison unique d’un utilisateur, d’un produit et d’un contexte. Comprendre le contexte d’utilisation est essentiel pour comprendre les éléments sociaux et émotionnels sous-jacents dans le choix d’une solution. Un même utilisateur peut ainsi utiliser un même produit pour deux objectifs distincts car les contextes sont différents. Prenons le milkshake de Clayton :

• 1er Jobs To Be Done : Je cherche le petit déjeuner idéal qui me tiendra au corps toute la matinée. Il me faut quelque chose de pratique à manger en voiture et suffisamment “fun” pour ne pas m’ennuyer dans les embouteillages. Je pourrais prendre une banane, mais je me retrouve coincé avec la peau dans la voiture. Je pourrais prendre un doughnut mais j’ai du sucre plein les doigts après. Je pourrais sinon passer au Drive de Mcdonald's mais je n’assumerai pas si un collègue me surprend dans la queue. Je choisis donc de partir sur un milkshake bien compact, fourni d’une paille très fine et garni de morceaux de chocolat.
• 2ème Jobs To Be Done : J’aimerais faire un petit cadeau à mes jeunes enfants qui m’ont accompagné pour faire les courses. Je suis seul avec eux et c’est l’occasion de les laisser céder à un petit plaisir coupable. Je pourrais leur acheter un jouet mais je devrai me justifier auprès de mon conjoint à la maison. Je pourrais leur promettre de faire un jeu après les courses mais je vais devoir faire une croix sur la préparation d’un dîner aux petits oignons. Je choisis donc de leur prendre un milkshake petit format, pauvre en sucre avec des morceaux de fruits.

Si la chaîne de milkshake voulait innover sur ses produits, elle devrait adresser deux “Jobs To Be Done” distincts et ainsi sortir deux nouveaux milkshakes.

Un dernier enseignement clef de la théorie des “Jobs To Be Done” est de prendre en compte aussi bien les forces qui encouragent un utilisateur à embaucher un nouveau produit que les freins aux changements. On distingue deux forces parmi celles qui poussent à l’adoption d’une nouvelle solution : le “push” qui traduit la volonté de résoudre un point de douleur actuel et le “pull” qui reflète l’aspiration à une meilleure situation. Côté freins au changement, il faut composer avec les “habitudes du présent” qui sont les arrangements ou les points positifs de la solution actuelle et “l’anxiété d’essayer quelque chose de nouveau”. Cette anxiété au changement est particulièrement accrue dans l’adoption des produits data par le sentiment de perte de contrôle et de défiance de l’utilisateur face à un traitement automatisé ou à des algorithmes “boîtes noires”.

La théorie des “Jobs To Be Done” nous permet ainsi de tirer 5 conclusions pour les projets data :

• Pour sortir de l’aspect intangible de la donnée, il faut s’intéresser au problème et au contexte derrière l’utilisation de la donnée (i.e traiter la donnée comme source d’information).

• Se concentrer sur le contexte d'utilisation de la donnée permet de tenir compte des ressorts émotionnels et sociaux et de sortir du débat purement technique ou fonctionnel.

• Pour une même donnée, il peut exister plusieurs “Jobs to be done”.
• Les intermédiaires entre la donnée et le consommateur final de l’information (interface utilisateur, data scientist retraitant l’information derrière…) doivent être pris en compte dans l’analyse du “Jobs To Be Done”
• Les produits data doivent tenir compte des freins à l’adoption comme les habitudes des solutions existantes et l’anxiété face au changement.
  

Déterminer les Jobs To Be Done de mes utilisateurs sur un projet data

L’apprentissage de cette théorie appliquée à un projet data-driven est que pour s’assurer de l’adoption utilisateur, la donnée mise à disposition doit parfaitement s’inscrire dans son contexte d’utilisation. Cette donnée doit être à la fois une solution meilleure aux alternatives existantes tout en levant les barrières à son adoption. La clef de la réussite d’un projet data-driven passe par la compréhension des “Jobs To Be Done” associés. Ainsi, il faut replacer l’utilisation de la donnée dans son utilisation métier et identifier les “Jobs To Be Done” des utilisateurs finaux de cette donnée.

Lors de la phase de cadrage d’un outil d’analyse des ventes, cette méthodologie avait permis d’identifier deux types d’utilisation : certains utilisateurs voulaient mesurer la performance de leur force de vente et d’autres voulaient prédire les prochaines tendances du marché. Bien que les deux types d’usage s’appuyaient sur la même source de donnée, un outil d’analyse des ventes classique n'aurait pas pleinement répondu aux besoins des utilisateurs.  Deux modules distincts de l’outil d’analyse des ventes ont été développés pour répondre à chacun des deux “Jobs To Be Done” et assurer une meilleure adoption par les utilisateurs.

La recherche et formalisation des “Jobs To Be Done” se résume en 3 étapes clefs :

1. Aller sur le terrain et rencontrer les utilisateurs finaux
   
   

   Une condition cruciale pour déceler les “Jobs To Be Done” des utilisateurs finaux est d’avoir un contact direct avec eux pour éviter de rester dans l’hypothétique. Dans certaines situations, il peut être utile de faire appel à un expert métier notamment lorsque le jargon technique est particulièrement fourni (notamment pour les projets en milieux industriels ou bancaires).

   L’exploration des “Jobs To Be Done” se base sur les mêmes méthodes traditionnelles d’investigation utilisateur (interview utilisateur, go & see, focus group…). En revanche, l’accent est mis majoritairement sur les expériences passées et vécues plutôt que sur une liste de souhait ou des projections hypothétiques. Les principaux risques de ne pas se baser sur des expériences concrètes sont soit d’introduire un biais de confirmation ("Achèteriez-vous un produit qui prédit vos ventes dans 2 semaines ?”) soit de ne pas réussir à évaluer l’importance réelle du problème sous-jacent aux produits développés (“Oui, je vais souvent à la salle de sport”). Pour plus de détails sur les pièges à éviter lors de l’interview utilisateur, je vous invite à lire The Mom Test de Rob Fitzpatrick.

   Avec l’approche des “Jobs To Be Done”, l’interviewer doit se comporter tel un réalisateur de documentaire ou un enquêteur afin de faire ressortir des éléments démontrant la valeur réelle. Ainsi, les rencontres avec l’interviewé se concentrera sur les questions suivantes :

   • Quelle était la dernière fois où l’utilisateur a essayé de résoudre son problème ? Comment s’est passée précisément la tentative de résolution du problème ?
   • Quels étaient les ressorts fonctionnels, émotionnels et sociaux qui sous-tendent sa situation ?
   • Quelles alternatives ont été essayées ? Quelles sont ses petites habitudes et ses angoisses dans cette situation ?
2. Formaliser ses recherches en Storyboard
   
   

   Une fois les éléments terrains récoltés, les “Jobs To Be Done” sont formalisés sous forme de Storyboard. L’objectif est de rendre visible les différentes épreuves auxquelles l’utilisateur fait face pour atteindre son objectif, les tensions en jeu et les alternatives en compétition. Le Storyboard raconte comment un utilisateur cherche à faire des progrès vers son objectif tout en mettant en lumière les moments de tension, de trade-off, d’expériences imparfaites et de frustrations. Ainsi un Storyboard se place à l’échelle d’un utilisateur et croiser les Storyboards entre eux permet d’identifier les patterns communs.

   
   Les points de contrôle d’un bon Storyboard sont :
   
   
   • De rendre son storyboard le plus concret possible avec des photos, citations ou vidéo
   • D’éviter de tomber dans des constats généralistes et rester le plus détaillé possible
   • De mettre en lumière les habitudes et raisons pour lesquelles un utilisateur ne serait pas enclin à changer de solution
     
     

Illustration de Storyboard

03. Identifier les alternatives et comprendre les préférences clients

La dernière étape consiste à évaluer les solutions et alternatives existantes pour faire ressortir les critères de choix de l’utilisateur final. Dans le cadre de la théorie des “Jobs To be Done”, un utilisateur n’acceptera de changer de solution seulement s’il juge que la nouvelle solution répond mieux à son besoin. Pour rendre ce trade off visuel, les solutions concurrentes sont notées selon les critères de choix de l’utilisateur sous forme de radar chart. Ces radars charts serviront d’axe d’évaluation pour le produit à développer et de points de comparaison.

Dans le cadre de la donnée, les préférences clients peuvent être liées à la fiabilité de l’information, sa pertinence, sa disponibilité ou son niveau de sécurité / confidentialité. Enfin, il faut garder en tête que ne rien faire est aussi une alternative concurrente. Le coût pour atteindre l’objectif pourrait être trop élevé par rapport aux bénéfices attendus. Le problème considéré n’est peut être pas une priorité pour l’utilisateur.

Illustration d’évaluation des solutions alternatives selon 5 préférences clients

Conclusion

Pour conclure, l’enseignement principal à retenir de la théorie des “Jobs To Be Done” est qu’elle permet d’apporter une nouvelle perspective dans la compréhension de ses utilisateurs sur des projets data en mettant l’accent sur le contexte autour de l’utilisation d’un produit. Le développement de produits data ayant une véritable traction des utilisateurs finaux est un enjeu crucial pour diminuer le coût global des initiatives data driven et in fine réduire les gaspillages de temps et de ressources.

Si vous cherchez de l’aide pour la conception de vos produits data-driven, n’hésitez pas à prendre contact avec nous !

Source / Bibliographie :

"Leading companies continue to identify culture – people, process, organization, change management – as the biggest impediment to becoming data-driven organizations – 92.2%” NewVantage Partners Releases 2021 Big Data and AI Executive Survey

Competing Against Luck, Clayton Christensen

The Mom Test, Rob Fitzpatrick