Sébastien Sacard
Transcription
Bonsoir à tous, je vais commencer puisqu'on est déjà 8 minutes, 10 minutes en retard et je vais essayer de tenir les délais.
Je vais vous parler d'une méthode de management de produits que j'ai... Que j'ai conçu. Je vais vous expliquer un petit peu d'où ça vient, aussi un petit peu d'où moi je viens, pour que vous compreniez un petit peu l'histoire de cette méthode.
J'ai commencé ma carrière en 1999, je suis le premier employé de la société Kelkou, pour ceux qui connaissent encore, c'était un comparateur de prix qui avait été racheté par Yahoo en 2004. J'ai commencé en tant que webmaster, développeur, ingénieur dans l'équipe R&D. Puis j'ai pris des responsabilités de lead technique. Et quand Yahoo a racheté Kelco, j'ai eu l'opportunité de partir en Angleterre et d'apprendre un nouveau métier, qui est le métier de product manager. Le product manager, c'est un métier qui n'existe pas vraiment en France, en tout cas dans le digital, dans le web ici. Ça existe chez les éditeurs, ça existe bien sûr dans d'autres secteurs que l'informatique. Mais en France, ça n'existait pas. Et quand je suis revenu en 2007, je cherchais un job de product manager et je n'en ai pas trouvé, tout simplement parce qu'il n'y avait pas d'entreprise. Donc j'ai décidé de devenir consultant et d'évangéliser un petit peu ce métier et ses pratiques dans différentes entreprises.
Depuis 7 ans, je suis consultant et je travaille principalement pour des grands groupes aujourd'hui. Et j'alterne création de start-up, accompagnement de grands groupes, pour essayer de polliniser les deux univers. C'est-à-dire que quand je suis en mode start-up, je transmets un peu ce que j'apprends dans les grands groupes. Et quand je suis dans les grands groupes, j'essaie de ramener un petit peu d'esprit start-up dans... Dans ces équipes.
Aujourd'hui, moi, j'ai trois activités qui se complètent. Vous allez comprendre pourquoi. La première, c'est que j'ai cofondé une startup depuis le mois de juin.
On a monté un réseau avec mes associés, un réseau de réparation de mobile à domicile et en entreprise. Donc moi, je m'occupe du produit, de la technique. Mon associé s'occupe du commerce et du développement du réseau. Et on l'a développé en mode Lean Startup.
Et ça marche.
Ma deuxième activité, c'est que, comme je vous le disais, quand je suis arrivé en France, j'ai cherché le métier de Product Manager et je n'ai pas trouvé de job. Donc depuis deux ans, je me suis lancé dans la promotion de ce métier dans les entreprises. Donc on a monté une association. Aujourd'hui, on est plus de 600 dans le groupe sur Paris. Dans l'association d'actifs, on est à peu près 70. Tous les mois, on fait des conférences sur product management. On fait venir des experts étrangers. La dernière, au mois de septembre, on a fait venir le coach produit de Google Venture aux États-Unis, qui s'occupe de coacher toutes les startups incubées par Google. On l'a fait venir pour nous parler produits. On a fait venir GoCoAd. Que vous connaissez sûrement. On essaie de faire venir des gens pour parler produits et parler de choses un petit peu nouvelles et de promouvoir le métier de product manager.
Et donc je suis auteur d'une méthode que j'appelle le Lean Product Management, qui est donc des aspects du Lean et du Product Management, qui permettent aux grandes organisations d'innover aussi vite que des startups. C'est l'objet de cette méthode.
Donc moi, je vais vous parler de transformation digitale en introduction pour comprendre un peu dans quel contexte on évolue. Le Lean Product Management, ça s'applique dans le contexte d'entreprises qui sont en transformation digitale. Pardonnez-moi.
Et une transformation digitale, c'est quoi?
C'est un mot qui veut dire plein de choses pour plein de personnes différentes. Pour moi, la transformation digitale, c'est un changement de business model. C'est-à-dire qu'une entreprise classique va transformer radicalement ses modèles de revenus pour passer sur des modèles de revenus basés sur du digital. Prenez par exemple Pâtes Jaunes, qui vend du papier, qui passe depuis des années à du digital. Ça, c'est de la transformation digitale. C'est quand on change de revenu, quand on change son modèle, on change ses équipes et sa production en profondeur.
Et qu'est-ce qui ne marche pas dans ces entreprises ?
J'ai travaillé dans beaucoup de ces entreprises et je consulte aussi beaucoup.
Le problème principal qui revient, c'est qu'il y a beaucoup trop de temps entre l'idée, on aimerait bien faire ça, et le moment où ça sort de l'autre côté, où on arrive enfin à sortir la fonctionnalité, le nouveau produit, etc. Ça peut prendre deux ans, facilement. Ah, ça serait bien si on faisait une application qui? Et puis deux ans après, elle n'est toujours pas sortie, ou elle commence à sortir. C'est vrai aussi pour les départements IT en interne, quand on a des modifications à faire sur des back-office, des changements, des nouveaux outils, des nouveaux process, ça met beaucoup, beaucoup, beaucoup de temps. Le deuxième point qui a été remonté par les personnes que j'ai interrogées, c'est que la notion de valeur, elle est très, très floue selon les personnes à qui on parle. Et c'est une des problématiques qui fait que ça ne bouge pas.
Le troisième point, c'est qu'il y a souvent une grande différence entre ce que dit le patron, la vision, et ce qu'on nous demande de faire au quotidien.
Et le quatrième point, c'est que l'innovation dans ces entreprises n'est pas perçue comme une source de revenus fiable. C'est-à-dire qu'avant tout, dans ces entreprises, il s'agit de protéger le revenu, c'est-à-dire le revenu actuel qui est généré par les ventes actuelles et le business model actuel. Et pas tellement d'innover, parce qu'innover, c'est dangereux. Innover, innover, ça remettrait en cause le business model de l'entreprise. Donc, c'est souvent pas perçu comme un potentiel de revenu. Là où, chez les startups, l'innovation, c'est le modèle de revenu principal. Si vous n'innovez pas, vous mourrez. Et donc, vous n'avez pas de raison d'être. Donc, c'est les grandes différences.
Et c'est ce qui ne marche pas vraiment dans les transformations digitales. Et c'est pour ça que c'est aussi lent. Les alternatives que ces entreprises ont développées, justement, pour arriver à développer quand même, à profiter un petit peu de l'innovation, elles sont plusieurs, vous en connaissez certaines. Elles font des hack days. Alors nous, on faisait même ça chez Yahoo, une grosse start-up quand même, mais on faisait des hack days, c'est-à-dire que pendant une journée, en gros, on avait quartier libre pour innover. Une journée sur toute une année, même chez Yahoo. Dans des entreprises comme Page Jaune, ou même chez AXA, dans d'autres grandes entreprises, ils font des hackathons, c'est-à-dire ouverts ou fermés, mais on va innover pendant 24 heures, 48 heures, pour faire des choses. Et souvent, ils sortent des choses intéressantes. Dans ces hackathons, on va sortir un produit. On va déléguer une équipe, un budget, et on va sortir un produit. Ça arrive une fois par an, pour un. C'est assez petit. Ce qu'on constate aussi, c'est que souvent l'innovation est déléguée dans un département, et même dans un bureau très loin, même dans une autre ville souvent. Et ça, c'est la façon qu'ils ont d'essayer de trouver un petit peu d'innovation, c'est qu'on met des gens, souvent techniques, dans un coin, et on leur demande de trouver des choses. Ou alors c'est un département innovation qui est censé essaimer dans les autres départements des pratiques d'innovation. Au quotidien, dans les outils. Troisième façon de faire un peu d'innovation dans ces grandes entreprises, c'est d'incuber des entreprises. Elles vont financer, elles vont ouvrir des bureaux, faire venir des entreprises, s'intéresser à leurs projets, pourquoi pas éventuellement les financer, les acheter, mais voilà, on ne touche pas au business normal.
Elles vont aussi faire de l'investissement externe, elles vont investir dans des entreprises innovantes, racheter des startups, éventuellement. Mais voilà, on ne touche pas au business... actuel. Et alors c'est pareil, c'est comme transformation digitale, innovation, ça veut dire plein de choses pour beaucoup de gens, mais il y a une vérité, moi que j'ai découvert dans le milieu des startups notamment, c'est que l'innovation, ça ne se commande pas. On ne dit pas, tiens, on va innover. Et donc ces solutions de créer un pot, l'innovation, des choses comme ça, ça ne peut pas marcher parce que l'innovation, par définition, ça arrive par erreur, par hasard. Donc on ne peut pas provoquer le hasard. On ne peut pas dire, tiens, on va trouver l'innovation, ça ne marche pas. Il faut faire plein de choses, il faut tester plein de choses. Et c'est en testant plein de choses qu'il va arriver un jour peut-être de l'innovation. Et ce n'est pas seulement en faisant plein de choses, c'est en faisant plein de choses, en constatant des résultats, et en se disant, tiens, il y a un écart par rapport à ce que je pensais. Qui allait arriver pendant mon expérience. Et c'est en creusant ce point-là qu'on va découvrir quelque chose que personne n'avait découvert ou que personne n'avait cherché jusqu'à maintenant. Et c'est là qu'il y a un potentiel d'innovation.
Donc l'innovation programmée, entre guillemets, des programmes d'innovation, c'est simplement des programmes d'investissement en fait. On dit voilà on va développer un nouveau projet, on alloue un budget et finalement le projet va sortir. Mais ça ne sera pas plus innovant que ça. Ce n'est pas ça qui va être disruptif par rapport à un marché. On ne va pas découvrir ou révolutionner quelque chose dans des programmes d'innovation. Donc l'innovation dans la transformation digitale, ça ne marche pas très bien avec ces solutions-là.
Donc comment une compagnie pourrait délivrer plus vite ?
Insérer de l'innovation au quotidien dans les processus de développement classique. Avoir idéalement un framework unique qui serait partagé par tous les départements de l'entreprise, pour éviter d'avoir l'IT d'un côté, le marketing de l'autre, l'innovation encore plus loin, et que ces gens ne se parlent pas.
Et puis idéalement, pourquoi pas, on sort de l'atelier Cost of Delay avec Ron Renadsen, mais comment on pourrait remplacer la persuasion par l'expérimentation? C'est-à-dire qu'aujourd'hui, toutes les grandes décisions, les nouveaux produits qui sont lancés, C'est le CEO, c'est le marketing qui décide, allez on va faire ça, c'est super et puis on y va. Mais il n'y a pas plus de fait que ça. Et donc le framework que je propose, c'est de remplacer justement toutes ces décisions de choix de produits, de fonctionnalités, par des décisions rationnelles basées sur des expérimentations, plutôt que sur des décisions qui peuvent être bonnes, mais
qui peuvent être une fois sur deux mauvaises.
Donc moi, la méthode, elle vient de là. Elle vient de deux choses, de deux univers, quelque part. Du product management, je vais vous parler rapidement.
Et du Lean Thinking. Donc ce n'est pas le Lean Startup, c'est un petit peu ce qu'il y avait avant le Lean Startup. C'est comment se centrer sur la valeur, sur la recherche de nouvelles valeurs, sur délivrer de la valeur plus rapidement, de manière plus continue, etc.
Et je ne sais pas si vous connaissez ce livre, Lean Thinking, mais moi, personnellement, il a un peu changé ma vie depuis quelques années. Donc moi, je vais vous parler du product management et comment ça peut changer un petit peu l'organisation de vos entreprises et comment la mise en place du product management va permettre... l'innovation dans vos programmes de développement. Donc on va aller au-delà du product development que vous avez peut-être l'habitude de pratiquer, On va parler de produits et de management. Un produit, on peut le voir d'une façon assez systématique, assez mathématique quelque part. L'idée, ça va être de mettre de la mesure là-dedans. Donc, il faut mesurer des choses. Donc il faut rationaliser beaucoup de choses. Ce qui, a priori, n'est pas très rationnel. Un produit... Quand on parle produit, on pense à marketing, on pense à communication, on pense à marché, prix, etc. Donc ce n'est pas très rationnel. Et pourtant, il y a un moyen de rationaliser tout ça, et notamment pour moi qui suis plutôt... technique, plutôt analytique, ça m'a permis de rationaliser pas mal de choses. Un produit, on peut le voir comme un système, avec une entrée, des besoins, clients, et puis en sortie de la valeur pour l'entreprise,
et des bénéfices utilisateurs pour l'utilisateur. Donc on distingue bien les deux choses. Quand on parle de business value,
C'est value, c'est de l'argent, c'est des euros, c'est pas autre chose. Donc si vous avez l'habitude de traiter avec des backlogs où on parle de business value, c'est de l'argent. Quand on parle de bénéfice utilisateur, c'est du gain de temps, de la performance, de tout ce que vous voulez. Mais un produit, ça fait deux choses. On va aller du plus simple au plus compliqué. Un sèche-cheveux, un produit comme un autre, il y a un besoin, des bénéfices utilisateurs et de la valeur. Celui-là, je n'ai pas rempli exprès pour avoir un petit peu votre avis, mais c'est quoi le bénéfice du sèche-cheveux?
Pardon ?
Si, ça peut chauffer en hiver.
Gagner du temps, voilà. Gagner du temps, ne pas tomber malade, pour ne pas sortir les cheveux mouillés, etc. Bref, gagner du temps, ça peut être un bénéfice effectivement du sèche-cheveux. La valeur.
30 euros, c'est de l'argent. C'est assez simple. On est sur un produit standard. J'achète un produit. Je donne de l'argent à l'entreprise. L'entreprise gagne de l'argent. C'est assez simple. Là, on va faire un petit peu plus compliqué.
Un GPS.
Un GPS TomTom, moderne comme celui-là. Pardon?
C'est vrai? Mais t'as raison. La dernière campagne TomTom, c'était n'arriver plus en retard ou quelque chose comme ça. On était assez loin dans le bénéfice. Mais oui, pourquoi pas, la paix des ménages, complètement.
Mais la valeur, c'est un peu plus compliqué. Parce que la valeur, ce n'est pas simplement la valeur d'achat. Parce que derrière, ils vont vendre des services, ils vont vendre un abonnement, cartographique, etc. Donc le produit en lui-même, on commence à décorréler le bénéfice immédiat de la valeur perçue quand on l'achète. C'est encore plus vrai pour les imprimantes. Vous le savez, quand on achète une imprimante, on ne paye pas le prix de l'imprimante. En fait, là où on gagne de l'argent, c'est sur les fournitures, c'est sur l'achat de... Pardon ?
C'est vrai? Mais t'as raison. La dernière campagne TomTom, c'était n'arriver plus en retard, ou quelque chose comme ça. On était assez loin dans le bénéfice. Mais oui, pourquoi pas, la paix des ménages, complètement.
Mais la valeur, c'est un peu plus compliqué. Parce que la valeur, ce n'est pas simplement la valeur d'achat, Parce que derrière, ils vont vendre des services, ils vont vendre un abonnement, cartographique, etc. Donc le produit en lui-même, on commence à décorréler le bénéfice immédiat de la valeur perçue quand on l'achète. C'est encore plus vrai pour les imprimantes. Vous le savez, quand on achète une imprimante, on ne paye pas le prix de l'imprimante. En fait, là où on gagne de l'argent, c'est sur les fournitures, c'est sur l'achat de...
Oui, effectivement.
Ce n'est pas vraiment le sujet, c'est pour introduire la notion de produit, mais oui, Google, c'est encore plus loin. N'importe quel service Internet gratuit, entre guillemets, c'est encore plus loin. On a un bénéfice utilisateur immédiat qui est de trouver de l'information.
La valeur pour Google, elle est nulle. Si vous cherchez que vous ne cliquez jamais sur la publicité, elle vaut zéro. Par contre, l'audience, le trafic que vous faites va créer une valeur dérivée, qui est que cette valeur, cette audience, ils vont la vendre à des annonceurs qui, eux, vont payer de l'argent pour le coup réel, etc. Donc plus on va dans le digital, plus c'est compliqué de lier le bénéfice utilisateur et la valeur. Et c'est pour ça qu'il faut mesurer les deux différemment. Puisque l'un peut impacter l'autre, mais sur des niveaux quand même assez lointains. Et donc quand on fait un produit, quand on développe un produit, il faut se poser ce genre de questions, il faut avoir cette notion de bénéfice et de valeur, pour pouvoir ensuite savoir ce qu'on développe. Et une façon de faire ça dans des entreprises, de piloter ça, de piloter la valeur, de piloter les bénéfices, c'est de mettre en place une organisation produit.
Dans une entreprise. Une organisation produit, c'est quoi? C'est que, comme vous le voyez, comme d'habitude, le marketing et l'engineering, en fait, une organisation produit, il y a des product managers entre le marketing et l'IT. qui ne font pas partie de l'IT, qui ne font pas partie de l'engineering. Et ces gens du produit, donc dedans il y a des product managers, il y a UX designers, il y a des product designers aussi, tous ces gens-là, ils travaillent directement avec le client. Pour déterminer le vrai bénéfice client qui est attendu par eux. C'est eux qui vont aller chercher des idées, trouver des idées innovantes, rationaliser tout ça et en faire un système, construire un produit qui au final créera de la valeur pour l'entreprise et des bénéfices pour les clients.
Le rôle du product manager, c'est de travailler avec le marketing, l'engineering et la finance pour faire un produit rentable. Donc il apporte de la valeur in fine. Donc c'est son rôle. Il a un rôle de maintien du héroïne de son produit.
Souvent, dans les entreprises plus classiques, ce rôle-là, il est délégué, je prends l'exemple de Page Jaune, par exemple, c'est plutôt le commerce qui gère les revenus. Ce n'est pas du tout le product manager qui est responsable de monétiser un produit. Donc ce type d'organisation, c'est le type d'organisation que vous retrouvez très fréquemment aux États-Unis. C'est un type d'organisation que vous trouvez chez les éditeurs logiciels.
C'est quelque chose qu'on trouve très très peu en France, mais c'est en train d'arriver, c'est en train de changer. Et donc dans l'ordre, en gros, le product manager, il s'occupe de trouver les idées, il design le produit, en même temps il vérifie la faisabilité technique, il vérifie la viabilité, financière et il vérifie, il va définir l'offre avec le marketing. Une fois que le produit est développé, il va travailler avec le marketing pour lancer le produit et ensuite le marketing va travailler avec le commerce pour préparer le message et aider les commerciaux à vendre le produit. Ça, c'est dans une entreprise plus B2B, c'est pour ça que je l'ai mis en gris. C'est un peu particulier. En B2C, il n'y a que ça. Il n'y a pas de commerciaux. Pourquoi je vous parle de Product Manager? C'est parce que c'est ce type d'organisation et ce type de rôle qui peuvent porter l'innovation dans une entreprise, plutôt qu'un département à côté. C'est-à-dire que le Product Manager a la responsabilité de piloter le produit de l'entreprise, mais également d'injecter de l'innovation en permanence. Grâce à un framework que je vais vous montrer. Moi, la question que je voudrais vous poser, c'est est-ce que vous êtes une entreprise produit, en tout cas dans l'entreprise dans laquelle vous travaillez, est-ce que vous proposez un produit tel qu'il est défini avant?
Aucun d'entre vous ?
Vous êtes plutôt une entreprise IT, c'est-à-dire un département IT dans une entreprise qui vend autre chose, c'est ça? Et qui serait potentiellement dans une phase de transformation digitale dans un futur plus ou moins proche, par exemple?
Un type d'entreprise, pas forcément le nom, mais un type de secteur,
Pour une banque, oui. Qui sont en pleine transformation digitale, pour le coup, depuis plusieurs années, et ça s'accélère.
D'accord. Donc voilà, nous ce qu'on appelle les projets métiers, c'est les produits. Une banque par exemple, on peut prendre l'exemple d'une banque, d'une compagnie aérienne ou autre, ils ont un vrai métier, c'est effectivement faire fructifier de l'argent, proposer des services financiers, ça c'est leur produit à eux. Après, les produits digitaux, on pourrait dire que c'est pour du marketing, c'est pour faire de la communication, ou alors pour améliorer le travail des agences, etc. On pourrait dire que c'est un side business finalement, que ce n'est pas ça qui permet de gagner de l'argent. Mais tôt ou tard, toutes les entreprises feront du logiciel et du digital, et ce sera ça leur... Leur vrai business, en fait. Leur vrai produit, ce sera bientôt ça. Aujourd'hui, vous avez toutes les banques en ligne, 100% en ligne. Si elles n'ont pas de produit digital, ça n'existe pas. Elles n'ont plus d'agence, elles n'ont plus rien. Donc le produit en lui-même devient très central. D'autres types d'entreprises, c'est des entreprises type médias, des journaux, etc. Ce n'est pas vraiment un produit. Le logiciel, entre guillemets, est un support. Il remplace le papier, mais ce n'est pas un produit à part entière. Mais on peut voir les choses. On peut voir les choses, on peut tout voir comme un produit, dans une certaine mesure. Et donc on peut introduire ces notions de KPI, de bénéfices, de valeurs, pour aider à piloter les projets sous forme de produits. Dans l'IT, par exemple, moi je travaille actuellement avec un client dans le département IT, dont le métier n'est pas de faire du produit, mais de faire du commerce.
Le département IT, Se posent la question de dire, nous voulons devenir éditeur, donc avoir une position produit. Et donc on est en train de voir avec eux comment introduire le rôle de product manager en interne, dans le cadre du département IT, et plus être en position de vendre
un produit fini, un logiciel, une plateforme, que d'accueillir des besoins et de faire des projets. Donc c'est tout à fait possible. On peut voir les choses, notamment dans l'IT, comme étant éditeur de logiciels et donc éditer un produit.
Donc les phases du product management et du lean product management, voilà comment ça se passe. Et en fait, je ne pourrais pas vous dire que j'ai utilisé chez un de mes clients l'ensemble de ces phases-là. Chez mes clients dans le passé et dans mes aventures en tant que salarié, j'ai fait une de ces étapes ou plusieurs de ces étapes. Et c'est très difficile de faire le framework en entier. J'espère que dans le futur, on y arrivera. Plus on prend le projet en amont, plus on y arrive. Mais il faut aussi que l'organisation d'entreprise soit faite de telle sorte qu'on puisse avoir un rôle de product manager et un framework comme ça. Mais il y a différentes étapes. L'étape de découverte, qu'on fait rarement.
l'étape de design, de développement, de lancement, d'amélioration continue, et surtout à la fin, ce qui est assez nouveau, c'est qu'on va se forcer à jeter la plupart des choses qu'on développe.
Ça peut paraître aberrant aujourd'hui, mais moi, à l'époque où j'étais chez Yahoo, c'est ce qu'on faisait. Et à l'époque déjà, Google faisait dix fois plus que nous, jetait dix fois plus de choses que nous. Ça veut dire quoi, jeter plus? Ça veut dire qu'on va expérimenter beaucoup, beaucoup, beaucoup de choses. Et on va ne garder que ce qui marche. Mais que ce qui marche très bien. Pas ce qui marche un peu. Et donc en testant beaucoup, comme on l'a vu pour l'innovation, on va se permettre de trouver des idées auxquelles on n'avait pas pensé, ou des choses un peu étranges auxquelles on n'avait pas pensé. Donc on va faire surgir l'innovation. C'est comme ça que les grands groupes... Aux États-Unis découvrent des choses, c'est en testant plein de choses, et donc hop, il y a l'innovation qui émerge, et ils en jettent 95%. Quand on parle d'expérimentation, ça va de« je lance un produit en entier», comme Google... Wave, voilà. Grosse innovation lancée dans un pays, en Australie, et qui n'a pas marché. Mais ça va aussi de« je change la couleur d'un lien» ou« je déplace un bouton» ou« je rajoute un petit truc» et je teste sur un petit ensemble de personnes. Une boîte comme GULF fait entre 3 et 5 000 expérimentations par an.
Plein de petits tests comme ça. Et on jette. Et on jette tout ce qui ne marche pas.
Plus près de nous, en France, une boîte comme Viadeo, moi j'ai été témoin malgré moi de tests qu'ils ont faits. Un jour, sur une fiche d'un profil de quelqu'un, il y a eu un bouton qui est apparu qui s'appelait« Prendre rendez-vous» ou« Proposer un déjeuner» ou un truc comme ça, je ne sais plus. J'ai cliqué dessus et il y a une fenêtre qui est apparue qui a dit« Merci, mais en fait le bouton ne marche pas encore. Par contre, on a bien noté votre intérêt pour la fonctionnalité, on vous recontactera, etc. » Alors pour ceux qui connaissent l'Instartup, c'est un peu connu, mais je trouvais ça intéressant qu'une boîte comme Viadeo, qui a une bonne dizaine d'années, commence à rentrer dans cette démarche de test. Et il n'y a pas très longtemps, j'ai reçu un email du Product Manager. Personnalisé qui me disait merci d'avoir cliqué sur le lien, on aimerait bien en savoir plus sur votre besoin, etc. Donc ils sont dans ces démarches de test. Donc l'intérêt c'est quoi? C'est de tester plein de petites choses et de passer par toutes ces étapes systématiquement, à chaque fois. Et de le faire de plus en plus vite. Donc il y a trois focus importants. Trouver sans arrêt des nouvelles opportunités, soit des nouvelles opportunités business, donc au travers de nouvelles fonctionnalités qui généraient des nouvelles lignes de revenus, ou alors complètement des nouveaux produits, pourquoi pas? Il faut se laisser la possibilité de faire des nouveaux produits. Moi, j'ai travaillé pour une boîte dont le métier n'était pas du tout le e-commerce. Et ils m'ont demandé d'explorer la piste e-commerce. sur la base de leur ADN, de leurs actifs, de leur culture aussi. Il ne s'agit pas de lancer une nouvelle entreprise, mais d'explorer des possibilités de faire du e-commerce pour une entreprise qui n'en faisait pas du tout. Et ça, on peut le faire très très rapidement, en quelques semaines, on peut explorer des possibilités, voir s'il y a un potentiel, des choses intéressantes, en allant interroger des clients, en allant faire une petite étude de l'écosystème, voir un peu comment ça se passe, donc ça c'est tout à fait possible. Et tout ça, il y a des itérations. On itère. Dans la partie découverte, on va itérer, plein de fois. Dans la partie design aussi, on va itérer plein de fois. Donc on itère sans arrêt. Dans la partie développement, vous connaissez tous. On itère, on fait du Scrum. La partie amélioration continue, c'est également pareil.
On itère sans arrêt. Le deuxième focus, c'est atteindre ce qu'on appelle le Pro-Lock Market Fit, c'est atteindre vraiment l'adéquation pro du marché, c'est-à-dire qu'on lance une première version extrêmement rapide et on se donne un temps, on se donne 2-3 mois pour l'améliorer, l'améliorer, jusqu'à ce qu'on arrive à un taux satisfaisant et on décide de le garder. Ou de le jeter. C'est-à-dire que si on n'atteint pas le taux qu'on s'était donné, le chiffre qu'on s'était donné de performance, on enlève la fonctionnalité, on ne va pas chercher plus loin.
Dans une entreprise un peu classique comme on peut en trouver en France, ce serait sur une échelle de 3 à 6 mois, une expérience. On va se donner un mois ou deux, un mois pour faire de la découverte, deux, trois mois pour faire du... design du développement, deux mois pour améliorer la fonctionnalité, puis au bout de deux mois, on arrête. En tout cas, on tire un premier bilan. Et on se donne un bilan, on se dit, est-ce qu'on continue ou est-ce qu'on arrête?
Mais la clé, elle est là. La clé, elle est d'accepter dès le départ, de se dire, l'expérimentation qu'on va mettre dans ce flux est vouée à disparaître. C'est là où il y a un grand changement culturel à avoir.
La grande différence aussi, c'est que comme vous le voyez, le Product Manager est surtout le long de la chaîne. C'est lui qui pilote ça avec le marketing, avec les UX designers, avec les développeurs. En fonction de l'emplacement dans le flow, ils vont travailler avec telle ou telle partie de l'équipe. Donc il ne s'agit pas de casser les silos en termes de hiérarchie, il ne s'agit pas de détruire le département marketing, l'engineering, de tout mettre ensemble. Chacun continue à travailler avec sa spécialité, avec ses collègues, etc. Mais on travaille dans le cadre d'un produit.
Donc, quelqu'un en marketing va être dédié au produit X, une équipe engineering à ce produit-là, quelqu'un à la finance, etc.
Et en fait, c'est un flot. C'est un flux.
C'est pour ça que je trouvais intéressant d'en parler ici. C'est parce que... Moi, c'est ma façon de représenter un Kanban. Alors, je ne sais pas si ça vous parle. Mais en gros, moi, j'avais du mal à visualiser les doubles colonnes. Vous savez, to do, done, to do, done, to do, done. En fait, moi, je préfère présenter ça comme ça. Ça, c'est le to do. Et ça, c'est le en cours, en fait. On est en train de le faire.
Et donc, en fait, ça rentre dans le système de Discovery. Par exemple, cette phase-là où on est en train de découvrir des choses. Donc, on a plein de trucs à découvrir.
Qui sont dans le backlog de la découverte. Et puis quand c'est en phase de découverte, c'est là. Et quand c'est découvert, hop, ça passe dans le backlog de la phase d'après. Et donc ça permet comme ça de visualiser ce qui est en cours, vraiment, et de ce qui n'est pas encore commencé, mais sur l'ensemble de l'entreprise. Ça permet de voir tous les projets qui sont en stand-by à tous les niveaux de l'entreprise, que ce soit en termes de discovery, que des choses qui sont prévues d'être supprimées du produit. Ça permet de visualiser de manière assez simple l'ensemble du processus. Chacun de ces processus peut être détaillé eux-mêmes. C'est-à-dire que là, c'est la phase de développement. Dans la phase de développement, il y a, pourquoi pas, le backlog ou le Kanban de l'équipe de développement. C'est juste un zoom, une façon de voir l'activité de l'entreprise en termes de développement produit. On peut en faire un par produit ou un pour l'ensemble des produits de l'entreprise, peu importe le niveau de zoom, mais au moins on voit tout. Et donc voilà, ça bouge tout simplement.
Chaque phase correspond à une activité particulière. C'est pour ça qu'on est vraiment dans un flot. Ici, c'est une phase de discovery. Ici, c'est une phase de design. Ici, c'est une phase de développement. Et on dépile. Alors vous êtes familier avec ces notions de flux, de WIP, de Q, etc. Et bien moi j'ai repris ça en fait. C'est-à-dire que ce système-là permet de définir des limites minimum et des limites maximum pour s'assurer qu'on est toujours dans un rythme.
De développement de fonctionnalités. Donc c'est ça qu'on va piloter, s'assurer qu'on est toujours pour chacun des systèmes dans un mode où on a suffisamment de choses à faire dans le pipe, et on déroule. Et là, qu'est-ce qu'on voit? On voit que si on a défini une borne maximum arbitraire, comme je l'ai dessiné ici, on voit qu'il y a trop de choses en discovery, trop de choses qui doivent être lancées.
Donc il y a un problème, il faut s'arrêter, il faut descoper, ou il faut réorganiser un petit peu les équipes, parce que ça veut dire que ça ne coule plus, entre guillemets, dans le flux de développement. C'est-à-dire qu'on ne sort pas les choses assez vite. On est toujours dans un rythme de développement de fonctionnalités, donc c'est ça qu'on va piloter, s'assurer qu'on est toujours pour chacun des systèmes
dans un mode où on a suffisamment de choses à faire dans le pipe, et on déroule. Et là, qu'est-ce qu'on voit? On voit que si on a défini une borne maximum, arbitraire comme je l'ai dessiné ici, on voit qu'il y a trop de choses en discovery, trop de choses qui doivent être lancées. Donc il y a un problème, il faut s'arrêter, il faut descoper ou il faut réorganiser un petit peu les équipes parce que ça veut dire que ça ne coule plus dans le flux de développement. C'est-à-dire qu'on ne sort pas les choses assez vite.
L'intérêt aussi, c'est qu'il faut contraindre ces phases par des contraintes arbitraires de temps. C'est-à-dire qu'il faut se fixer, de dire, moi, la phase de discovery pour tel projet, telle initiative que je veux lancer, je me donne trois semaines, pas plus. On se force à se contraindre par le temps.
Et on avance comme ça pour le développement, on va se donner deux mois. Mais au bout de deux mois, on arrête. Donc en gros, on arrive avec un projet, on a deux mois pour expérimenter ça, on découpe en sprint, etc. Mais au bout de deux mois, on arrête, il faut lancer. Donc ça force à avancer.
Puis bien sûr, ça peut gérer plusieurs équipes. C'est-à-dire qu'ici, qu'est-ce qu'on est en train de dire? On est en train de dire qu'il y a quatre choses, quatre features en train d'être développées, quatre expérimentations en cours. Ça peut tout à fait être quatre équipes différentes. Donc ça peut tout à fait scaler en fait. Moi, chez le client pour qui je travaille en ce moment, il y aura cinq équipes en place qui vont pouvoir prendre comme ça des projets en parallèle. On pourrait très bien en avoir 7, 9, 10, 15, ça ne pose aucun souci. Chaque équipe est complètement indépendante et prend une expérimentation et la lance. Quand je dis expérimentation, c'est au sens large, c'est-à-dire que ça peut être aussi bien changer la couleur d'un bouton que lancer une vraie fonctionnalité.
Tout est expérimentation en fait. Même si on se dit, il faut absolument cette fonctionnalité, on sait qu'on va la garder. En fait, non, on ne sait pas. Il faut prendre pour acquis que potentiellement, on va la jeter parce que potentiellement, ça ne va pas marcher. Potentiellement, ça va être un four. Donc il faut se laisser la possibilité de l'enlever. Donc tout est expérimentation. Donc d'avoir ce mindset-là, ça change complètement l'organisation. Et donc voilà, c'est pour toute l'entreprise. Ça, c'est un tableau qui peut être visible pour l'ensemble de l'entreprise. On voit où on en est dans nos développements produits.
Donc la clé ici, c'est la rapidité. C'est pour ça qu'on se contraint par le temps, on se force à se contraindre par le temps dans les phases de développement.
D'apprendre, bien sûr, il faut qu'on apprenne des résultats dans la phase d'improvement, on va se rendre compte qu'il se passe des choses, et donc il faut essayer de collecter toutes les informations qu'on peut, et d'être focus. C'est-à-dire que plutôt que de travailler, comme je le vois beaucoup, sur une équipe de 25 ingénieurs qui travaillent sur 20 projets en même temps, de se forcer à travailler que sur quatre projets, mais de les faire dans un laps de temps très court et de les sortir.
Donc vous êtes familier avec l'idée de découper en sprint, etc. Là, l'idée, c'est que oui, on va découper en sprint, mais qu'on se donne la possibilité que s'il y a d'autres projets qui arrivent, qu'on s'arrête. Un projet a été prévu pour faire six sprints. On ne va en faire que trois, mais au moins les trois sprints qui ont été faits, ils ont vraiment délivré de la valeur et on va être capable de tester ça. On va être capable de l'exposer au marché et de voir ce que ça donne. Donc ça renforce, entre guillemets, à remettre de la valeur dans les sprints et à s'assurer que ce qu'on sort, ça a vraiment de la valeur. Parce que potentiellement, on va s'arrêter là, vraiment.
Je vais... Hop!
C'était juste un focus sur les différentes phases.
La phase de découverte, c'est pour dire un peu qui travaille dans ces phases-là. La phase de découverte, c'est le product manager, c'est le UX manager, l'engineering aussi. C'est aussi une des grandes différences, c'est qu'on fait intervenir des responsables du développement très très tôt dans les phases de découverte pour participer.
Aux enquêtes, aux clients, avec les clients, etc. On fait aussi intervenir la finance, on fait intervenir la BI, pour avoir des datas, déjà des analyses, pour récupérer des infos. Et là, l'idée, c'est quoi? C'est de faire de la découverte d'opportunités, des enquêtes, définir la vision, la stratégie. C'est très, très large. On ne développe quasiment pas, mais on va essayer d'explorer un peu ce qu'on pourrait faire, tout simplement. Donc là, il y a plein d'outils pour ça. Certains que j'ai développés, d'autres que j'ai récupérés d'autres méthodes, et j'en ai fait un tout cohérent. Dans la phase de design, là, il y a le produit, le UX, toujours l'engineering, un petit peu. Et là, on va commencer à faire du prototypage, des maquettes, des interviews, on va commencer à montrer des choses.
Dans la phase de développement, vous connaissez tous, je ne vais pas rentrer dans le détail, si ce n'est qu'il y a une clé qui est assez importante, c'est ce point-là, c'est que le rôle de l'engineering dans la phase de développement
n'est pas que de développer le feature, la fonctionnalité ou le produit. C'est d'améliorer et de développer en permanence le framework. Qui va permettre de lancer des expérimentations de plus en plus vite, de plus en plus rapidement et de délivrer, c'est l'intégration du déploiement continu, mais au-delà de ça, c'est construire les briques qui vont permettre de développer des expérimentations par la suite. Chez Yahoo, nous, par exemple, on avait un outil qui nous permettait, quand on développait une fonctionnalité, de cibler une catégorie de la population, de lancer l'expérimentation que sur cette catégorie-là, et de ne pas le faire apparaître pour les autres, et de récupérer des analyses. Et ça, c'était en 2004, même avant. L'entreprise était construite autour de ça, parce qu'on savait l'intérêt de l'expérimentation. Donc au-delà de simplement développer des fonctionnalités, on avait développé un moteur à expérimentation. Et ce que nous, on avait fait, comme je vous le disais, nous, ce qu'on avait fait chez Yahoo, Google avait fait ça dix fois plus vite, et dix fois mieux, et dix fois plus puissant. Moi, je suis à peu près sûr aujourd'hui que chez Google, les expérimentations se font de manière automatique. C'est-à-dire que c'est des robots qui expérimentent. Il n'y a même plus un product manager qui dit« Tiens, je vais tester la couleur du bouton, etc. » Je suis à peu près sûr que ça peut se faire quasi. automatiquement. Et s'il y a un truc intéressant qui sort, hop, ça remonte et là il y a un product manager qui regarde et qui va investiguer. Mais je suis sûr et certain que ça se fait aujourd'hui par des robots quasiment. Donc la phase de lancement elle est très importante, elle est souvent très négligée. Quand on lance une nouvelle fonctionnalité, même en test, et surtout en test, il faut faire super attention à la communication. Il faut lancer ça auprès d'une communauté, ou auprès d'une... Si on n'a pas la capacité à lancer que sur une petite partie de la communauté des utilisateurs, il faut communiquer clairement pour dire, attention, c'est un test. Sinon, c'est compliqué. Il faut être connecté en avance avec les utilisateurs pour pouvoir aller chercher du feedback. Parce qu'il n'y a rien de pire que de lancer une fonctionnalité et ne pas avoir de retour. Ça ne sert absolument à rien. Donc tout ça, il faut le prévoir en amont. C'est pour ça qu'on travaille avec le marketing avant le développement. Parce qu'on prépare un plan de lancement avec eux. Donc là aussi, il y a plein de choses à mettre en place. Enfin, la phase d'amélioration continue, c'est celle qui m'intéresse le plus. Il faut essayer de réduire au minimum ce qu'on va sortir. Ce fameux MVP que vous connaissez peut-être dans le Lean Startup, c'est sortir ce truc-là, le lancer, le mettre à disposition de la communauté. Et seulement à partir de là, le travail vraiment intéressant commence parce qu'on va l'améliorer en fonction des retours, analyser. jusqu'à trouver le bon équilibre. Et si on n'arrive pas à trouver le bon mix, Il faut sortir la fonctionnalité. Il faut laisser de la place à la prochaine expérimentation. Ce n'est pas forcément un échec, entre guillemets, de retirer une fonctionnalité. Au contraire, ça peut nous permettre d'apprendre des choses sur nos clients, et ça peut aussi permettre de garder un code propre, entre guillemets, de... Non, c'est la partie remove, pardon, je me suis trompé. Sur la partie improvement, ce qui est très important, c'est de mesurer. Et c'est la partie quantitative et qualitative. C'est-à-dire que c'est bien de mesurer. Il faut mesurer, il faut avoir des infos qui remontent du système, mais il faut toujours comparer ça avec des observations réelles. C'est-à-dire que quand on lance une fonctionnalité, on va voir, tiens, il y a un taux de clic qui a augmenté, mais tout de suite après, il faut faire des tests utilisateurs pour voir pourquoi les gens, effectivement, dans un petit échantillon, pourquoi les gens cliquent et avoir du retour qualitatif. Ça permet de se mettre à l'abri de fausses mesures, de mesures mal placées, de mesures mal mesurées, de choses qu'on ne pourrait pas comprendre. Il ne faut pas se baser que sur les chiffres, il faut se baser sur des études.
Et enfin, la partie suppression. Ça arrive assez peu, mais on l'a vu récemment sur LinkedIn. LinkedIn, quoi qu'ils l'ont déjà fait deux, trois fois récemment, ils disent on va supprimer telle partie du site parce que ça ne marche pas aussi bien qu'on voulait.
Ça arrive assez souvent. En France, on ne le fait pas du tout. Parce que l'idée, c'est de se dire, après tout, on a payé pour, on ne va pas l'enlever. C'est quand même bête. Mais ce qu'on oublie, c'est que le fait de garder quelque chose, ça coûte de l'argent. Donc non seulement le... métier entre guillemets qui vous dit on a payé on va pas l'enlever ce qu'ils ne savent même pas c'est qu'en fait ils continuent à payer pour ce truc et ça ils le voient pas donc le fait de leur dire mais vous savez qu'en le gardant vous ça vous coûte encore plus cher souvent ils sont un peu plus d'accord pour l'enlever et l'idée de supprimer des fonctionnalités du code vraiment les supprimer c'est à dire pas simplement de désactiver les boutons ou de cacher des pages mais de d'enlever le code, ça fait que le produit est plus« lean», il est plus propre, il est plus durable. Et ça aussi, il faut le prévoir dès le début. C'est-à-dire que quand on développe une fonctionnalité, il faut prévoir qu'on va l'enlever au niveau du code. Il faut que ce soit fait pour être enlevé. Donc c'est aussi ça qu'il faut penser. En amont.
Donc voilà, c'est ce que je vous disais sur la philosophie de...
Des grands groupes qui font ça aux États-Unis, c'est d'expérimenter de plus en plus, mais dans une optique de supprimer aussi de plus en plus de choses. Ce n'est pas expérimenter pour expérimenter. C'est vraiment de garder que ce qui marche vraiment très bien.
Pour finir, c'est quoi les conditions pour que ça marche? Pour que ça fonctionne, il faut déjà avoir une organisation produit. C'est-à-dire qu'un, idéalement, il faut travailler dans une entreprise qui vend des produits.
Si vous êtes dans un département engineering, IT, c'est plus compliqué, mais c'est faisable. Il y a de plus en plus de départements IT qui se mettent en position d'éditeur. Donc c'est tout à fait envisageable. En revanche, ce qui n'est pas négociable, c'est que le CEO ou le manager sponsorise ce type de choses. Dans la dernière conférence qu'on avait organisée, on avait le retour d'un CEO d'une agence de voyage en ligne.
Il a dit« c'est moi qui ai poussé pour avoir une organisation produit». Ça ne peut pas venir de l'équipe d'engineering ou du marketing. Tout simplement parce que j'ai essayé de le faire dans un grand e-commerce en France. Quand j'ai proposé ça au directeur général, il y a déjà 4 ans. Il y a le directeur marketing qui m'a dit non, non, non, tu es en train de m'enlever des prérogatives. Et puis il y a le directeur engineering qui m'a dit non, non, non, tu es en train de m'enlever des prérogatives. Donc ni le marketing ne voulait, ni l'engineering ne voulait, et le DG ne voulait pas non plus. Parce qu'au lieu de taper sur la tête de cinq personnes, ça lui faisait six têtes sur lesquelles il fallait taper. Donc ça ne l'intéressait pas. Préférer avoir un petit groupe de personnes plus resserrées. Bon voilà, c'est des choses qui doivent venir du haut et donc il faut effectivement faire un gros travail de lobbying. Moi je m'y emploie, je commence à parler à des responsables du digital, donc je commence à être entendu à ce niveau-là, en même temps voilà, c'est... C'est aussi le bon moment, je pense.
Donc c'est en train de changer. Ça va venir. L'organisation produit va venir. Maintenant, intégrer de l'innovation dans un processus de développement produit, ça vient, mais tout doucement. Et il faut une méthode pour faciliter la compréhension de tout ça. Donc moi, juste pour résumer tout ce que je vous explique, je ne vous ai pas montré tous les outils, toutes les méthodes qui sont dans chaque phase, parce que ce serait beaucoup trop lent et un petit peu ennuyeux, mais pour chaque phase, il y a des outils, des méthodes. Quand je dis des outils, ce n'est pas des outils en ligne, c'est des feuilles Excel bien faites, des choses, des façons de mesurer, des façons de faire des interviews, des outils que vous connaissez comme l'impact mapping, bien utilisés à certains moments, ça a du sens. Il faut l'utiliser à certains moments dans un... certains contextes. Le Lean Canvas que vous connaissez de Running Lean, dans la partie de Discovery, c'est très utile. Il ne faut pas l'utiliser n'importe comment et à n'importe quel moment. Donc moi ce que j'ai fait, c'est que j'ai documenté pour moi ce framework et ce processus-là, parce que je l'utilise d'ailleurs actuellement à partir de zéro chez un grand compte. Et donc on le déroule actuellement.
J'ai réussi à unifier toutes ces méthodes que vous connaissez, j'ai réussi à leur donner du sens et à les organiser finalement les unes par rapport aux autres pour que c'est un sens et qu'on puisse les coordonner et pas qu'il y ait des querelles de chapelle entre moi je fais du startup, moi je fais autre chose. Non, tout ça, ça va dans la même direction.
Et puis, j'ai commencé à l'implémenter chez quelques clients. Et pour l'instant, ça marche. Moi, mon objectif pour 2015, c'est de continuer à initier cette culture au travers de l'association que j'ai montée, d'initier la culture de produit au sein des entreprises. Et j'aimerais donc... Réussir enfin à prendre le temps d'écrire tout ça dans un livre pour pouvoir mettre tout ce que j'ai appris ces dernières années et à essayer de le partager et puis pourquoi pas créer une communauté de pratiquants autour de ça parce que c'est comme le product management, j'ai vu une grande différence entre quand j'essayais de l'évangéliser moi-même dans les entreprises versus créer une association. Je pense que si vous êtes intéressé par essayer de tester ces différentes méthodes, essayer de le pousser dans votre entreprise,
Ce truc-là, il est ouvert, il a destination à être. ouvert et à être partagé.
Donc mon objectif, c'est de créer une communauté autour de cet outil. Donc voilà, si vous êtes intéressé, écrivez-moi. J'ai un blog que j'écris en anglais sur toutes ces découvertes, tout ce que j'essaye de pratiquer, et puis un compte Twitter, bien sûr, où j'essaie d'être assez actif.
Voilà.