Discovery Playbook

Article co-écrit par Laure Nilles & Christopher Parola

Le Discovery, c’est la découverte : l’action d’enlever ce qui couvre l’inconnu. Pour résoudre des problèmes utilisateurs et leur apporter des solutions de qualité, nous pensons qu’il faut plonger la tête la première dans cet inconnu : pourquoi ? Comment ?

Ces dernières années, nous avons souvent eu l’impression de répondre aux mêmes questions sur ce sujet : quelles sont vos méthodes de Discovery ? Quels sont vos outils ? Est-ce que ce n’est pas trop long ? Est-ce que c’est vraiment utile, si on connaît le marché et nos utilisateurs ?

Pour répondre à ces questions, nous avions envie de partager notre expérience et la théorisation que nous avons peaufinée au fur et à mesure des succès, des échecs, et des lectures éclairantes (Marty Cagan, Teresa Torres, merci !).

Tout d’abord : qu’est-ce que le Discovery ?

Nous définissons le Discovery comme un processus d’apprentissage conduisant au succès produit, grâce à des hypothèses préalablement posées.

Le succès produit est atteint lorsque la valeur apportée aux utilisateurs et à l’entreprise est maximisée durablement. Ce dernier terme est clef : les enseignements issus d’une phase de Discovery peuvent être remis en cause par tout changement de contexte (politique, légal, concurrentiel, ou un changement structurel de comportement des utilisateurs).

Ces apprentissages, c’est la boussole de l’équipe Produit. Ils vont nous permettre de prendre les meilleures décisions possible à tous les stades de réflexion : arbitrage sur le périmètre d’une fonctionnalité, sur la hiérarchie des composantes d’une interface, sur les messages clefs dans la communication, sur la façon de pricer et de commercialiser le produit… Grâce à eux, on va pouvoir faire en sorte que toute décision s’appuie sur des éléments issus du Discovery, et non sur une intuition. L’intuition, cette “forme de connaissance immédiate qui ne recourt pas au raisonnement” fonctionne parfois, d’autant qu’elle peut venir inconsciemment de connaissances enfouies. Mais son caractère “immédiat” et non vérifié la rend risquée, et ce risque n’est pas toujours souhaitable si les conséquences s’avèrent douloureuses pour l’entreprise (perte de CA, mauvaise satisfaction client, perte d’utilisateurs ou de données par exemple).

Le Discovery doit donc selon nous être aussi structuré que le Delivery : dans la théorie et dans la pratique de beaucoup d’entreprises aujourd’hui ce n’est pas le cas. Cela freine la mise en place de réelles pratiques de Discovery, et conduit à des équipes souhaitant “faire plus de produit, être plus autonomes” mais qui ont du mal à prouver leur capacité à utiliser cette autonomie à bon escient. L’idée n’est pas pour l’entreprise de remplacer le gut feeling de certain•e•s par celui de l’équipe Produit.

C’est pour cette raison que nous travaillons notre méthode en continu, au fil des réussites ou des échecs, pour avoir un cadre qui nous permette de nous guider tout en se laissant la place de tester toujours de nouvelles façons de faire.

Nous avons souhaité partager publiquement nos pratiques car :

• Elles s’inspirent de nombreuses méthodes et pratiques existantes, mais qui nous semblent incomplètes ou manquent de liant (par exemple, quel est le lien entre un Opportunity Tree et le Lean Startup ? Vous avez quatre heures.)
• Elles sont agnostiques du secteur d’activité et peuvent permettre à des équipes Produit de monter en compétence très rapidement sur n’importe quel sujet.

Quels bénéfices de mettre en place des pratiques de Discovery ?

1. Langage commun : souvent en matière de Discovery chaque personne peut avoir sa vision, en fonction de son expertise et de ses expériences passées, de ce que signifie “recherche utilisateur”, “cadrage”, “benchmark”… L’avantage de structurer cette méthode est d’aligner tout le monde sur les termes utilisés, facilitant la communication au sein de l’entreprise. À noter qu’il ne faut pas avoir peur de répéter un maximum de fois les définitions et méthodes employées :)
2. Moins de gâchis : un Discovery efficace permet à l’impact team de savoir ce qu’elle va développer et surtout pourquoi. Il est donc plus rare de développer des fonctionnalités qui seront ensuite jetées à la poubelle, ce qui est à la fois plus efficace et plus motivant pour tout le monde.
3. Plus de succès produits : c’est tout l’objectif ! Sans dire qu’une méthode peut être infaillible, être dans une dynamique de structuration du process et d’amélioration continue contribue à maximiser ses chances de réussite.

Comment on fait ?

Il ne s’agit pas d’une liste d’outils, mais bien d’une méthode dans laquelle :

1. on s’interroge toujours sur le “pourquoi” avant le “comment”,
2. on identifie tous les risques qui seraient un obstacle au succès du produit.

Nous insistons sur ce point : à chaque fois que nous voyons une conférence sur le Discovery ou que nous nous intéressons à une méthode de Discovery, la question arrive systématiquement “quels sont vos outils ?”. Et là, on entre dans une discussion passionnante mais qui ne fait pas avancer le débat “moi j’aime bien les Problem Interviews, moi je préfère les tests de concepts”.

Les outils de Discovery sont nombreux et très bien documentés. La méthode de Discovery crée un lien entre eux, et nous permet de comprendre quel outil répond à quelle partie de la méthode. Nous avons ainsi pu constituer une véritable trousse à outil du Discovery, chaque outil étant associé à une étape.

Pour citer Abraham Maslow: Si le seul outil que vous avez est un marteau, vous verrez tout problème comme un clou.

Il est donc important d’avoir une trousse à outils bien garnie et maîtrisée, mais cela n’est pas suffisant. Nous vous partagerons notre trousse à outils dans un prochain article !

Pour minimiser les risques associés à un produit, on va s’intéresser — par ordre d’importance aux :

1) Risques Utilisateur : à quel problème veut-on apporter une solution ? Est-ce un problème suffisamment important pour qu’on investisse du temps sur une solution ? Qui rencontre ce problème et quand ? Existe-t-il des alternatives ? Cette étape, trop souvent oubliée, est un préalable indispensable à toute initiative traitée par une équipe Produit (du bug signalé par un collègue, au lancement du nouveau produit phare de l’entreprise).

2) Risques Produit : face aux problèmes identifiés, a-t-on la bonne solution ? Notre proposition de valeur est-elle suffisante pour répondre au problème et nous distinguer de la concurrence ?

3) Risques Commercialisation : comment communiquer sur la solution, à qui, quand et comment ? Comment apporter cette nouveauté sur le marché ?

4) Risques Rentabilité : pour que la solution soit bénéfique à l’utilisateur et à l’entreprise, il faut qu’elle soit rentable durablement. Quel investissement représente-t-elle pour l’entreprise (temps de développement, temps de formation et de commercialisation, coûts externes…) et pour quels avantages (MRR, effet de réseau, rétention…) ?

Ces risques sont représentés dans la pyramide du Succès Produit, qui s’inspire du framework du Lean Canvas et des fours steps to the epiphany de Steve Blank :

Chaque étape dépend ainsi de la précédente : on ne peut atteindre le succès produit si on développe une solution qui ne répond pas à un vrai problème utilisateur, ou si on amène la nouveauté aux utilisateurs de la mauvaise façon ou avec le mauvais message, ou si la solution n’est pas rentable à long terme. L’objectif est d’avoir une réelle cohérence entre toutes ces étapes : les enseignements de l’étape 1 doivent ruisseler sur les autres étapes. Par exemple, la compréhension fine des besoins des utilisateurs pourra alimenter la communication du produit et de sa proposition de valeur.

Quel temps va-t-on alors passer pour minimiser tous ces types de risque ? Tout dépend de l’objectif et du niveau de connaissances qu’on a déjà sur le sujet traité. Selon l’objectif à atteindre, il faut établir ce qu’on sait déjà, et poser des hypothèses sur le reste. Une fois les hypothèses posées, on va ensuite réfléchir aux façons de les vérifier.

Il est également important de noter un risque majeur au moment de la mise en œuvre du Discovery : vouloir en faire sur tous les sujets, à tout moment. Nous l’avons déjà évoqué dans un précédent article, nous croyons que la maîtrise des risques est un des éléments clés du Product Management. On peut délibérément décider de sauter le Discovery, ou une étape du Discovery. On peut par exemple manquer de temps pour faire le Discovery et démarrer directement la conception et le développement de la solution. Il faut être à l’aise avec cette situation, sachant que le fait d’avoir une méthode de Discovery claire permettra d’identifier les risques (“Attention, on n’est même pas sûr du besoin !”) et de comprendre le paris qui est pris (“On ne connaît pas le besoin, on sait qu’on a un fort risque de produire une solution qui ne répond à aucun problème, mais on assume ce risque et investit tout de même dans le développement”).

Pour conclure cette article de présentation : avoir cette pratique commune nécessite une construction itérative et collaborative, beaucoup de formation et une volonté farouche de découvrir et de progresser au sein de l’équipe Produit. Nous détaillerons les étapes de la méthode ainsi que ses conditions d’application dans d’autres articles à venir !