Ramon Guiu

Donc, j'ai été invité, je suis très heureux d'être ici. On m'a invité à partager mon expérience. Je ne suis pas un expert ou quoi que ce soit, il se trouve simplement que je me suis retrouvé dans une position au sein d'une entreprise où nous sommes passés de la méthode Waterfall à Agile. C'était du Scrum, pas du Kanban. Et je veux simplement partager notre expérience alors que nous avons itéré tout au long du processus et que nous avons, vous savez, essayé différentes choses. Et je veux partager ce qui a fonctionné, ce qui n'a pas fonctionné, et j'espère que c'est quelque chose que vous pourrez emporter avec vous et voir si cela peut s'appliquer à votre environnement spécifique. Encore une fois, chaque environnement est différent, donc vous devrez voir.
Alors, juste avant de commencer, combien de personnes ici sont propriétaires de produits ou gestionnaires de produits ?
D'accord, et parmi ceux qui ont levé la main, combien le font pour des produits commerciaux ou des produits que vous offrez en dehors de l'organisation ?
D'accord, comme je l'ai dit, seulement quelques-uns. D'accord.
Bien. Avant de commencer, il m'a été utile de retracer l'histoire de la gestion de produit pour comprendre comment nous en sommes arrivés là où j'étais au début et comment nous avons traversé ce processus. Ainsi, la gestion moderne de produit peut être retracée jusqu'en 1931. Il s'agissait d'un gentleman nommé Nate McElroy. Il travaillait chez Procter & Gamble, une grande organisation de biens de consommation à rotation rapide. Et à l'époque, le marketing était généralement organisé. Il n'y avait pas de gestion de produit. Il y avait une fonction marketing centralisée qui gérait tous les produits de l'organisation. Et ce monsieur a écrit un mémo dans lequel il a défini le concept d'hommes de marque. Et ceux-ci étaient des personnes entièrement responsables, ayant la pleine propriété d'une marque spécifique au sein de Procter & Gamble. Et ils étaient chargés des ventes, du produit, de la tarification, etc. Et la chose la plus importante qu'il a dite est que pour être efficaces dans leur travail, ils devaient le faire par des tests continus et en étant très proches du client, en interagissant beaucoup avec les clients, ce qui n'était pas le cas à l'époque. C'était donc assez révolutionnaire. Et à l'époque, la façon dont ils procédaient était...
par l'utilisation du mix marketing traditionnel. Il s'agissait d'avoir le bon produit au bon prix, au bon endroit, et avec la bonne promotion.
Donc les choses, vous savez, l'histoire continue. Et, chose intéressante, M. McElroy était conseiller à Stanford. Et à Stanford, il y avait deux gars appelés Bill Hewlett et Dave Packard, qui étaient entrepreneurs et ont été influencés par sa pensée autour des hommes de marque, vous savez. Et ils ont pris cela et l'ont interprété comme la nécessité de placer la prise de décision pour la gestion de produit, le développement de produit, très près du client. Et alors, le gestionnaire de produit était la voix du client au sein de l'organisation. Et en fait, c'est cette politique, il existe un livre sur l'histoire de Hewlett-Packard, et dans ce livre, ils attribuent le fait qu'ils aient eu 50 ans de croissance consécutive, année après année, une croissance de 20%. Ils attribuent cela à cette politique spécifique, être très proche du client lors de la conception du produit. Lorsque la fabrication juste-à-temps est arrivée en Occident, Hewlett-Packard a été l'une des premières entreprises à l'adopter. Et, vous savez, comme vous pouvez l'imaginer, Hewlett-Packard grandissait, et il y avait beaucoup de gens, vous savez, qui y travaillaient, ont quitté leurs emplois, ont rejoint d'autres entreprises, sont partis et ont créé leurs propres entreprises. Et donc cette culture d'être très centré sur le client, verticale par marque, et allégée. La fabrication, vous savez, s'est transmise dans tout l'écosystème de la Silicon Valley, et de là, elle s'est répandue dans le monde entier.
Maintenant, si vous y pensez, et que nous revenons aux biens de consommation à rotation rapide, construire et commercialiser du savon n'est pas la même chose que construire des logiciels ou des produits technologiques en général, mais en particulier des logiciels. Donc pour le savon, comme je l'ai dit, vous savez, les biens de consommation à rotation rapide, parce que le développement du produit est, vous savez, lent, vous ne pouvez pas, vous savez, vous devez imaginer, vous savez, vous devez développer un dentifrice ou vous devez faire les tests, et ensuite vous devez avoir les installations de fabrication où vous pouvez le faire. Vous devez augmenter la production. Vous devez commercialiser, mettre le produit, vous savez, trouver les canaux, mettre ce produit dans les magasins. C'est un processus très lent. Vous ne pouvez pas... Si vous êtes un gestionnaire de produit, vous passez la plupart de votre temps non pas sur le produit lui-même, mais vous vous concentriez davantage sur les trois derniers P du mix marketing. Donc, c'est le prix, la promotion et le placement. Maintenant, pour les logiciels, c'est très différent. Vous devez imaginer, vous savez, Aujourd'hui encore, les logiciels transforment complètement les industries, en inventant de nouvelles industries. Et le développement du produit est très lié à la commercialisation, aux besoins des utilisateurs. Donc ce changement a...
beaucoup influencé le développement de produit, à nouveau, dans le rôle de la gestion de produit. C'est donc, encore une fois, un grand changement en termes de fonctionnement de la gestion de produit.
Et non seulement cela, donc parce que tout ce que j'expliquais sur le processus de développement d'un produit étant lent et nécessitant d'énormes investissements initiaux pour les installations et l'augmentation de la production, etc., ils utilisaient un processus de gestion de projet en cascade parce qu'ils devaient tout planifier à l'avance. Vous savez, on ne peut pas, d'accord, construisons une nouvelle installation de fabrication et testons-la. Vous savez, il nous faut un an pour construire, testons-la. Ça n'a pas marché, d'accord, maintenant nous allons itérer et la changer. C'était trop cher à faire, n'est-ce pas. Donc encore une fois, les problèmes typiques, vous savez, avec le processus en cascade, la validation arrive trop tard dans le processus. Le fait que le changement soit coûteux et perturbateur. En fait, la méthode en cascade fonctionne bien quand on ne veut faire aucun changement du tout. On veut tout planifier à l'avance. Et puis, vous savez, c'est une réponse lente aux changements du marché. D'accord, rien de nouveau ici. Alors est venue la révolution, n'est-ce pas ? Et pas celle-ci, mais celle-là. Donc Internet, vous savez, la fin des années 1990, a apporté une manière complètement nouvelle de livrer des logiciels. Et c'est, vous savez, lorsque les fournisseurs de services d'applications sont nés. C'est comme ça qu'on les appelait à l'époque. Aujourd'hui, vous pouvez penser aux entreprises de logiciels en tant que service, ce qui est une sorte d'évolution naturelle alors que nous sommes passés à ce, vous savez, donc... modèle économique. modèle économique. Mais cela a complètement changé l'écosystème, le paysage, car maintenant vous pouviez mettre un produit sur le marché, obtenir des retours des clients immédiatement, donc vous n'aviez pas besoin de le distribuer. Je le mets simplement en ligne, tout le monde peut y accéder. Je peux obtenir des retours. Et si je dois mettre à jour, je peux le faire très rapidement. Donc les risques de faire une erreur sont beaucoup plus faibles, car si une erreur est commise, je peux la corriger très rapidement.
Donc les personnes qui essayaient d'utiliser la méthode Waterfall avec ce nouveau modèle avaient du mal. Ça ne marche pas. Waterfall est pour un processus très prévisible, un processus plus long, beaucoup de prévisibilité. Je ne veux pas prendre de risques. Je veux être sûr que tout ce que je publie, ça va être stable, ça va marcher, etc. Mais avec Internet et avec le rythme auquel la technologie se développait, ce n'était définitivement pas une bonne chose.
Et c'est à ce moment-là que les méthodologies agiles sont devenues beaucoup plus populaires. Donc les deux mouvements sont très liés. Donc ceci est juste une très brève introduction à l'histoire, telle que je la vois, de la gestion de produit et où nous en sommes, comment nous en sommes arrivés là où nous sommes aujourd'hui. Et je vais me concentrer davantage sur mon expérience particulière. Mais cela a beaucoup de points communs avec cette transition.
Donc c'est moi. Je m'appelle Ramon Guill. Je viens de Barcelone. Je travaille depuis 14 ans dans des startups, à construire des logiciels, à commercialiser des logiciels. 10 ans en particulier à diriger des produits, plus précisément des produits, parfois pas appelés gestion de produit, mais de toute façon, à diriger la définition et la stratégie du produit. J'ai été entrepreneur auparavant, et j'ai travaillé dans de nombreux rôles différents également. J'ai été en développement, en assurance qualité, en gestion de projet. Et je suis également co-organisateur de Product Tank Barcelona. Je ne sais pas si quelqu'un ici connaît Product Tank. C'est un événement qui se tient dans de nombreuses villes différentes, 80 je pense actuellement. Il y en a un à Paris. Ils ont organisé un événement début novembre. Et il s'agit de personnes comme vous qui y vont pour présenter et partager leurs expériences. Ainsi, vous pouvez tous apprendre les uns des autres. Je vous recommande de regarder. Il existe un groupe de rencontre où vous pouvez vous inscrire. À leurs événements.
Nous sommes donc de retour en 2011, et j'ai rejoint Xylem. Xylem est une entreprise qui développe un contenu, nous proposons un système de gestion de contenu pour l'apprentissage. Et nous le vendons à des organisations d'entreprise, de très grandes organisations.
Et c'est en 2011, j'ai rejoint l'entreprise, je suis le premier chef de produit à rejoindre. D'accord, donc nous étions 30 personnes à l'époque, et la gestion de produit était dirigée par les propriétaires, les fondateurs et les propriétaires de l'entreprise. Et ils ont décidé qu'ils voulaient embaucher quelqu'un à bord pour apporter plus de structure, avoir quelqu'un dédié à recueillir les retours des clients, construire un backlog, une feuille de route, et encore une fois, structurer le processus de développement du logiciel.
Et donc nous étions 30 personnes. Gardez simplement à l'esprit que je vais parler de 2011 jusqu'à aujourd'hui, vous savez, où nous en sommes et ce que nous envisageons en termes de prochaines étapes. Gardez à l'esprit que nous étions 30 personnes, et pendant cette période, surtout les quatre premières années, nous sommes passés de 30 à 120 personnes. Donc c'est aussi, nous grandissons très vite, et non seulement cela, mais nous sommes en télétravail. Je ne sais pas s'il y a beaucoup de gens ici qui travaillent à distance, mais bien sûr, c'est une expérience très différente, n'est-ce pas ?
Et aussi, vous savez, très, très difficile.
Donc si nous revenons en 2011, vous savez, et que nous pensons à Xalim à cette époque, le logiciel que nous vendons, donc nous le vendons à des organisations d'entreprise. Pensez à de très grandes organisations, très averses au risque, vous savez, celles qui prennent un risque, la sécurité, très conscientes de la sécurité. Donc le logiciel à cette époque était souvent installé sur site. Et c'était notre cas pour la plupart. La plupart de nos clients ne voulaient pas que nous hébergions les choses sur le cloud. Le cloud ? Je veux dire, c'est quoi ça ? Je veux dire, non, pas question. Donc nous étions, ils hébergeaient, nous installions le logiciel sur leurs serveurs. Pour certains d'entre eux, nous l'hébergions nous-mêmes. Mais ceux-ci étaient quelques exceptions. Nous vendons des licences perpétuelles. Donc le modèle est que nous vendions, vous savez, un gros paiement initial, puis des frais de maintenance, vous savez, 20 %, généralement des frais de maintenance, chaque année. Et le problème avec ce modèle, bien sûr, comparé au SaaS, eh bien, le bon côté est que vous recevez beaucoup d'argent dès le départ. Le problème est que chaque année, vous devez vendre beaucoup de licences si vous voulez croître. Vous savez, avec le SaaS, c'est très différent. Nous utilisions un processus en cascade. Donc quand j'ai rejoint l'entreprise, nous étions en train de terminer une nouvelle version du logiciel qui était en développement depuis six mois. J'ai rejoint en janvier. Si je me souviens bien, la version est sortie vers mai, je pense. Donc il s'est écoulé presque un an entre la dernière version et la nouvelle.
Et gardez à l'esprit que nos clients n'étaient pas nécessairement, ils étaient d'accord avec ça. Encore une fois, comme je l'ai dit, ils étaient averses au risque. Le logiciel devait être installé sur leur système. Donc, d'accord, vous installez, ça marche pour nous. Nous l'avons testé parce qu'ils l'ont testé en interne. Nous sommes satisfaits. Je veux dire, ne le touchez pas, en fait. Ils disent, non, ne le touchez pas. Je veux dire, ça marche pour nous. Nous ne voulons pas que vous le changiez. Alors pourquoi sommes-nous passés à l'Agile ? Le problème que nous avions était les ventes. C'est que pour croître dans le processus de vente, nous devions devenir beaucoup plus agiles que nos concurrents qui étaient plus établis. Et afin de convaincre les clients de signer avec nous, nous étions plus flexibles en termes de, d'accord, vous avez besoin de ceci, nous pouvons le livrer plus rapidement que nos concurrents. Gardez simplement à l'esprit que nos concurrents utilisaient tous ce processus également. Donc ils sortaient une nouvelle version tous les ans, tous les 12 mois, 18 mois. Donc ce n'était pas vraiment nos clients existants. C'était les ventes qui, vous savez, le besoin des ventes et le besoin de s'adapter plus rapidement aux besoins du marché qui ont provoqué notre transition vers l'Agile.
Voilà donc ce que je faisais quand j'ai rejoint l'entreprise. Et encore une fois, c'est plus ou moins les six à huit premiers mois. Et donc je faisais le rôle traditionnel de chef de produit. Et le rôle traditionnel de chef de produit est très large. Donc vous définissez la vision, la stratégie, et probablement que cela se matérialise dans une feuille de route, un document qui est une feuille de route. Vous travaillez sur les exigences, les spécifications. Vous vous impliquez beaucoup dans la mise sur le marché. Donc je faisais les fiches techniques. Je travaillais sur le message pour mon produit. Je guidais les mises à jour que nous devions faire sur le site web. Je faisais des webinaires. Beaucoup de choses, aussi écrire des documents pour les ventes et des présentations pour les ventes. C'est ce qu'on appelle l'habilitation des ventes, afin qu'ils puissent vendre notre produit. Beaucoup d'activités liées à la mise sur le marché, les plans de lancement, tout cela. Et puis, vous savez, se concentrer sur la rentabilité. Dans mon cas, ce n'était pas nécessairement, je veux dire, parce que le produit était essentiellement l'entreprise était le produit. Donc c'était surtout la responsabilité du PDG. Mais encore une fois, vous savez, ils voulaient s'assurer que notre produit était rentable.
Et puis... Nous sommes passés à Scrum. Nous ne sommes pas passés à Kanban. Nous sommes passés à Scrum. Donc c'est un processus. D'accord, donc maintenant nous allons introduire ce nouveau processus afin de... réagir plus rapidement, vous savez, avec des cycles de publication plus courts. Donc à la fin de chaque sprint, nous avions notre version, et nous utilisions des sprints mensuels. Donc nous publiions chaque mois, et les gens étaient heureux parce que nous pouvions réagir beaucoup plus rapidement à ce que nos, vous savez, prospects demandaient afin de pouvoir signer des contrats et cela a effectivement alimenté notre croissance. Nous avons ainsi triplé les revenus en quatre ans et, comme je l'ai dit, nous sommes également passés de 30 à 120 personnes. Mais encore une fois, ils voulaient s'assurer que notre produit était rentable.
Et puis nous sommes passés à Scrum. Nous ne sommes pas passés à Kanban. Nous sommes passés à Scrum. Donc, c'est un processus. D'accord, donc maintenant nous allons introduire ce nouveau processus afin de pouvoir réagir plus rapidement avec des cycles de release plus courts. Donc, à la fin de chaque sprint, nous avions une release, et nous utilisions des sprints mensuels. Donc, nous faisions une release chaque mois, et les gens en étaient heureux parce que nous pouvions réagir beaucoup plus rapidement à ce que nos prospects demandaient. Ainsi, nous pouvions signer des contrats, et cela a effectivement alimenté notre croissance. Donc, nous avons réussi à tripler les revenus en quatre ans, et nous avons également grandi, comme je l'ai dit, de 30 à 120 personnes.
Mais le problème, c'est que lorsque vous mettez en œuvre Scrum, vous avez le rôle du product owner. Et le rôle de product owner, nous n'avions pas de product owners. Nous avions le product manager, nous avions les leads en ingénierie qui géraient les projets en interne. Parfois, je faisais aussi de la gestion de projet pour certains des composants de notre plateforme. Mais ensuite, nous avons le product owner Scrum. Donc, vous avez le product backlog, vous devez écrire, ou peut-être quelqu'un d'autre, mais de toute façon, quelqu'un doit s'assurer que les user stories sont rédigées. Vous partagez les connaissances, la transparence sur les priorités dans le backlog, et qui, vous savez, quel est le contenu des user stories, ce qu'elles signifient, donc, vous savez, tout le monde dans l'équipe comprend de quoi il s'agit, et, idéalement, tout le monde dans l'organisation aussi. Et vous vous concentrez sur la maximisation de la valeur. Rien de nouveau ici. Mais le problème, c'est que, maintenant nous avons ces nouvelles responsabilités, et la question est de savoir comment nous mettons en œuvre Scrum, comment nous attribuons ces responsabilités au sein de l'équipe. Et ce qui s'est passé, et je pense que c'est très traditionnel, lorsque nous mettons en œuvre Agile, dans notre cas, encore une fois, avec une mentalité de startup claire, il n'y avait pas de planification. Donc, c'était surtout, d'accord, nous allons passer à Agile. Nous avions deux, trois présentations. Voici comment cela fonctionne. Il y a le backlog, il y a le sprint, et les daily stand-ups, et c'est tout. Nous tournons l'interrupteur, et nous passons à Agile. Donc, de toute façon, ce n'était pas exactement ça, mais presque. Et donc quelqu'un devait prendre les responsabilités du product owner, les responsabilités du product owner. Et traditionnellement, cela arrive souvent. Cela est donné si un product manager existe, ils disent, oh, cela correspond très bien au product manager aussi. Nous allons simplement lui donner ces tâches. C'est plus ou moins ce que le product manager fait déjà. Parfois, cette responsabilité est donnée. Elle est donnée à l'équipe d'ingénierie, peut-être un lead engineer ou autre chose.
Et c'est ce que nous avons fini par faire. Donc maintenant, nous combinons la gestion de produit et la propriété de produit. Donc, nous avons la vision et la stratégie, une feuille de route très haut niveau, etc. Le product backlog, un product backlog plus tactique et priorisé pour le prochain sprint. Les user stories ou spécifications ou exigences, appelez cela comme vous voulez, pour le développement. Partager les connaissances avec l'équipe et avec l'organisation sur ce que nous faisons, la mise sur le marché, encore une fois, vous savez, toute la commercialisation, ce qui prend aussi beaucoup de temps, vous savez, tous ces webinaires, le support aux ventes, etc., et maximiser la valeur rentabilité, d'accord ? Donc, et ce n'est pas nécessairement une mauvaise chose, car si une seule personne fait tout cela, il y a beaucoup d'alignement dans toute l'organisation sur ce que fait le produit, quel est le message que vous utilisez. Donc, je veux dire, si vous pouvez le faire efficacement, c'est super, d'accord ? Donc, c'est parfait. Donc, cela apporte, comme je l'ai dit, beaucoup d'alignement d'équipe dans toute l'organisation, et cela aide à la collaboration. Parce que si vous avez quelqu'un qui peut très bien représenter les clients au sein de l'équipe,
apporte des idées, les problèmes qu'ils ont, et cela favorise beaucoup de collaboration et d'interaction et de discussion pour trouver de grandes solutions à ces problèmes. Le problème que nous avons avec cela, c'est que cela ne s'adapte pas. Donc, à mesure que l'entreprise grandit, il y a tout simplement trop de travail à faire.
Donc, si vous regardez le cycle de vie du produit, vous savez, ces quatre étapes, introduction, croissance, maturité et déclin, je pense, d'après mon expérience personnelle, que vous pouvez avoir une seule personne jouant les deux rôles pendant la phase d'introduction alors que vous essayez de trouver l'adéquation produit-marché. Et vous pouvez le faire aussi, vous savez, lorsque vous êtes en maturité et que vous entrez en déclin, car le produit est presque en mode maintenance. D'accord, donc il n'y a pas beaucoup de travail et de recherche, vous savez, sur les nouvelles choses que vous devez faire. Il s'agit simplement de maintenir ce que vous avez en état de marche. Peut-être, vous savez, vous construisez un autre produit, vous savez, pour... Remplacer celui-ci. Cependant, vous savez, si vous êtes dans la phase de croissance, cela ne fonctionne pas. Donc, il y a quelque chose qui ne va pas fonctionner. Donc, comme je l'ai dit, nous grandissions très vite. Donc, nous étions dans cette phase de croissance. Et, vous savez, j'étais complètement submergé. Il y avait trop de travail, et je ne faisais vraiment rien correctement.
C'est pourquoi nous avons décidé, d'accord, nous devons passer à autre chose, et nous devons diviser les responsabilités d'une manière ou d'une autre. Nous ne pouvons pas avoir Ramon qui fait tout lui-même. Et c'est ainsi que nous avons abouti à cette configuration que j'appelle le couple étrange.
Donc, nous avons fait des recherches. Nous avons commencé à réfléchir, d'accord, comment les organisations qui évoluent et qui grandissent divisent-elles les rôles ? Comment partagent-elles leurs responsabilités ? Et nous sommes tombés sur le framework SAFe. Et le framework SAFe distingue entre un product manager qui est plus stratégique et travaille sur la feuille de route et les fonctionnalités, des fonctionnalités de haut niveau, peut-être que vous pourriez appeler cela des epics, et des product owners qui travaillent sur leur backlog sur les user stories, donc ils décomposent les fonctionnalités en user stories, ils les priorisent, et travaillent avec l'équipe pour les livrer. Il y a deux autres rôles là-dedans. Je pense que cela s'appelle le Epic Owner et le Program Portfolio Manager, dont nous n'avions pas besoin pour nos objectifs et notre taille. Donc, c'est ce que nous avons examiné. Et nous avons en fait appliqué cela pour les clients d'entreprise, ou les entreprises d'entreprise, désolé. Mais il dit que c'est pour les équipes de plus de 50 personnes. Nous sommes plus de 60, donc nous avons pensé, peut-être que cela s'applique à nous. Et nous avons lu que certains experts en gestion de produit recommandaient cela, comme Rick Mironoff et les gars de Rally Software. Ils utilisent cela. D'accord, essayons.
Et donc c'est ce que nous avons fait. Donc, nous avions un product manager, dans ce cas c'était moi, qui faisait de l'outbound, était plus orienté marché et externe. Donc, il regardait la vision, la feuille de route, les fonctionnalités de haut niveau, la mise sur le marché, encore une fois, toutes les activités autour de la mise sur le marché et l'auto-activation, et toutes ces choses que j'ai expliquées, et la rentabilité.
Et nous avions un product owner qui était plus inbound. Donc, il travaillait plus avec l'équipe. Et le product manager communiquait, ne communiquait pas directement avec toute l'équipe, il communiquait par l'intermédiaire du product owner.
Il transmettait les priorités au product owner, et le product owner travaillait, d'accord, ce sont les fonctionnalités, je vais les décomposer en user stories, je vais construire le backlog. Ils utilisent les stories, partagent les connaissances dans l'équipe, maximisent la valeur, ce que nous avons vu que les product owners devraient faire. Et quelque chose de très important à dire, et peut-être, donc cela n'a pas fonctionné, soit dit en passant, je vais expliquer pourquoi, mais peut-être que la raison pour laquelle cela n'a pas fonctionné pour nous est que nous n'avons embauché personne pour jouer le rôle de product owner. Nous avions beaucoup d'ingénieurs, donc nous avons mis un ingénieur pour jouer ce rôle. Et c'était le manager d'ingénierie qui jouait le rôle de product owner. Et cela pourrait être la raison pour laquelle cette chose a échoué pour nous. Je ne suis pas sûr. Mais nous commençons à voir certaines choses qui ne sont pas trop bonnes. Du côté positif, maintenant le product manager avait beaucoup de temps. Je veux dire, j'avais vraiment beaucoup de temps. du temps pour aller parler aux clients, leur rendre visite, passer une journée, une semaine, je passais une semaine entière aux États-Unis à voyager, visitant plusieurs clients, recueillant leurs avis.
Je pouvais aussi passer du temps à faire de la recherche de marché. Nous parlons généralement aux analystes. Ils nous fournissent des informations sur ce que dit le marché, ce qu'ils voient que le marché dit et veut. Et en fin de compte, cela m'a vraiment aidé à devenir plus stratégique et à ne pas m'enliser dans les détails du travail quotidien.
Mais cela pose un problème. Et le problème pour moi, et je ne pense pas, vous savez, peut-être encore une fois, comme je l'ai dit, c'est peut-être parce que c'était un ingénieur qui travaillait dans un processus, dans ce rôle de propriétaire de produit. Mais je ne comprends pas comment quelqu'un qui n'interagit pas directement avec les clients très régulièrement peut les représenter. Je ne comprends pas comment le propriétaire de produit peut être un représentant du client s'il fait ce rôle de représentant par l'intermédiaire du responsable produit. Parce que dans ce cas, j'ai vu, vous savez, et nous avions différentes choses, j'ai vu différentes situations se produire. Dans certains cas, le... Le propriétaire de produit utilisait son interprétation de la compréhension du responsable produit de, vous savez, ce que le client voulait, ce qui n'était pas exactement la même chose. Et dans certains cas, comme je l'ai fait, j'ai commis la même erreur, je fais des suppositions sur ce dont l'utilisateur a besoin. D'accord, je n'ai aucun apport pour cela. Je fais une supposition raisonnable. D'accord, mais je suis aussi une personne, un être humain. Je suis sûr de comprendre. Je peux, vous savez, je peux comprendre. comprendre comment ils se sentent, et je peux prendre mes propres décisions. Et cela a causé beaucoup de problèmes, car nous apportions de l'alignement, la gestion de produit apportait de l'alignement sur le côté stratégique à travers l'organisation.
Mais ensuite, il y avait toutes ces décisions quotidiennes que le propriétaire de produit prenait et qui n'étaient pas nécessairement alignées avec ces priorités. Donc, bien que nous ne construisions peut-être pas quelque chose de complètement différent de ce qui était attendu, toutes ces décisions quotidiennes, nous en payions le prix. Ils prenaient de mauvaises décisions là. Nous étions, vous savez, encore une fois, c'étaient des ingénieurs, donc peut-être qu'ils priorisaient le travail. Ils voyaient, d'accord, j'ai ces personnes ici qui n'ont pas assez de travail à faire, alors je vais prioriser cette tâche. C'est une tâche d'ingénieur. Cela n'apporte peut-être aucune valeur au monde extérieur, mais c'est quelque chose que nous devons faire en interne, alors je vais prioriser cela. Je vais améliorer cette fonctionnalité ici parce que je pense que cela me dérange vraiment que nous ayons cette fonctionnalité qui ne fonctionne pas, mais peut-être qu'en pratique elle n'était pas si largement utilisée. Donc, il n'y avait aucune raison de l'améliorer, et il y avait d'autres choses qui pouvaient maximiser la valeur. Nous avions donc ce problème d'alignement à la fin.
Parce que sinon, le responsable produit doit s'impliquer très activement dans le quotidien pour s'assurer que les choses sont alignées.
Et dans ce cas, le propriétaire de produit devient juste un intermédiaire, peut-être plus un chef de projet que quelqu'un qui décide des priorités.
Donc cela ne fonctionnait pas, et nous avons donc itéré à nouveau. D'accord, alors nous avons dit, Dan, d'accord, cela ne fonctionne pas bien. Nous avons ce problème de priorité. Alors, comment pouvons-nous répartir les responsabilités d'une manière différente ? Et c'est ainsi que nous en sommes venus à cette dynamique, ce que j'appelle la configuration en duo dynamique. Nous avons introduit un nouveau rôle, celui de responsable marketing produit. Ou responsable marketing produit. Et cette personne s'occupait de toutes les activités de mise sur le marché. Donc tout ce que j'ai expliqué autour de l'habilitation des ventes, nous pouvons le voir ici. Donc ce que j'ai dit sur la stratégie, les plans de lancement, l'habilitation des ventes, la concentration sur la rentabilité, le travail sur la tarification, le soutien aux ventes, l'obtention d'informations des analystes qu'il apporterait à l'équipe. Et le responsable produit se concentrait sur la vision, la feuille de route, le backlog, donc il se concentrait sur le travail stratégique et tactique, les fonctionnalités et les user stories, le haut niveau et aussi le niveau inférieur, ainsi que la valeur et la rentabilité. Donc, simplement en déplaçant les activités de mise sur le marché vers quelqu'un d'autre, le responsable produit pouvait être très efficace à la fois sur le côté stratégique et tactique de la gestion de produit.
De plus, si vous y réfléchissez, la séparation a du sens parce que le responsable produit va se concentrer sur le fait de s'assurer que les utilisateurs aiment le produit. Et le responsable marketing produit va travailler avec un type de personne différent. Il va travailler avec l'acheteur. Et beaucoup de fois, dans notre cas, C'est le cas. L'utilisateur et l'acheteur sont des personnes complètement différentes. Donc, vous devez adapter la façon dont vous les traitez. C'est différent de les comprendre. C'est un type de travail très différent. Et c'est ce que nous avons fait. Et cela a très bien fonctionné. Donc d'abord, il y avait un seul responsable. Parce que quelque chose que je n'ai pas dit avant, lorsque nous avions le responsable produit et le propriétaire de produit, quand il y avait des questions sur le produit, ce n'était pas clair pour toute l'organisation à qui ils devaient demander. Ce qui peut sembler stupide, mais c'était un gros problème. Parce qu'ils demandaient à quelqu'un, et peut-être que cette personne prenait une décision sans que l'autre partie ne le sache ou quelque chose, si la communication n'était pas fluide. Et cela causait des problèmes. Maintenant, il y a un seul responsable pour à la fois le travail stratégique et tactique.
Cela apporte de l'alignement à travers toute l'organisation. Encore une fois, il n'y a qu'une seule personne qui a la vision. J'ai les étapes pour y parvenir, pas seulement au niveau élevé, mais aussi au niveau bas. Et je peux expliquer cela à tout le monde afin que tout le monde comprenne ce que nous faisons et comment nous allons y parvenir. Cela a vraiment aidé à l'alignement.
Et puis la collaboration, parce que vous êtes impliqué dans tout le processus, à la fois sur un niveau stratégique et sur un niveau tactique, vous pouvez rapprocher l'équipe, et nous verrons certaines améliorations que nous apportons au processus, vous pouvez rapprocher l'équipe d'ingénierie des clients également, et les impliquer dans les conversations, afin qu'ils obtiennent également une compréhension de première main de ce dont les clients ou les utilisateurs ont besoin.
Cela a très bien fonctionné pour nous. Et l'alignement entre le marketing produit et la gestion de produit fonctionne. De mon point de vue, il est facile d'atteindre l'alignement entre le responsable produit et le propriétaire de produit parce que la gestion de produit et la propriété de produit, il y a des décisions quotidiennes que le propriétaire de produit prend qui ont un impact sur le produit. Et ils doivent être synchronisés presque tous les jours. Alors qu'avec le marketing produit, les décisions sont à un niveau plus élevé et s'étendent sur quelques mois. Ce n'est pas comme si vous changiez votre positionnement ou votre vision tous les jours. C'est quelque chose de plus stable. Donc, il est plus facile pour nous, nous nous rencontrons une fois par semaine, il est plus facile pour nous de rester synchronisés sur ce que nous faisons. Cependant, je peux voir qu'un problème potentiel, encore une fois, nous ne l'avons pas, mais je peux voir un problème potentiel entre ce que vous commercialisez, quelle est la valeur que vous commercialisez, et quelle est la valeur réelle que vous ajoutez dans le produit. Et cela pourrait être si la personne en marketing produit a une opinion différente en termes de stratégie qu'elle veut suivre. Et peut-être qu'ils déplacent leur message, et parfois même inconsciemment, vers cela, ils déplacent leurs messages vers ce type de proposition de valeur, alors que ce que le responsable produit construit ou essaie de résoudre est quelque chose de tout à fait différent.
Alors, qu'est-ce qui suit ? Donc maintenant, encore une fois, pour nous, nous voyons cela comme un processus d'amélioration continue. Nous ne nous arrêtons pas. Nous essayons toujours de le regarder de manière critique et de voir ce que nous pouvons faire ensuite pour l'améliorer. Donc la première chose que nous faisons est que nous mettons en œuvre l'agile à double voie. Et nous avons déjà fait cela avec certains... Avec certaines des fonctionnalités que nous construisons, c'est que nous séparons l'apprentissage de la livraison. Et nous avons une voie de découverte où l'accent est mis sur l'apprentissage, le prototypage, l'expérimentation, et la recherche de solutions à des problèmes qui sont validés. Nous n'avons pas une user story que nous apportons à l'équipe et ensuite, vous savez, nous devons peut-être détailler les détails et découvrir si cela va fonctionner, si c'est une bonne solution ou non. Non, ce n'est pas ce que nous faisons. Nous avons ces cycles. Encore une fois, ces cycles ne sont pas constants. Cela dépend de ce que nous essayons d'apprendre. Mais nous entrons dans des cycles de construction de prototypes, de test, et de validation de nos hypothèses. Et à la fin, nous produisons... Ces prototypes ne sont que des maquettes. Ce n'est qu'une série de maquettes qui sont connectées, donc elles sont interactives. Vous pouvez cliquer dessus. Et elles sont très peu coûteuses à produire, et elles sont super efficaces pour montrer comment vous adressez le problème réel. Et celles-ci deviennent maintenant notre spécification. Donc nous avons cela. C'est ce que nous donnons au développement avec une description supplémentaire de certains détails. Mais c'est ainsi, et il n'y a pas de problèmes autour de, vous savez, comment cela выглядит, comment cela se comporte, c'est très clair à partir de cette description.
Donc dans la voie de découverte, nous avons cette chose que nous appelons le backlog d'opportunités. Ce sont des idées générales de choses que nous y mettons et que nous croyons être précieuses, elles sont classées. Et dans la conception, la piste de découverte ou les sprints de design, nous puisons simplement à partir de là, découvrons, essayons d'affiner le problème, comprenons si c'est un bon problème à résoudre ou non, et quelle valeur nous pouvons produire avec eux, puis expérimentons en construisant quelques prototypes. Ensuite, nous avons la piste de livraison, la piste de développement qui est axée sur la livraison. Le résultat de la piste de découverte est d'intégrer le backlog de développement. Et le développement fonctionne à nouveau. Nous continuons à travailler avec Scrum, de manière régulière. Nous utilisons des sprints mensuels, peut-être un peu longs, mais c'est ce que nous avons trouvé qui fonctionne bien pour nous. Et peut-être est-ce à cause de notre organisation en remote. Et nous publions à la fin de chaque sprint. Voilà ce que nous faisons.
Une autre chose que nous avons introduite est les job stories ou quelque chose basé sur le concept de jobs to be done.
Nous utilisons cela pour le backlog d'opportunités. Donc nous ne pensons pas en termes de user stories, nous pensons en termes de job stories, c'est-à-dire pourquoi les gens engagent-ils votre produit ? Pourquoi engagent-ils votre produit ? Que tentent-ils de faire ? Donc ce focus n'est pas sur une persona spécifique, il se concentre davantage sur le contexte. Donc, quel est, vous savez, quel est le contexte autour de la situation ? Quels sont les besoins qu'ils essaient de satisfaire ? Et quels sont les objectifs ? D'accord, donc nous ne nous limitons pas trop. Nous n'entrons pas dans l'implémentation de ce que c'est, ce qui consiste vraiment à faire ressortir les besoins, les vrais besoins derrière le problème que les gens ont. Et pour cela, il faut bien comprendre le contexte, et il faut comprendre les objectifs. Et les objectifs, vous savez, peuvent être des objectifs émotionnels. Ils peuvent être, vous savez, des objectifs plus pratiques. C'est donc quelque chose de plus large, mais cela nous donne suffisamment d'informations pour essayer de résoudre le problème sans être biaisés. Parfois, les user stories biaisent vers une solution. Ici, nous essayons de rester très ouverts afin de pouvoir expérimenter.
Et la dernière chose que nous avons introduite, et que nous avons déjà, nous l'avons introduite, vous savez, il y a six ou neuf mois, ce sont les objectifs et résultats clés. Je ne vais pas entrer dans tous les détails des objectifs et résultats clés, vous pouvez chercher. C'est une façon d'aligner l'organisation. Donc, vous définissez quels sont les objectifs commerciaux, puis par l'entreprise, les départements, et chaque individu a ses propres objectifs et résultats clés, ou OKR. L'objectif est quelque chose, vous savez, un objectif motivant. Et les résultats clés, c'est comment vous allez mesurer que vous avez atteint cet objectif. Et il est censé être un objectif ambitieux. Donc ce n'est pas l'idée que vous atteigniez 100 %, c'est que vous atteigniez 60, 70 %, mais que vous poussiez les gens. Et c'est génial parce que cela apporte beaucoup d'alignement. Il y a beaucoup de transparence sur les objectifs que tout le monde dans l'organisation et chaque département a. Et cela nous aide également à mesurer si nous nous dirigeons vers cet objectif ou non. Donc ce que nous faisons, c'est que nous avons... Nous utilisons simplement un wiki Confluence pour mettre toutes ces informations. Donc tout le monde, chaque équipe et chaque individu a une page. Et pour les individus, nous avons les OKR et nous les suivons chaque semaine. Il y a des tâches que nous ajoutons pour nous aligner sur les OKR. Il y a d'autres choses que nous allons faire. Mais nous notons chaque vendredi ou chaque lundi, selon l'équipe, les tâches qu'ils vont accomplir la semaine suivante. Et nous célébrons nos accomplissements le vendredi à la fin de la semaine pour nous assurer de voir, d'accord, nous avons progressé. Et cela a vraiment fait une différence parce que ces activités, qui sont parfois plus stratégiques et peut-être pas si urgentes, mais qui sont très importantes, étaient souvent reportées. Maintenant, si vous les avez dans les OKR, cela force les gens à les faire. En plus de cela, si une autre équipe vous demande quelque chose, il est plus facile d'avoir une discussion. Non, non, non. Regardez les OKR. Ils ont déjà été discutés. Parce qu'ils sont discutés et convenus dans toute l'entreprise. Ils ont été discutés. Nous nous sommes mis d'accord sur eux. Donc je ne vais pas vous aider maintenant. Je dois vraiment me concentrer sur ces choses pour m'assurer qu'elles soient faites ce trimestre.
Et donc c'est essentiellement là où nous en sommes. J'espère que vous êtes toujours en vie.
Et si vous voulez me contacter, vous avez mon email et mon pseudo Twitter là.
Encore une fois, je ne prétends pas que ce que je vous montre aujourd'hui est la solution aux problèmes que vous avez. Vous devez voir dans votre contexte, évaluer dans votre organisation, la culture de vos collaborateurs.
Chaque organisation est différente. Mais j'espère que cela vous donne quelques idées sur des choses que vous pouvez essayer dans vos équipes pour améliorer leur productivité, leur efficacité, et, espérons-le, aussi leur bonheur. Merci.

Transcription (Traduit)