Itamar Gilad (Evidence Guided) : “Les décisions produit doivent être guidées par des preuves et non des opinions”

Dans son premier livre, Evidence Guided, le consultant produit israélien Itamar Gilad plaide pour une approche scientifique du product management, grâce à son méta-framework, le modèle GIST. Objectif : mettre les preuves objectives au centre de toute décision produit. Entrevue avec cet ancien PM de Google (Google +, Gmail) basé aujourd’hui à Barcelone.

⌛ 12 minutes de lecture pour se rendre à l’évidence

 ✉️ Article issu du Ticket n°066

Les grands thèmes abordés dans l’interview :

• • La notion de Evidence Guided
  • Son expérience concrète chez Google
  • Sa critique des Roadmaps
  • Le Confidence Meter et le modèle GIST

Bonjour Itamar. Dans votre livre, vous expliquez comment devenir une organisation produit dont les décisions sont guidées par “l’évidence”, autrement dit par des faisceaux de preuves solides, et non par des opinions. D’où vient cette réflexion ?

Itamar Gilad : Elle renvoie directement à mon expérience de plus de 20 ans dans l’industrie en tant qu’ingénieur et Product Manager. Je dirais même de ma frustration de vivre tant de célébrations de lancement de produits… qui n’avaient pas d’impact réel ensuite. Tout cela parce que nous investissions dans de mauvaises idées.

En découvrant une nouvelle façon de concevoir des produits, chez Google, j’ai compris d’où venait le problème : trop souvent, le critère principal pour choisir ce qu’il faut construire est l’opinion des dirigeants, des équipes, des parties prenantes voire des clients.

En quoi est-ce un problème ?

I.G. : Notre cerveau est un incroyable outil pour traiter de l’information et prendre des décisions au quotidien. Sauf que déceler l’idée qui permettra d’atteindre l’objectif que l’on s’est fixé, parmi la vingtaine ou trentaine qui existent potentiellement, représente une complexité qui dépasse nos capacités !

On doit en effet tenir compte des besoins spécifiques des clients, de l’évolution constante du marché, des stratégies des concurrents, des contraintes de notre produit et de l’organisation… Humainement parlant, nous ne pouvons pas traiter autant d’inconnus, surtout dans le temps limité dont nous disposons pour faire notre roadmap. Naturellement, les décisions que nous prenons sont donc sous-optimales.

 

D’où votre concept de “Evidence guided”, le titre du livre. À savoir : prendre des décisions guidées par une accumulation de preuves tangibles.

I.G. : Exactement. Ces preuves permettent de confronter notre cerveau à la réalité. Juste en faisant des AB tests ou des tests utilisateurs, on découvre que, bien souvent, quelques changements minimes dans le produit font une grande différence tandis que la majorité des autres idées n’ont aucune influence, voire ont un impact négatif.

Mais ce je dis n’est pas nouveau : la médecine, le droit ou la science en règle générale reposent sur cette notion d’évidence. Votre médecin ne va pas vous établir un diagnostic sur la base de son opinion. Je ne vois donc pas pourquoi on ne fait pas de même dans le produit. Tout le livre porte sur les manières d’apporter des éléments probants dans les discussions liées aux choix de conception.

Il y a un élément rassurant raconté dans votre livre : même dans une boîte à la pointe en termes de Product Management, Google, on peut se planter en prenant des décisions basées sur les opinions !

I.G. : Je cite en effet l’exemple du réseau social Google +, lancé en 2011, auquel j’ai participé. L’histoire est intéressante car Google a une culture très ouverte, les équipes sont invitées à exprimer clairement leurs objections si elles pensent que la boîte fait fausse route. À l’époque, je me rappelle que de nombreuses personnes trouvaient que créer un nouveau réseau social n’était pas la bonne façon de concurrencer Facebook.

Mais la direction était très inquiète. Et quand vous êtes inquiet, l’aspect démocratique devient moins prioritaire. Illustration : en interne, ce projet avait pour nom de code Emerald Sea, du nom d’une peinture où l’on voit un bateau échoué face à un tsunami !

On connaît la suite de l’histoire : Google + a été fermé en 2019 et est aujourd’hui considéré comme un des plus gros échecs de l’entreprise. Est-ce que, de l’intérieur, vous sentiez qu’il y avait un problème ?

I.G. : Honnêtement, ce n’était pas évident. Les premiers signes étaient très positifs : nous l’utilisions tous en interne, les premiers utilisateurs l’adoraient et, à l’époque, jamais un réseau social n’avait connu un démarrage aussi rapide (NDLR : 90 millions d’utilisateurs après 6 mois). Avec du recul, on a reçu un mauvais signal au départ.

Je pense aussi que la direction était très influencée par le modèle de Steve Jobs, à savoir un leader visionnaire avec des opinions très fortes et beaucoup d’audace. Sauf qu’il faut relativiser l’image du cofondateur d’Apple : il était beaucoup plus ouvert aux preuves que nous le pensons généralement.

En tout cas, à cause de cette mauvaise décision stratégique, Google a raté la tendance des applications sociales, comme Whatsapp, Instagram ou Snapchat, qui auraient pu, elles, vraiment concurrencer Facebook.

Vous avez également travaillé sur un projet nettement moins prometteur à l’origine mais devenu un succès depuis : les onglets (promotions, réseaux sociaux etc.) dans la messagerie Gmail. Comment expliquer la différence de destin avec Google + ?

I.G. : C’est vraiment l’opposé. Google + découlait d’une stratégie top-down avec de gros moyens en face pour réussir absolument. Dans le cas des onglets de Gmail, c’est parti d’une idée bottom-up à laquelle personne ne croyait, même mes collègues. Cependant, ils ont été assez ouverts pour accepter que l’on s’intéresse à l’enjeu de l’accroissement de l’engagement sur Gmail, qui était l’outcome visé à l’origine par ce projet.

En analysant le problème, on s’est rapidement rendu compte que les utilisateurs recevaient beaucoup trop de notifications de réseaux sociaux ou de promotions dans leur boîte mails. Et je pense que la clé a été de ne jamais faire confiance à notre solution ! Nous n’avons fait que la tester encore et encore… afin d’accumuler des preuves de sa pertinence.

Dans le livre, vous racontez notamment comment vous expérimentez la solution sans la développer, en triant par exemple à la main les mails des testeurs…

I.G. : Tout l’enjeu, c’est de réussir à construire et à apprendre en même temps. De cette façon, nous n’avons pas du tout eu peur quand on s’est lancé. Il y a bien sûr eu des personnes qui n’ont pas compris cette fonctionnalité car elles géraient déjà très bien leur messagerie. Mais nous le savions car nous l’avions testé !

On avait constaté en effet que 15 % des utilisateurs, les gens très à l’aise techniquement, n’avaient pas besoin de cette boîte de réception. D’ailleurs, beaucoup de mes collègues en faisaient partie. Malheureusement, la presse tech également ! Toutefois, pour 85 % de la population, c’était super utile.

Au départ, les onglets n’existaient que sur la version ordinateur de Gmail. Généralement, pour déployer une fonctionnalité sur mobile, qui correspond à un autre département chez Google, il faut faire de nombreuses présentations. Or, là, j’ai juste eu à montrer les preuves qu’on avait accumulées et les équipes ont été convaincues très facilement.

Pour moi, c’est vraiment une façon plus saine de construire un projet. Tu commences petit, tu restes sceptique et, au fur et à mesure que tu collectes des preuves, tu deviens de plus en plus ambitieux.

Intéressant de voir que, dans la même entreprise, on peut parfois être guidé par des opinions et parfois par l’évidence, pour reprendre votre distinction. Ce n’est pas noir ou blanc. Un constat porteur d’espoir pour les lectrices ou lecteurs…

I.G. : Bonne observation en effet. Dans toutes les entreprises, il y a des subdivisions avec différentes façons de travailler selon les équipes ou les produits. Certaines très traditionnelles, d’autres plus modernes. Et ce n’est pas qu’une question de taille : même des startups peuvent se concentrer sur les outputs et ne pas responsabiliser leurs équipes.

Revenons sur un élément que vous avez évoqué dans une précédente question : pourquoi est-ce si difficile de construire un produit et d’apprendre en même temps ? Autrement dit, de mélanger les phases de Delivery et de Discovery.

I.G. : C’est difficile parce que l’on pense que l’un doit se faire au détriment de l’autre. Or, les deux peuvent se faire en même temps. La complexité vient aussi de l’interprétation qui a été faite de l’agile. Aujourd’hui, c’est l’outil numéro 1 pour achever les tâches de production le plus rapidement possible. Mais, à la base, l’agile a été conçu pour rendre les équipes plus adaptables face aux apprentissages qu’elles font en cours de route.

Ce que nous construisons ne doit pas uniquement avoir pour objectif de livrer le plus tôt possible. Cela doit parfois aussi servir à apprendre le plus vite possible. Parfois, on bâtit un produit jetable, juste pour vérifier des hypothèses. Je pense aux tests du Wizard of Oz, de la fausse porte ou du concierge par exemple.

Je n’invente rien ici, ce sont les bases de la Product Discovery, de l’approche Lean Startup et du triptyque Build – Measure – Learn (construire, mesurer, apprendre).

Cet état d’esprit est-il la définition du “Product Management moderne”, dont vous parlez dans un épisode de podcast récent avec Lenny Rachitsky ?

I.G. : Le product management est une discipline qui a mis du temps avant d’être clairement définie. L’histoire du métier remonte aux années 1980 avec Microsoft et HP qui ont introduit ces rôles, à l’origine très proches des chefs de projet.

Les entreprises ont ensuite découvert le produit grâce à Scrum, en Europe notamment. Elles ont réalisé qu’elles avaient un poste à combler, pour aider l’équipe delivery : les Product Owners. On sait aujourd’hui que ce n’est pas la définition complète du product management, qui consiste en réalité à découvrir le produit qui va créer le maximum de valeur pour les clients (valeur livrée) et pour l’entreprise (valeur capturée).

De ce point de vue, être guidé par l’évidence est en effet un des principes sous-jacents du métier. Au même titre que le fait de placer le client au centre ou l’agilité – la vraie. Il faut en effet constamment s’adapter aux nouvelles informations qui nous parviennent.

Vous êtes critique des décisions dictées par les opinions… mais aussi des roadmaps produit. Pourquoi ? Nous qui croyions que c’était un outil classique et essentiel des Product Managers…

I.G. : C’est vrai, c’est un artefact central du product manager. On a même parfois l’impression que c’est l’objectif de notre métier ! Il y a plusieurs problèmes avec les roadmaps selon moi.

Tout d’abord, leur conception demande énormément d’effort pour un résultat incertain. On organise des séries de réunions avec des personnes très occupées pour choisir des idées pour les trois prochains mois, en fonction de la connaissance actuelle, des opinions et de la dynamique de la salle. Bien souvent, ce ne sont pas les bonnes… Le processus n’apporte donc pas beaucoup de valeur.

Ensuite, quand la roadmap est établie, l’objectif c’est… d’exécuter la roadmap ! Et non de découvrir le meilleur produit à construire. Est-ce que les choses se passent comme prévu ? Jamais. Parfois, on arrive à modifier la roadmap en cours de route, ce qui est préférable. Mais, bien souvent, on s’y accroche à tout prix, pour des raisons politiques. Au lieu d’être une direction, elle devient l’objectif.

Pourquoi est-elle aussi répandue dans les organisations alors ?

I.G. : Nous y tenons parce que nous l’avons toujours utilisé traditionnellement. Mais aussi et surtout car les parties prenantes l’adorent. Cela aide la direction financière à planifier, la direction technique à gérer les effectifs, l’équipe commerciale et marketing à vendre…

Est-ce que cela vaut la peine de mettre en place tout ce processus uniquement pour ces avantages ? Je pense qu’on peut obtenir le même résultat de manière différente.

Comment ?

 

I.G. : En optant pour une roadmap d’outcomes (= de résultats concrètement engendrés par le produit). Autrement dit, on se fixe un objectif de résolution de problème dans une période de temps limité, avec des indicateurs de réussite définis. Par exemple, accroître la sécurité ou la rétention de son produit.

Les parties prenantes gardent une visibilité tandis que les product managers peuvent se baser sur les besoins des clients, sans s’engager sur une fonctionnalité X ou Y avec des caractéristiques fixées d’emblée. S’effectue alors le travail de tests dans le but d’augmenter son niveau de confiance dans une idée.

Une fois qu’on atteint un niveau suffisant, on peut alors s’engager sur une livraison d’output (= un rendu fonctionnel). Mais ce n’est pas n’importe quel output : on a les preuves qu’il peut faire un bon candidat pour résoudre le problème initial. Ce qui fait toute la différence, c’est de s’engager sur un niveau de confiance plutôt que sur une échéance.

Vos propos nous font penser à votre fameux Confidence Meter, l’outil qui permet de mesurer la pertinence d’une idée…

I.G. : Je pense en effet qu’il faut intégrer des éléments probants dans tout ce que nous faisons. Pour éviter de tomber dans la bataille d’opinions que je décrivais précédemment, je recommande de trouver un moyen objectif d’évaluer les idées très rapidement, comme le RICE ou le ICE.

Pour rappeler les lettres de ce dernier acronyme, le I correspond à l’impact que l’idée aura sur les objectifs. Le E signifie la facilité (ease) à la réaliser. On peut aussi prendre l’inverse et parler d’effort (difficulté). On classe ces deux éléments sur une échelle de 1 à 10, où 10 est le maximum.

Les entreprises s’arrêtent souvent là alors qu’il y a un troisième élément : le C, pour la confiance. Sommes-nous sûrs du chiffre attribué pour l’impact ? L’avons-nous deviné au doigt mouillé ? Avons-nous interrogé des utilisateurs ? L’avons-nous testé lors d’un AB Test ? Plus on a de preuves, plus l’indice de confiance augmente. J’ai voulu formaliser cela à travers ce Confidence Meter.

Il commence par l’auto-conviction (0,01). Puis, l’examen de l’idée avec des collègues (0,2). Puis des preuves anecdotiques, comme “3 clients l’ont demandé” ou “mon concurrent a cette fonctionnalité” (1). Et ainsi de suite jusqu’aux tests réels qui génèrent, naturellement, la confiance la plus forte.

Ce Confidence Meter fait partie d’un modèle plus global appelé GIST (pour Goal – Ideas – Steps – Tasks). De quoi s’agit-il ?

I.G. : Pour faciliter la diffusion d’éléments probants tout au long de la conception d’un produit, j’ai en effet divisé les choses en 4 couches :

• • Les objectifs (comment savoir que nous progressons pour réaliser la mission de l’entreprise)

• • Les idées (comment transposer ces objectifs en résultats clés, grâce à des outils comme les arbres d’indicateurs ou la North Star Metric)

• • Les étapes (comment valider les hypothèses grâce notamment au framework ICE)

• • Les tâches (comment livrer ensuite)

Comment avez-vous conçu ce modèle GIST, que vous décrivez comme un méta-framework ?

 

I.G. : Quand j’ai quitté Google et que j’ai commencé à travailler comme consultant, j’ai beaucoup lu d’ouvrages constitutifs du Product Management moderne. Que cela soit des écrits sur le Design Thinking, le Lean Startup, la Product Discovery, l’Agile, le Growth Marketing… J’ai réalisé que le problème central à résoudre était à chaque fois le même : comment fait-on pour construire le bon produit dans un environnement incertain ?

Tous ces livres en la matière vous donnent des solutions. Mais, ce n’est pas pour autant que mes clients, qui les avaient lus aussi, arrivaient à les mettre en œuvre. Il manquait un modèle pratique qui rende tout cela applicable. C’est pour cela que je parle de méta-framework. 90 % des concepts évoqués dans le livre ne sont pas nouveaux mais j’en propose une vue d’ensemble combinée.

On sent en effet que vous essayez constamment de simplifier la réalité à travers des modèles applicables.

I.G. : Vous savez, je suis ingénieur de formation. Les ingénieurs aiment systématiser les choses. Dès que l’on voit un problème, on essaie de trouver un système pour le résoudre !

Comment appliquez-vous concrètement ce modèle avec vos clients ? Peut-on dissocier les couches ou est-ce que cela forme un système global à prendre dans son intégralité ?

I.G. : Honnêtement, mieux vaut y aller couche par couche. Cela m’inquiète beaucoup quand un ou une CPO veut tout mettre en œuvre en quelques trimestres. J’essaie de voir où sont les principaux problèmes de l’organisation et, en fonction, nous nous concentrons sur la couche adéquate.

 

Comment faire si on est convaincu par ce que vous dites… mais que son organisation n’est pas convenablement équipée pour collecter les données ou ne compte que des juniors, pas forcément en capacité d’opter pour cette posture stratégique du Product Manager ?

I.G. : Bonne question en effet. Si vous travaillez dans une entreprise traditionnelle qui n’est pas bien instrumentée, sans donnée, où les décisions viennent d’en haut et où l’équipe tech et produit ne doit faire que répondre aux attentes des commerciaux… ce livre est clairement trop avancé pour vous. Vous avez trop de vents contraires pour appliquer les idées évoquées.

Mais, dans la réalité, ce type de cas extrême est de plus en plus rare. La majorité des organisations ont un système basique de données en place, commencent à faire des entrevues clients et ont adopté l’agile. J’espère que ce livre donnera des idées à leurs salariés pour aller plus loin. D’où l’intérêt d’y aller couche par couche grâce au modèle GIST. Aucune entreprise ne change du tout au tout du jour au lendemain.

Pour les lecteurs ou lectrices très juniors, il s’agit en effet plus d’un livre éducatif sur comment les choses peuvent fonctionner dans l’idéal. Mais dans les faits, vous avez raison, il est nettement plus applicable pour des PM avec une certaine expérience voire des responsabilités.

 

Finissons par une question plus personnelle. Vous avez mis 5 ans à écrire ce livre. Pourquoi cet exercice a-t-il été si compliqué ?

I.G. : Tout simplement parce que je suis un très mauvais étudiant, qui n’applique pas les conseils que je prodigue ! (rires)

J’ai voulu rédiger un document magnifique avant de le partager à quelques lecteurs puis de le publier. Sauf que cela ne marche jamais comme ça dans la vie, j’aurais dû trouver des moyens de tester le livre bien plus tôt. Par ailleurs, j’ai réalisé que j’étais beaucoup trop théorique au début. Je m’étais en effet uniquement concentré sur le modèle GIST. Les premiers retours des lecteurs tests étaient plutôt tièdes.

Je me rappelle encore du retour que m’a fait Marty Cagan : “Ne te concentre pas sur un stupide acronyme !“ J’ai donc pivoté et c’est là où je suis arrivé au fil rouge de la notion d”Evidence guided”.