Comment passer de ses premiers clients au Product Market Fit ?
Compte-rendu du webinar du 15/05/2020 sur le sujet "Comment passer de ses premiers clients au Product Market Fit ?"
A travers la publication de 4 articles, nous partageons notre expérience et notre vision du Data Product Management. Dans ce deuxième article, nous expliquons pourquoi il est important d’intégrer du Product Management en Data Science, puis nous détaillerons comment le faire. Enfin, dans une dernière partie, nous nous intéresserons à l’agilité adaptée au développement de produits data.
La majorité des entreprises a conscience aujourd’hui du potentiel énorme des produits data. Malheureusement, leurs équipes se lancent souvent dans des développements ambitieux qui s’étalent dans le temps (plusieurs années parfois) et qui avancent de manière déconnectée du métier et de ses utilisateurs finaux. Cela mène alors soit à l’abandon du produit, soit à la mise en production d’un produit data inutilisable, en décalage avec le besoin, qui a coûté beaucoup d’argent et qui décrédibilise totalement l’utilisation de la donnée.
Voici quelques chiffres pour illustrer nos propos :
Les produits data ont donc tendance à échouer. Mais pourquoi ?
A travers nos missions, les Hubvisors ont identifié cette liste non exhaustive d’explications :
Raisons pour lesquels les projets Data échouent__Source:
C’est pour résoudre une partie de ces problèmes qu’entre en jeu le Product Management, et plus exactement le Data Product Management : une manière adaptée d’appliquer les méthodes du Product Management pour proposer et livrer des produits data utiles, performants, appréciés, et recommandés.
Le Data Product Management est une approche conçue pour faire face aux enjeux d’incertitude de la recherche tout en garantissant un time to market optimisé qui répond aux exigences de production. L’objectif est d’apporter un maximum de valeur aux utilisateurs finaux qui vont utiliser, parfois sans le savoir, le produit data développé.
_Cycle du Data Product Management_Source : Hubvisory
Le Data Product Management bénéficie à tous :
_Processus Data Product Management_Source : Hubvisory
Dans le schéma 2 ci-dessus, on aborde ici la phase 1: Imaginer un produit.
Lancer le développement d’un produit data sans une phase de réflexion et d’étude mène souvent à du gaspillage de ressources, de compétences et de temps.
Pour ce faire, voici quelques pistes pour vous permettre d’explorer une nouvelle idée de produit data. A la fin de ce travail, vous aurez toutes les informations vous permettant de lancer ou non le développement d’un tel produit.
1.Formulation de la problématique utilisateur : sous forme d’ateliers métier pour bien saisir leur besoin, premiers échanges avec des profils tech data, formalisation de canvas fonctionnels et techniques (adaptés aux produits data et qui, comme tout canvas classiques, évolueront tout au long du cycle de vie du produit data).
L’objectif est de vérifier que le produit data en question répond à une réelle problématique, de préciser les utilisateurs finaux, les solutions envisagées, les KPIs, les risques …
Louis Dorard, ingénieur chez Dataiku, propose le Machine Learning Canvas, inspiré du Lean Canvas qu’on utilise beaucoup en Product Management. Ce canvas permet de faire le lien entre le Machine Learning et un cas d’usage, un besoin utilisateur:
Par exemple, nous avons mené une mission au sein d’un Data Lab où l’idée était de développer rapidement des Proof Of Concept pour tester la valeur de différentes idées de produits data. Nous nous sommes appuyés sur le Machine Learning Canvas pour décrire chaque POC et les prioriser les uns par rapport aux autres.
2.Recherche utilisateur : sa réalisation permet de vérifier les hypothèses métier, de recueillir les éléments utiles au développement du produit (règles métiers, gouvernance, délais…). S’appliquent alors les méthodes classiques de User Research (voir paragraphe suivant “Ecouter”).
3.Wireframing & prototypage : quand cela est possible, c’est un excellent moyen de collecter du feedback utilisateurs. Cela se fait plus facilement pour les produits de Data Decision qui prennent la forme de visualisation mais l’exercice est aussi intéressant, certes moins évident, pour les produits Data Science car cela permet de projeter l’utilisateur.
4.Analyse des données : une première analyse aide à dérisquer la faisabilité technique du produit en vérifiant les données (sa disponibilité, son accessibilité, sa qualité, sa quantité pour répondre au besoin) et à s’informer afin de permettre dès à présent des choix stratégiques dans la conception du produit.
📚 Lire notre article sur la vision produit.
📚 Lire notre article sur le wireframing
_Machine Learning Canvas_Source :
📚 Pour aller plus loin
Lors de ces étapes préliminaires, établissez une définition du succès de votre produit centrée sur vos utilisateurs : pourquoi votre produit data va-t-il rendre plus heureux vos utilisateurs ? plus engagés, plus satisfaits ? A tel point qu’ils iront recommander votre produit. Anticipez aussi les effets secondaires : quel impact une prédiction erronée (un faux positif par exemple) va-t-elle avoir sur votre utilisateur ?
Prenons l’exemple de Google Flights qui recommande le meilleur moment pour acheter ses billets d'avion. La définition du succès de ce produit data est le fait d’acheter au bon moment au bon prix. Un effet secondaire d’un faux positif, par exemple avoir prédit qu’un prix n’allait pas augmenter alors que finalement c’est le cas, peut avoir un impact non négligeable sur la vie d’un utilisateur et donc sa satisfaction (par exemple : annulation d’un projet de voyage, de retrouvailles avec des proches …). Identifié, on peut alors déjà prévoir et réfléchir à une solution pour éviter ou minimiser ces situations : par exemple, calculer un indice de confiance des prédictions et en dessous d’un certain seuil, décider de ne pas afficher ses recommandations.
Source : Conférence Google “Designing Human centered AI products”
Une question inévitable qu’il faut également se poser : est-ce qu’une solution non-data science peut répondre au besoin identifié ? Si l’on est capable d’expliquer en quoi la data est nécessaire pour répondre de la meilleure manière à un besoin (exemple : un produit classique ne propose pas une précision suffisante et est trop complexe à maintenir au vu du nombre d’utilisateur important qui le sollicite).
Explorer, c’est prendre le risque d'abandonner le projet à chacune de ces phases et de ne pas se lancer dans le développement d’un produit mais n’est-ce pas mieux que de perdre un an et du budget sur la réalisation d’un produit qui ne sera pas utilisé ?
Explorer, c’est aussi se laisser l’opportunité de pivoter et de faire la différence !
Alors, convaincu.e.s ? Abordons maintenant l’importance d’une bonne recherche utilisateur avant tout lancement de développement d’un produit data.
Nombreuses sont les équipes data, parfaitement qualifiées et animées par la passion des mathématiques, des statistiques, de la visualisation, qui livrent des produits qui ne sont finalement pas utilisés et ne trouvent pas leur public … De plus, dans le cas des produits Machine Learning, les algorithmes qui sont conçus sont souvent directement intégrés aux applications centrales, ainsi le produit data souffre dans certains cas d’une absence d’interface utilisateur. Le Data Product Management permet alors de remettre l’utilisateur au centre pendant tout le processus de construction du produit data en échangeant avec lui et en recueillant ses feedbacks.
Mais alors comment écouter ses utilisateurs ?
En Product Management, il est important de récolter les besoins utilisateurs lors de la construction d’un produit (Discovery & Build) mais également tout au long de la vie de ce produit (Growth & Run). Mesurer les comportements des utilisateurs permet de piloter son développement.
Pour bien comprendre ses utilisateurs, coupler deux approches UX permet de limiter les erreurs d’interprétation :
Recherche utilisateur - quantitative vs qualitativeSource : Hubvisory
Elle permet de mesurer des actions d’utilisateur (Où ? Quand ? Combien ?). La data est un des éléments clés de la recherche UX, particulièrement pour cette approche :
Plus il y a de données, plus les tendances sont représentatives. Les produits data (Machine Learning surtout) pour lesquels l’interaction avec les utilisateurs est moins évidente peuvent paraître trop techniques pour avoir recours à cette approche. Mais les clics, les vues, les funnels, les algorithmes… représentent bien un comportement, un besoin utilisateur.
Voici quelques exemples d’outils pouvant être utilisés : Google Analytics, Hotjar, Mixpanel… Hotjar permet par exemple d’enregistrer une session complète d’un utilisateur.
Cette collecte neutre permet de mettre en lumière le quoi mais donne peu d’informations sur le contexte. De plus, la donnée se limite à un environnement où les utilisateurs sont connectés. Mais nombreux sont les actions, les expériences, les comportements qui ont lieu hors ligne. Il faut alors combiner l’approche quantitative avec une approche qualitative pour identifier le pourquoi.
Elle permet de comprendre les motivations de l’utilisateur (Pourquoi ? Comment ?). Produit data ou classique, la démarche reste la même et se révèle une mine d’or d’informations. Cela peut prendre la forme d’interview utilisateur, de shadowing, de focus groupe, de test utilisateur, questionnaire / demande de feedback en ligne (reviews), personas … Malheureusement, cette approche est souvent négligée voire oubliée dans le cas des produits data.
Exemple : lors d’une de nos missions data qui traitait du développement d’un produit Data Decision (Analyse) autour des performances des opérations commerciales, l’organisation d’interviews utilisateur avait lieu 1 an après le démarrage des développements des Data Scientists et Analysts. Sur 12 personnes interviewées, 10 n’utilisaient pas le produit data proposé : nous nous rendions compte que l’importance pour les utilisateurs n’était pas telle ou telle fonctionnalité (filtre, calcul complexe d’une statistique …) mais plutôt la profondeur et la fraîcheur des données disponibles. En effet, les utilisateurs souhaitaient des informations sur les performances des opérations commerciales quasi en temps réel et avec un historique de plusieurs années pour permettre la comparaison. Dans ce cas, les retours des utilisateurs ont redonné du sens en définissant une nouvelle vision produit, en comprenant mieux le métier des utilisateurs et les données dont ils ont besoin et en identifiant les fonctionnalités prioritaires.
L’itération est la meilleure façon de proposer de la valeur au produit data développé. Plutôt que de construire un modèle aux performances parfaites et de le sortir qu’une fois qu’il est “prêt”: l’idée est de proposer des releases régulières apportant des améliorations avec de la valeur. De plus, en délivrant rapidement et périodiquement, cela permet d’obtenir l’adhésion et la confiance des parties prenantes et des utilisateurs qui se renforcent au fil des livraisons.
Cela étant dit, intéressons-nous aux frameworks de gestion de projets à mettre en place lors du développement de produits data.
Dans le cas de la construction d’un produit data, il s'agit d'extraire des informations utiles à partir de données brutes et de :
📚 Lire notre article sur les produits data
Ce processus nécessite une plus grande créativité et, il faut le dire, des échecs. Cela implique un degré élevé d'incertitude et de fortes évolutions et ajustements tout au long du cycle de vie du produit. C'est la raison pour laquelle les méthodologies Agiles sont particulièrement adaptées et couronnées de succès. Elles facilitent tant l’engagement des équipes que la qualité et la régularité du delivery.
S'appuyer sur la méthodologie Scrum a été bénéfique pour les équipes data accompagnées par Hubvisory. Elle permet d’asseoir un certain nombre de repères (sprints réguliers de réalisation, management visuel, cérémonies...) qui apportent rythme et amélioration continue à l’équipe data.
Scrum divise la construction des produits en phases plus petites appelées sprints qui durent entre 1 et 4 semaines. Chaque sprint est donc timeboxé : il doit atteindre des objectifs et la réalisation de livrables ou incrément définis lors du sprint planning, réunion de lancement du sprint. Scrum s’appuie fortement sur les feedbacks utilisateurs.
📚 Lire notre article sur Scrum
📚 Lire notre article sur les sprints agiles
Quels sont les avantages et inconvénients d’une telle méthode?
👍 Pros :
Nous détaillons finalement les avantages de Scrum en général mais qui sont tout particulièrement bénéfiques à une équipe data.
🤔 Cons :
_Les différents types de User Stories_Source : Hubvisory
📚 Lire notre article sur la Definition of Done et la User Story
Oui, Scrum est une bonne solution pour la réalisation d’un produit data.
Néanmoins, il ne s’agit pas d’appliquer Scrum à la lettre comme dans une équipe classique. Le Data Product Manager doit adapter les rituels et les artefacts au cas particulier de son équipe data et de son produit. Typiquement, un Data Product Manager sera peut-être amené à modifier le template des Users Stories, à y ajouter des informations propres au domaine de la Data Science. La construction d’un cycle de vie adapté des User Stories peut également être nécessaire afin de répondre aux exigences des produits data. Le plus important est de construire un fonctionnement qui convient à son équipe (et donc construire ensemble via des ateliers par exemple), qui vous permet d’être performant et de livrer des fonctionnalités qualitatives.
Par exemple dans nos missions, nous avons en effet été confronté lors des cérémonies d’Affinage et de Poker Planning à une équipe de développement peu à l’aise à l’idée d’estimer certaines User Stories de nature exploratoire par exemple. Et l’idée n’est pas de forcer un chiffrage inexact et altérer les performances de l’équipe.
Une solution que nous avons pu tester et valider est l’utilisation de Spike à la place d’une User Story pour se laisser un laps de temps afin de “craquer” les incertitudes. Un spike, c’est une notion qui existe déjà en Agilité : il s’agit d’une activité de recherche ou d’exploration réalisée avant la création d’une User Story. L’objectif d’un Spike est de réduire le risque et les incertitudes. Ce n’est donc pas une User Story à proprement parler, et le Spike est limité dans le temps.
Avant d'intégrer à un sprint une User Story difficile à estimer :
Il est bien sûr possible de privilégier la méthodologie Kanban. Il faudra alors que l’équipe data réfléchisse à ses propres modalités, ainsi qu’aux outils et rituels nécessaires à l’accomplissement de ses objectifs.
Pour rappel, Kanban est une méthode de travail collectif basée sur la visualisation, la limitation du travail en cours, et l'amélioration incrémentale. Kanban utilise un tableau comme suivi de produit et des cartes comme tâches. Un tableau Kanban traditionnel comprend trois colonnes - Terminé, En cours et À faire. Pour un produit data, des colonnes supplémentaires peuvent être ajoutées.
Kanban présente une approche Agile, à l’image de Scrum. Néanmoins, cette méthode met davantage l'accent sur le “Work in Progress” sans la notion de sprint, ni l’application de tous les rôles et cérémonies : ce qui peut être un plus dans le développement de produits data selon les équipes.
📚 Lire notre article sur la méthode Kanban
Le Product Management peut s'adapter et est même essentiel pour les produits data : on parle de Data Product Management.
Nous vous rappelons les caractéristiques principales :
📚 Pour aller plus loin, quelques ressources :
Conférence Google “Designing Human centered AI products”
Un canvas pour explorer la valeur d’un produit data
En savoir plus sur les Spikes___
Nous croyons en un nouveau modèle de consulting où l’excellence commence par l’écoute, le partage et une vraie vision