La sortie de son livre, Continuous Discovery Habits (dont le résumé de Sarah Caruel se trouve ici), en avril dernier, était un petit événement dans le monde du produit. Teresa Torres est en effet une coach produit spécialiste de la discovery et conférencière de renom.
On a un peu galéré pour obtenir une entrevue… Mais tout vient à point à qui sait attendre 🙂 Et on est ravi de pouvoir vous faire profiter de ces précieux conseils !
Avant de commencer, un petit rappel sémantique essentiel : selon Teresa Torres, la discovery concerne toutes les activités qui servent à décider ce que l’on doit concevoir au niveau du produit. On l’oppose généralement à la delivery (oui, nous on est de l’école 100 % féminin pour ces termes) qui est le travail de conception et de création de la valeur pour les utilisateurs. Enfin, on va voir que la séparation entre ces deux phases est plus complexe que ça… Bonne découverte !
Bonjour Teresa. Tu es une grande spécialiste de la discovery.Peut-être que tu vas pouvoir nous aider à comprendre un grand paradoxe à ce sujet : tout le monde s’accorde à dire que c’est super important… mais, au final, très peu en font vraiment. On va essayer de comprendre pourquoi dans cette interview. Déjà, la première objection qu’on entend sur la discovery, c’est : j’ai pas le temps ! Est-ce justifié selon toi ?
Teresa Torres : Je pense que l’on confond la discovery que l’on fait en mode projet et la discovery en continu, dont je parle dans mon livre. Beaucoup de gens sont sensibilisés à la recherche utilisateurs issue du monde du projet. Autrement dit, où cela prend des semaines à recruter les utilisateurs, à organiser puis faire les interviews, à créer la présentation pour montrer ses résultats… Bref, où l’on se retrouve à avoir un trimestre à faire de la recherche.
Ce n’est pas ce que j’appelle faire de la discovery en continu. Qui est plus une façon de se demander : comment faire pour que les équipes qui construisent le produit soient régulièrement en interaction avec les consommateurs ? C’est beaucoup plus simple et léger. Cela peut juste être une conversation de 20 minutes une fois par semaine. Dans le livre, j’évoque notamment l’automatisation du processus de recrutement des interviews pour éviter que cette partie ne prenne trop de temps. Ou des synthèses d’interview qui tiennent sur une seule page.
On n’est donc pas dans de la recherche académique, comme on le voit à l’université. Mais plus dans les façons de créer une boucle de feedback régulière. Car, il faut bien comprendre une chose : une équipe qui bâtit un produit n’a pas la même vision de celui-ci que le consommateur. Le but de cette boucle est justement de créer les conditions pour se rendre compte de ces différences.
Dans ton livre, tu conseilles de commencer par de petites activités de discovery mais d’avoir des points de contacts, au minimum, hebdomadaires avec ses consommateurs. Peux-tu nous dire pourquoi la fréquence est plus importante que le temps passé d’après toi ?
T. T. : En fait, les équipes font parfois l’erreur de se dire : nous allons parler à 12 consommateurs dans le trimestre… mais elles ne parlent à leurs 12 consommateurs que sur les deux dernières semaines ! Comme je le disais précédemment, le problème quand on travaille sur un produit numérique, c’est qu’on en devient rapidement expert. On passe notre journée à en parler. On connaît l’ensemble des fonctionnalités disponibles, comment fonctionne l’interface, où sont situés les différents éléments, quelles sont les données nécessaires etc. Ce qui amène au développement d’un biais de connaissance.
Dès que l’on commence à développer une expertise, on oublie ce que ça fait de ne pas avoir cette expertise. Et si on ne parle pas à des consommateurs pendant des semaines, on va de plus en plus prendre des décisions influencées par ce biais de connaissance. C’est pour cela que je dis qu’il vaut mieux commencer par des premiers pas très basiques, sans grande documentation, mais de manière fréquente. Cela permet de garder constamment en tête que l’on voit son propre produit différemment de ses consommateurs.
La deuxième objection fréquente sur la discovery : c’est sans fin et on ne sait pas quand il faut passer à la delivery ! Dans ton livre, tu indiques : “Delivery et discovery ne sont pas deux phases distinctes […] Non seulement la discovery sert la delivery, mais la delivery sert aussi la discovery”. Tu peux préciser ?
T. T. : En fait, cette idée qu’il existe une phase de discovery et une phase de delivery vient encore d’un monde projet, habitué au développement en cascade. Même dans un environnement Scrum, on peut parfois continuer à faire deux semaines de discovery et deux semaines de delivery. Mais, avec un état d’esprit de discovery en continu, la discovery et la delivery ont lieu au même moment.
Dans le livre, j’évoque l’histoire d’une entreprise avec qui j’ai travaillé. Nous devions changer la façon dont la barre de recherche fonctionnait. Et pour tester nos hypothèses, nous nous sommes servis directement de l’environnement live ! Dès que tu commences à faire ça, tu vois bien que la frontière entre delivery et discovery devient plus floue. Moi, quand je travaille sur des petits batchs d’utilisateurs et que je teste la validité de mes hypothèses de manière itérative, je suis bien incapable de tracer une ligne stricte entre les deux.
Le problème, c’est que la plupart des gens ne font pas ça dans la vraie vie. Très peu d’équipes prennent le temps de valider leurs hypothèses de manière itérative. Le conseil ici, c’est de tester ses hypothèses sur une faible portion d’utilisateurs. Et, dès que tu as un signal positif, de continuer à creuser auprès d’un échantillon plus important. En procédant ainsi, tu vas te rendre compte que tu vas commencer à délivrer avant d’en avoir fini avec la discovery.
On voit aussi beaucoup d’équipes qui confient la delivery à leurs juniors alors que la discovery est plutôt le “privilège” des plus seniors. Ou des PMs qui, durant leurs entretiens d’embauche, indiquent ne pas vouloir trop faire de delivery, arguant que c’est le travail des product owners (PO). Qu’en penses-tu ?
T. T. : Pour moi, la base, c’est que les équipes qui construisent le produit font leur propre discovery. Il n’y a pas d’équipe delivery et d’équipe discovery. Cela doit se faire sans discontinuité. Il y a des tonnes de décisions à prendre tous les jours en delivery. Il faut donc s’assurer que les équipes qui construisent le produit soient impliquées dans la discovery pour qu’elles puissent avoir tout le contexte nécessaire.
Ce qu’il est possible de faire ici, c’est de donner aux équipes juniors un spectre de discovery moins vaste. Par exemple, de leur confier des problématiques d’optimisation sur une plus petite partie du produit. Pour que cela soit moins risqué. Ce qui va leur donner l’opportunité d’apprendre et de comprendre ce qu’est une bonne delivery et une bonne discovery. Au moins, ils font le même travail qu’une équipe senior et ils apprennent en faisant. Et plus ils gagnent en maturité, plus on peut élargir leur champ d’action.
Car, le problème avec les équipes discovery et delivery, c’est que tout le monde n’apprend qu’un seul métier. Et que l’expérience précédente n’aide pas à passer au niveau suivant.
En effet, on voulait aborder cette question des compétences avec toi. Lors d’une précédente édition (NDLR : sur les impact teams, si tu te rappelles), un CPO nous disait que tout le monde au produit veut faire de la discovery mais que, dans les faits, seulement un petit nombre sait vraiment en faire. Tu perçois aussi cet enjeu de montée en compétences au sein des équipes que tu coaches ?
T. T. : Oui, et je vois deux choses ici. La première, c’est que beaucoup de PM attendent la permission de faire de la discovery. Ils attendent qu’on leur dise : “Go, tu as le temps, prends un jour par semaine pour en faire”. Mais ça n’arrive jamais en vrai ! Les équipes produit doivent donc spontanément prendre l’initiative de commencer à faire leur propre discovery.
La deuxième, c’est que, nécessairement, quand on fait un nouveau métier, on a besoin d’apprendre de nouvelles compétences. Si, historiquement, on vous a donné une roadmap avec des fonctionnalités à livrer et que vous travaillez dans une usine à fonctionnalités, vous devez apprendre la discovery en partant quasiment de zéro. Comprendre comment on gère un outcome (= la finalité d’une fonctionnalité sur le comportement des utilisateurs) fait appel à des compétences bien différentes que d’écrire des spécifications.
En fait, beaucoup de compétences nécessaires tournent autour de la gestion de l’incertain. Avec les questions suivantes : comment on fait de bonnes interviews ? Comment on identifie des hypothèses, on teste leur validité, on définit de bons outcomes, on sélectionne des opportunités utilisateurs ? La bonne nouvelle, c’est qu’il existe des tonnes de bonnes ressources maintenant pour y arriver. Livres, formations, cours en ligne etc. (NDLR : Allez, on va être sympa et faire de la promo pour la sienne de formation… Sinon, tu as aussi une super page sur les formations produit ici).
On continue notre petit tour des objections sur la discovery avec le fameux : “Pas besoin de perdre du temps à en faire, on sait exactement ce qu’on a à faire.” Autrement dit : doit-on tout le temps faire de la discovery ou parfois, peut-on s’en passer, quand on doit délivrer rapidement et que la roadmap est claire ? Comme pour des startups qui viennent de trouver leur adéquation au marché par exemple.
T. T. : Quand une équipe dit cela, j’entends deux erreurs. La première, c’est que cela sous-entend qu’elle ne va pas s’intéresser pas à l’impact que vont avoir ses fonctionnalités. Et, la deuxième, qu’elle ne va donc pas mesurer l’écart entre l’impact attendu de ces dernières et la réalité. Pour 100 % des équipes, il y a en effet un écart entre ce à quoi elles s’attendent d’une fonctionnalité et ce qui arrive en réalité. La discovery est intimement liée à la notion d’impact.
Après, ça ne veut pas dire que chaque chose que l’on fait nécessite le même montant d’investissement en discovery. Si on travaille sur le parcours de réinitialisation du mot de passe, pas besoin de faire des dizaines d’interviews utilisateurs. Des tests d’utilisabilité peuvent suffire. Je dirais qu’il faut investir sur les parties du produit sur lesquelles on souhaite se différencier de ses concurrents.
Donc, en résumé, je dirais qu’il est rare de ne pas avoir besoin de faire la moindre discovery. Par contre, chaque initiative ne demande pas le même niveau de discovery. Rappelons en effet pourquoi on fait de la discovery au final : pour limiter le risque. Chaque initiative ne revêt pas le même niveau de risque.
Parlons maintenant des personnes qui s’occupent de la discovery. Dans ton livre, tu mentionnes le trio produit, à savoir Product Manager, Product Designer et Lead Engineer. En France, c’est plutôt commun pour les deux premiers rôles. Par contre, pour les ingés… nettement moins. Pourquoi c’est si important à tes yeux de les avoir aussi dans le processus ?
T. T. : Rappelons déjà que beaucoup d’entreprises travaillent encore sur un modèle d’équipe IT où les ingénieurs sont un centre de coût. Ce sont des exécutants et on veut qu’ils (ou elles) construisent ce qu’on leur demande de construire, le plus rapidement possible. C’est-à-dire, pour que cela coûte le moins cher possible. Le problème ici, c’est qu’on travaille dans une industrie si complexe que les parties-prenantes business n’arrivent que très rarement avec les meilleures solutions à développer.
Il est donc nécessaire d’impliquer ses ingénieurs car ce sont eux (et elles) qui ont l’expertise technologique et qui vont savoir précisément ce qui est possible de faire. Donc les avoir dans le trio produit va nécessairement leur permettre de mieux connaître le contexte et donc d’aboutir à de meilleures solutions. En somme, pour beaucoup, les ingénieurs sont un centre de coût et leur temps est si précieux qu’il ne faut pas qu’ils passent du temps sur la discovery. Alors qu’au contraire, s’ils ne sont pas impliqués dès la discovery, cela va prendre plus de temps à délivrer les bonnes choses. Et cela coûtera plus cher au final !
Et quid des autres rôles, comme la recherche utilisateur par exemple ?
T. T. : C’est en effet une des questions que l’on me pose le plus souvent : pourquoi n’as-tu pas inclus mon rôle dans le trio produit ? Que cela soit les UX researchers, les rédacteurs UX, les scrum masters, les chefs de projet…
Alors déjà, je tiens à rappeler que je n’ai pas inventé le concept de trio produit. Cela existe depuis longtemps. Certains l’appellent les “three amigos”, d’autres la triade. J’aime le langage simple donc je l’appelle le trio.
La plupart des entreprises ont ces trois rôles. Ce sont les rôles les plus communs dans les entreprises numériques. Mais, derrière cette idée de trio, il faut surtout voir une équipe transverse pertinente et complémentaire, dont on dispose à l’interne, qui sera impliquée dans le processus de discovery depuis le début. Le concept de trio est donc flexible et se base sur les rôles disponibles dans l’organisation.
Le principe clé à retenir ici c’est : comment permettre la collaboration d’une équipe transverse en tirant partie de toute l’expertise dont nous avons accès. Ainsi, si vous avez le luxe d’avoir une personne en recherche utilisateur, évidemment qu’il faut l’inclure !
Et qui doit participer dans l’équipe dev’ ? Tout le monde ou juste la personne responsable ?
T. T. : C’est une bonne question. Qui est généralement à la source d’une erreur : le trio fait de la discovery pendant que le reste de l’équipe est à temps plein sur la delivery. Non, ce n’est pas souhaitable car on en revient à déresponsabiliser une partie de l’équipe.
Je dirais que le trio est responsable de la discovery et fait en sorte que les autres personnes de l’équipe y soient exposées. Evidemment, cela ne veut pas dire que tout le monde est impliqué dans chaque étape de la discovery ou participe aux interviews utilisateurs. Mais il faut trouver une façon pour que chaque membre de l’équipe ait un rapport direct régulièrement avec les utilisateurs.
On peut par exemple partager des vidéos d’interviews utilisateurs ou impliquer différentes personnes dans les tests de validation d’hypothèses. J’aime bien aussi quand le trio instaure un rituel régulier pour diffuser ce qu’il se passe au niveau de la discovery au quotidien. Ce qu’ils font, ce qui les bloquent, comment ils travaillent, ce qu’ils sont en train d’apprendre…
Cela doit en effet se faire au fil de l’eau et il existe plein de super outils de communication asynchrone pour y arriver. Il n’y a plus de raison aujourd’hui pour garder le reste de l’équipe en dehors de la discovery.
Est-ce que tu as des exemples d’entreprises qui ont mis en place ces habitudes de discovery en continu ?
T. T. : J’en ai inclus certaines dans mon livre, comme Carmax par exemple. Mais je pense que c’est la mauvaise question à poser (Bim la question foireuse Le Ticket !). Ce n’est pas parce que ce sont les meilleures entreprises que tout le monde y travaille de cette façon.
Il faut plutôt se demander : qui sont les leaders produit qui veulent et font en sorte que leur équipe travaille de cette façon ? Il y a certaines entreprises que je cite dans lesquelles on retrouve en même temps des équipes qui travaillent très bien de cette manière et d’autres, plus traditionnelles, qui sont plus en mode gestion de projets en cascade.
Je conseille donc aux gens qui veulent travailler en discovery en continu de moins regarder l’entreprise que les leaders produit qui y sont. (Choose your boss, not your company, comme on dit dans le Gers).
Et pour donner quelques illustrations concrètes, qu’est-ce que ces personnes ont mis en place ?
T. T. : En pratique, une équipe qui adopte la discovery en continu fait deux choses toutes les semaines.
1. Des interviews utilisateurs
Au moins une conversation de 20 à 30 minutes par semaine. Cela peut évidemment être plus, mais une, c’est déjà bien pour commencer. Cela permet de mettre en place un processus d’apprentissage et de découverte d’opportunités en continu.
2. Des validations d’hypothèses de manière itérative
Les vérifications d’hypothèses (= assumptions testing) sont une des choses les moins bien comprises dans notre industrie. On voit encore des équipes qui font de longs tests qualitatifs en prenant plusieurs semaines pour juste collecter les résultats. En soi, ces tests sont super… mais ils ne doivent intervenir qu’en fin de processus. Ce n’est pas la meilleure façon d’apprendre car ils sont trop lents et demandent trop d’effort.
Un bonne équipe discovery peut mener une petite dizaine de tests de vérifications d’hypothèses en une semaine. Cela permet de prendre des décisions en comparant de multiples solutions.
Question personnelle : quand as-tu découvert la discovery et pourquoi avoir décidé d’en faire ton grand sujet d’expertise ?
T. T. : En fait, j’ai fait des études en informatique et interactions humaines puis en design. Je suis donc entré dans le monde professionnel en pensant que les entreprises fonctionnaient en écoutant leurs consommateurs. Et quand j’ai commencé à travailler, je me suis rendue compte que ce n’était pas le cas.
Comme c’était ma façon d’approcher les problèmes, j’ai essayé de réduire l’écart entre l’idée que l’on se fait de comment les choses fonctionnent… et comment elles fonctionnent vraiment. Puis j’ai réalisé que je ne voulais pas travailler sur ces sujets pour une seule entreprise à la fois… donc j’en suis arrivée à cette activité pour aider le plus d’équipes à être en lien constant avec leurs consommateurs.
Dans ton livre, tu expliques qu’un des 6 états d’esprit à cultiver pour adopter ces habitudes de discovery en continu, c’était d’être orienté outcomes et non output (en gros “résultat final” plutôt que “livrable”, comme l’explique Jeff Patton dans notre interview ici). Pourquoi est-ce si important à tes yeux ?
T. T. : 2020 nous a montré à quel point il vaut mieux se baser sur des outcomes ! On vit dans un mode très ambigu et incertain. Planifier n’est jamais suffisant dans un rôle complexe. Il faut au contraire se donner plus de flexibilité pour s’adapter à l’incertain.
Concrètement, au lieu de dire “il faut construire cette fonctionnalité”, il vaut mieux dire : “le monde change constamment, on ne sait pas les fonctionnalités que l’on devra construire dans 6 mois. Mais on sait l’impact que ces fonctionnalités devront avoir et voilà comment on le mesurera”.
Cela veut-il dire qu’il faut abandonner les roadmaps trimestriels ?
T. T. : J’ai écrit un article de blog justement à ce sujet. Personnellement, j’aime bien voir des opportunités (= les problèmes, les besoins et les désirs des consommateurs) dans les roadmaps et non des solutions.
Par exemple, dans ma colonne “Now”, j’indique l’opportunité et la solution sur laquelle je suis en train de travailler, peut-être avec une échéance en fonction d’où j’en suis dans la delivery. En effet, parfois, je teste des hypothèses donc je ne peux pas encore savoir si ma solution va répondre à l’opportunité identifiée.
Dans la colonne “Next”, je mets les opportunités. Peut-être des solutions à explorer mais surtout pas de date parce que je n’ai pas encore fait de vérifications d’hypothèses.
Enfin, dans la colonne “Future”, je mentionne des opportunités mais absolument pas d’idée de solution.
Ce qui est bien dans ce type de roadmap, c’est que vous avez de la clarté sur le court terme, vous savez ce qu’il va se passer dans les prochaines semaines. Moins au-delà. Ce qui reflète l’ambiguïté et l’incertitude dans lesquelles nous vivons.
On a l’impression que l’un des mots les plus importants de ton livre c’est ”habitudes”. C’est d’ailleurs, celui qui est le plus en évidence sur la couverture. Est-ce qu’on se trompe ?
T. T. : C’est très lié en effet à ce que vous disiez en début d’entrevue : beaucoup d’organisations savent qu’elles doivent faire de la discovery… mais ce n’est pas pour autant qu’elles en font !
Je pense que c’est parce qu’elles sont trop centrées sur la notion de “bonne réponse”. Alors que la discovery en continu est plutôt axée sur la gestion de l’incertain et de l’ambigu. C’est pour ça que j’ai essayé d’écrire chaque chapitre comme une habitude spécifique à avoir, pour que les équipes construisent petit à petit des fondations solides en la matière.
Ce n’est pas en se réveillant un matin que l’on décide d’un changement. Non, les changements se produisent par des habitudes que l’on construit. Et qui infusent naturellement dans les mentalités et la culture.
C’est par là que ça se passe si tu veux d’autres interviews de personnalités produit de haut niveau.
Comment ?! Vous n’êtes pas abonné(e) au Ticket ?
Corrigeons tout de suite cela 👇
