Un mois avant sa venue à Paris, pour participer à la Conf’ School of Product, dont Le Ticket est partenaire média, l’illustre Jeff Patton nous a accordé une longue entrevue. Outcomes, outputs, impact, product mindset… On abuse un peu sur les anglicismes mais ce grand pédagogue nous rend tout ça limpide malgré tout.
Avec ses petites lunettes rondes, sa décontraction naturelle et son sens de la pédagogie, Jeff Patton est un peu le Professeur Product qu’on aurait tous et toutes aimé avoir. L’auteur de User Story Mapping, concept qu’il a contribué à populariser, est de passage sur Paris en septembre.
Le mardi 21, en tant que conférencier vedette de la Conf’ School of Product (d’ailleurs, 50 € de réduc’ avec le code promo LE-TICKET lors de votre inscription. En toute transparence : on ne touche aucune com’ ici. On trouve juste l’événement super cool ! Non mais regardez la prog’ !)
Et les 22 et 23, rebelote avec une formation sur le product leadership dans les locaux de l’agence BENEXT (là, on n’a pas de réduc’, désolé).
En attendant, le célèbre coach aux fameux dessins en direct lors de ses interventions est dans Le Ticket pour nous parler output, outcome et impact. Des notions certes très en vogue en ce moment. Mais dont la remise en contexte ne fait pas de mal en cette rentrée. Surtout de manière aussi pédagogique.
Avant de commencer à parler produit, est-ce que tu pourrais un peu rappeler ton parcours pour les personnes qui ne te connaîtraient pas ?
Jeff Patton : En fait, une des raisons pour lesquelles on pourrait me connaître, c’est que je suis vieux et que je fais ce métier depuis très longtemps ! (rire)
J’ai commencé à travailler en informatique sur le tard. Je devais avoir 29 ans. À l’époque, personne n’utilisait le terme de Product Manager (PM) ni ne savait ce que c’était. Mais, c’était un peu ce que je faisais : j’étais responsable d’une équipe, je parlais à des consommateurs, je prenais des décisions sur ce que l’on concevait… Je travaillais dans une petite boîte de logiciels pour les commerçants qui est devenue Salesforce Commerce Cloud.
Puis, j’ai bossé dans une startup de San Francisco qui commençait tout juste à travailler en eXtreme Programming (une méthode agile, comme Scrum, aussi appelée simplement XP), avant l’arrivée du terme et du manifeste agile, en 2001. Mon rôle était “XP customer”, qui est un peu l’équivalent du Product Owner en Scrum. Mais sur ma carte d’affaires, il était écrit “Product Manager”. C’était la première fois que j’avais officiellement ce titre.
Puis je suis devenu consultant et je me suis fait rapidement connaître en étant un des premiers à créer des ponts entre le développement agile, l’expérience utilisateur et le product thinking.
Au final, je ne pense pas que j’étais un PM incroyable. Mais j’ai cette capacité à expliquer simplement comment les disciplines fonctionnent ensemble et créer du lien entre elles.
Tu es aussi l’auteur du livre, et du concept par la même occasion, de User Story Mapping. Une référence dans l’univers du product management.
J.P. : Le story mapping n’est pas vraiment une invention. C’est une pratique courante pour visualiser les comportements des utilisateurs d’un produit. Pour celles et ceux qui ne savent pas ce que c’est, il s’agit de décrire sur une frise temporelle comment les utilisateurs interagissent avec votre produit du début à la fin, avec une carte pour chacune de leurs actions.
J’ai travaillé tant d’années dans le produit que c’est ce que je faisais couramment. On appelait plutôt ça d’ailleurs de l’analyse de tâches à l’époque, dans les processus design. En développement agile, où l’on a un backlog avec des user stories, j’ai toujours trouvé que cette méthode était une façon d’ouvrir facilement des discussions au sein de l’équipe et de visualiser ce que nous pourrions construire pour améliorer le produit.
Je n’avais pas vraiment de nom pour cette pratique. Et, en 2008, j’ai présenté le concept à un ami en lui expliquant que c’était une histoire (story) organisée sous la forme d’une carte (map). Une carte d’histoires en somme. Et il m’a dit : “Mais pourquoi tu ne l’appelles pas comme ça : Story mapping ?” Et ça a décollé ! Voilà tout simplement l’origine…
Après, il y a plein de modèles qui fonctionnent un peu de la même manière avec des noms différents. Sachant aussi que le nom n’est pas nouveau non plus. Pour écrire une pièce de théâtre ou un roman, c’est commun de structurer l’histoire de cette façon, en faisant du story mapping.
OK, si tu n’es pas l’inventeur du concept au sens strict du terme, tu es quand même celui qui l’a grandement popularisé. De ce point de vue, est-ce que tu en vois des mauvaises mises en pratique chez les PM que tu coaches ?
J.P. : La plus grosse erreur que je vois, c’est quand des personnes l’utilisent en tant qu’outil pour décomposer des fonctionnalités. Alors que cela doit décrire le parcours d’un utilisateur, ce qu’il fait dans votre produit.
Un des grands principes que j’enseigne : dans vos cartes, il doit toujours y avoir des phrases courtes et un verbe qui décrit ce que les utilisateurs font. Mais pas des noms. J’en vois qui écrivent sur leur première carte “Homepage”. Mais ce n’est pas un verbe, personne ne “homepage” ! Ils arrivent sur un site, CHERCHENT quelque chose, LISENT des informations etc.
Un des grands sujets que tu abordes dans tes différentes interventions, c’est la distinction entre output, outcome et impact. Peux-tu déjà nous en rappeler la différence ?
J.P. : En effet, je commence quasiment chacune de mes conférences par la définition de ces trois termes :
- Outputs : ce sont les fonctionnalités que vous faites
- Outcomes : ce sont les comportements des utilisateurs qui se produisent en fonction de ce que vous avez développé.
Pour un produit numérique, vous vous attendez à ce que les consommateurs :
- le voit
- l’essaie
- l’utilise
- continue à l’utiliser
- Et en dise des choses positives
C’est une autre façon de présenter les métriques produit que sont Acquisition, Activation, Retention et referal (= le fameux acronyme AARRR). Donc en gros, les outcomes ne sont pas ce que vous construisez mais ce que les gens font. Vous ne pouvez pas construire un outcome.
- Impact : enfin, j’utilise impact en parlant des résultats business en conséquence des outcomes. Comme, concrètement, le retour sur investissement, la part de marché, la reconnaissance de marque etc. Ce qui se passe uniquement grâce à l’usage du produit.
Pour toi, le problème est que les PM ont trop souvent des objectifs basés sur des outputs et non des outcomes. Dit autrement : qu’on donne plus des objectifs de livrables que de résultats. Pourquoi à ton avis ?
J.P. : La première raison… c’est que c’est la façon habituelle de procéder ! Généralement, on va dire aux PM : “On veut que cette fonctionnalité soit faite… Fais-la ! » D’autant que, dans beaucoup d’entreprises, on estime qu’on a réussi quand on a designé, conçu et livré la fonctionnalité à temps. Donc naturellement, les PM se calquent sur cette mesure du succès.
Je dirais que la plupart des entreprises sont bonnes pour mesurer l’impact, mais mauvaises pour mesurer les outcomes. Le problème est systémique, culturel, organisationnel… C’est une habitude et, comme toutes les habitudes, c’est difficile à changer. Et les PM ont une responsabilité dans cette histoire…
Pourquoi ?
J.P. : Parce que généralement ils / elles comprennent les outcomes à atteindre et essaient de réfléchir aux bonnes fonctionnalités à sortir, identifiées grâce au travail de discovery. Mais, ensuite, ils / elles communiquent juste des outputs aux équipes et notamment aux ingénieurs. Et il se produit une déconnexion. Ces derniers ne comprennent pas qui sont les utilisateurs. On leur dit juste quoi faire.
Et je le dis avec d’autant plus de facilité que moi-même, les dix premières années de ma carrière, c’était ce que je faisais. C’était mon job de savoir ce qu’il fallait concevoir. C’est la même chose pour les CEO, les dirigeant(e)s ou les parties prenantes business : ces personnes pensent que c’est leur job de prendre des décisions sur ce qu’il y a à développer. Je vois ce problème partout, même chez des super PM.
Comment expliques-tu cette déconnexion ?
J.P. : Parfois, c’est tout simplement parce que l’équipe ne veut pas savoir ou pense qu’elle n’a pas besoin de savoir.
L’une des caractéristiques du développement agile, c’est que ce n’est pas orienté sur les outcomes. Au début de chaque sprint, en Scrum, les équipes ont besoin de comprendre de manière suffisamment détaillée ce qu’elles vont construire pour pouvoir prédire ce qu’elles vont pouvoir développer dans les deux semaines à venir. Les outcomes sont intéressants mais pas importants de ce point de vue pour elles.
Et, à la fin du sprint, on va évaluer la qualité et la vélocité de la production par rapport à ce qui avait été annoncé au début. La discussion à propos des usages et des outcomes n’apparaît alors que comme une distraction pour beaucoup. Et donc les PM se disent qu’ils n’ont pas besoin d’en parler, comme cela ne semble pas intéresser l’équipe.
Une autre raison que je vois : quand les PM commencent à expliquer au reste de l’équipe qui sont les utilisateurs, quels sont les outcomes visés, pourquoi ils / elles ont pris ces décisions de fonctionnalités à développer… et bien cela amène des questions et des débats. Voire des remises en cause. C’est donc plus confortable de ne pas en parler.
Il y a vraiment beaucoup de raisons de ne pas faire les bonnes choses…
On nous a soufflé dans l’oreillette que tu vas présenter une nouvelle conférence à Paris, le 21 septembre prochain, autour du thème “Comment devenir une organisation centrée produit ?”. Sans tout dévoiler, est-ce que tu peux nous donner déjà quelques pistes de réflexion ?
J.P. : Pour être tout à fait honnête, à l’heure où je vous parle (NDLR : le 19 août dernier), je ne connais pas encore la réponse !
Je peux expliquer ce qu’est la mentalité produit, je peux dire, comme mon ami Marty Cagan, à quoi ressemble une organisation idéale, ce dont on doit s’inspirer, son fonctionnement… c’est ce que j’enseigne. Et ce que tout le monde me demande immédiatement après, c’est : comment on change la culture de notre entreprise pour l’orienter produit ?
J’ai travaillé avec de nombreuses boîtes qui ont réussi à changer leur mentalité interne et je me suis donné le défi, dans cette conférence, de prendre du recul et voir comment elles ont réussi. Mon intention est de donner de vraies bonnes pratiques qui ont mené à ce changement. Mais là, un mois avant la conférence, je ne connais pas encore la réponse. Je suis encore dans le processus de récolte d’informations et d’interviews. Peut-être que la conférence sera un échec complet si je n’ai pas trouvé de réponse d’ici là ! (rire)
A défaut de parler de changement organisationnel global donc, essayons d’être moins ambitieux et de nous situer au niveau individuel. Que dirais-tu à un ou une Product Manager qui est convaincu(e) de cette approche en outcomes mais qui est dans une boîte qui n’a pas cet état d’esprit ? De la quitter ?
J.P. : Je conseillerais à cette personne d’être très bonne en reframing. C’est-à-dire de bien faire comprendre à ses différents interlocuteurs le pourquoi derrière la conception de telle ou telle fonctionnalité et ce qui va être observé comme outcomes.
Quand on construit un produit, on doit se mettre d’accord sur plusieurs points avec ses parties prenantes : ce que l’on va construire, certes, mais aussi et surtout les problèmes que l’on veut résoudre pour les consommateurs voire les impacts business que cela pourra générer. Et cela prend du temps et de la confiance.
Car, quand on nous demande : pourquoi n’as-tu pas fini avec ça et pourquoi fais-tu ce truc de product discovery ? Il faut pouvoir faire comprendre par exemple que l’on pensait devoir résoudre tel problème, mais qu’en fait on s’est rendu compte que cela n’en était pas un pour les utilisateurs. Et que si nous avions construit la fonctionnalité envisagée à l’origine, cela n’aurait pas eu de bénéfice tangible. Que l’on ne veut pas aller de l’avant tant que nous n’aurons pas une plus grande confiance dans ce que nous devons vraiment concevoir. C’est un vrai travail d’éducation à avoir en permanence autant auprès de sa hiérarchie que des équipes avec qui on travaille.
Et si les gens ne l’entendent pas et continuent de demander “Quand est-ce que ce sera prêt ?”, alors là, il faut en effet envisager de changer d’entreprise…
On a beaucoup de lecteurs et lectrices au Ticket qui nous demandent des articles sur la façon de faire ses roadmaps. Dans la formation que tu donnes à Paris, les 22 et 23 septembre, il y a un passage sur les roadmaps orientées outcomes. Tu peux nous en dire un mot ?
J.P. : En effet, l’intégralité de cet atelier est orienté sur les outcomes. Pour les roadmaps, il y a une chose simple à faire : pour chaque item de la roadmap, il convient de préciser à quel outcome envisagé il correspond, pour quels types d’utilisateurs et comment on en mesure le succès. Si vous ajoutez ces infos dans votre roadmap, cela deviendra un document de stratégie et surtout quelque chose de vivant.
Car, quand votre roadmap ne contient que ce que vous envisagez de concevoir, autrement dit des outputs, votre seule mesure de succès, c’est votre production réalisée par rapport à ce qui était envisagé. Quand vous ajoutez des outcomes, là, il y a des choses concrètes à évaluer. Et si vous délivrez ce que vous aviez dit mais sans les résultats (= les outcomes) attendus, c’est là où cela devient un document vivant et itératif.
Il convient ici de bien voir la différence entre la mise en prod’ “to learn” (i.e. auprès d’un petit échantillon pour valider des hypothèses) et “to earn” (auprès de tous ses consommateurs pour récolter concrètement les fruits de son travail en termes d’impact pour l’entreprise).
Contrairement à ce que pensent certains, on ne change pas notre plan parce qu’on a changé d’idée. On change parce que les outcomes espérés n’ont pas été atteint. On passe dans une pensée de changement en continu. Cette évolution est d’ailleurs exactement la même que celle qu’ont connu nos produits si on prend un peu de recul…
C’est-à-dire ?
J.P. : Le plus grand changement dans nos métiers sur ces dernières années, c’est l’évolution des technologies sur lesquelles on travaille. Les produits sont aujourd’hui des choses vivantes. Ils changent et évoluent constamment. La différence avec les produits traditionnels, c’est qu’ils évoluent en temps réel. Une voiture, un grille-pain, une télévision, ça ne change pas en temps réel. Ce qui n’est pas le cas d’une application mobile, d’un produit numérique voire d’une TV connectée ou d’une Tesla, dans une certaine mesure.
En informatique, à l’époque, on travaillait sur des logiciels que l’on mettait sur des CD. L’utilisateur l’achetait, l’amenait chez lui et l’installait. Avec des mises à jour ponctuellement. C’était le modèle économique et la façon de faire des produits, dans les années 2000, quand le manifeste agile est sorti.
Mais le paradigme a changé. Le produit aujourd’hui est plus quelque chose auquel on s’abonne plutôt que l’on achète. Vous n’achetez plus Confluence, Jira ou Photoshop aujourd’hui, vous vous abonnez. Ce qui veut dire qu’on n’attend plus la nouvelle version d’un produit. On s’attend à ce que le produit s’adapte en permanence.
D’où l’émergence du métier de product manager et d’une nouvelle façon de travailler. Car on peut désormais mesurer les outcomes et faire des petits ajustements en temps réel. Ce qui était impossible auparavant, quand on devait installer son logiciel. D’où ce passage désormais possible à la culture des outcomes.
Très instructif cette remise en contexte de l’essor actuel des outcomes. Et est-ce que tu fais justement référence à cette culture quand tu parles de “Product thinking” (= pensée produit) ? On parle aussi beaucoup de “product mindset”…
J.P. : Ce sont des synonymes en effet et je ne sais pas quel est le meilleur terme. Mais j’ai l’impression qu’on a besoin d’un autre mot que “produit” pour dire qu’on est plus orienté sur les outcomes.
Comme il existe dans notre vie plus de produits non technologiques que technologiques, quand on parle de produit, souvent les gens vont penser à tous ces objets physiques que l’on voit mais qui n’ont pas ces caractéristiques de changement en continu. Le processus et le rythme de développement ne sont pas du tout les mêmes. Peut-être que “product mindset” est le mauvais terme…
Mais en tout cas, oui, pour moi, le product mindset, c’est être orienté outcomes. Un(e) leader qui a un product mindset, c’est une personne qui va moins se concentrer sur l’écart entre ce que les gens prévoient et ce qu’ils délivrent vraiment. Mais qui va plutôt leur donner une idée claire des outcomes qu’ils doivent atteindre et leur en laisser la responsabilité.
Quel est ton avis sur l’écosystème français et européen du product management ? On parle souvent d’un retard ou d’un manque de maturité encore par rapport aux Etats-Unis. Qu’en penses-tu ?
J.P. : Alors déjà, ce n’est pas toujours une mauvaise chose d’être en retard. Si le product management est émergent en France, c’est une bonne nouvelle : cela veut dire que vous ne ferez pas toutes les erreurs que les autres ont faites auparavant. Vous pouvez apprendre des leçons des autres. D’autant que ce qu’on apprend aujourd’hui n’a plus grand chose à voir avec ce qu’on apprenait auparavant.
Tu as quoi en tête quand tu parles d’erreurs du passé ?
J.P. : Je pense notamment au processus de design produit. Autrement dit de comprendre et évaluer le marché, puis faire beaucoup de recherche initiale puis créer le design puis faire le produit. Cela semble être la façon évidente de faire les choses mais cela prend beaucoup trop de temps dans le monde dans lequel on vit désormais.
Et il faut en finir avec la phrase : “On doit faire le bon produit”. C’était avant ça, quand on faisait un produit de masse que l’on imprimait sur CD car cela coûtait très cher à réparer si cela ne marchait pas. Ce n’est plus le cas désormais et cela a pris beaucoup de temps pour les PM et la communauté design à reconnaître que ce processus n’est plus le bon aujourd’hui. Le concept de discovery en continu est un concept contemporain clé pour les PM.
Et pour répondre à votre question précédente, je dirais que la différence culturelle majeure concerne le rôle des PM dans l’organisation. On retrouve encore des managers traditionnels qui disent quoi faire à leurs équipes et ces dernières prennent leurs managers et leurs parties prenantes comme leur premier client. Ils pensent que leur job, c’est de satisfaire leur manager. C’est une posture de respect par rapport au leadership et à la séniorité mais c’est clairement un échec de la pensée produit.
Il y a certaines cultures où ce respect est plus fort que d’autres. Je ne sais pas ce qu’il en est en France. Je n’ai pas vraiment l’impression que les Français soient particulièrement attachés à constamment suivre les règles et ce qu’on leur dit de faire…
Une dernière question qui n’a rien à voir. L’une des grandes caractéristiques de tes conférences, ce sont tes dessins réalisés en direct projetés sur un écran. D’où est-ce que cela vient ?
J.P. : C’est vrai que je fais tout le temps des dessins en direct, même durant mes cours (il décroche les dessins de ses derniers cours derrière lui en disant cela). En fait, il y a plusieurs années, j’enseignais comment faire des interfaces design et notamment des prototypes sur papier. Et quand vous êtes devant une grande salle, la quarantaine de personnes présentes ne peuvent pas voir vos mains. C’est la raison pour laquelle j’ai commencé à utiliser une caméra, posée sur ma table, pour leur montrer ce que je faisais en direct. Un peu de la même façon que l’on travaille avec un paperboard.
Et je me rappelle d’une conférence où je n’avais pas eu le temps de faire mes slides. J’avais donc dessiné en direct tout du long. Et les gens ont commencé à me dire : “Jeff, on déteste tes slides, pourquoi tu ne fais pas ça tout le temps plutôt !” Donc en fait je dessine parce que mes slides sont pourries ! (rire)
Il faut savoir que j’ai abandonné mes études d’art. Au début, je voulais être illustrateur. Mais j’ai très vite compris que cela nécessitait beaucoup de travail pour devenir artiste et que j’étais trop fainéant pour y arriver. Je suis donc un artiste raté… mais heureusement, j’ai d’autres compétences. Notamment celle de rendre simples des idées complexes.
Comment ?! Vous n’êtes pas encore abonné(e) au Ticket ?
Corrigeons tout de suite cela 👇
