Comment choisir des outils que votre équipe produit utilisera réellement

Lisez la transcription :

Nous testons la transcription de nos podcasts à l’aide d’un logiciel. Veuillez pardonner toute faute de frappe, car le robot n’est pas toujours exact à 100 %.

Hannah Clark : Rapidement, sans compter, pouvez-vous me dire combien d’identifiants vous utilisez actuellement au travail chaque semaine ? Si vous ne savez pas, mettez en pause et essayez de compter. Je parie que le nombre est choquant. En fait, un rapport 2024 de CloudZero a révélé que l’employé moyen utilise actuellement 36 services cloud par jour, et les équipes d’ingénierie en utilisent deux fois plus.

Fou, non ? Et voici une autre chose folle qui ne vous surprendra probablement pas. Selon une étude de CloudZero en 2023, plus de 53 % des licences SaaS ne sont pas utilisées. En d’autres termes, malgré le besoin constant de nos organisations en outils pour soutenir nos opérations uniques, nous gaspillons beaucoup d’argent dans des outils qui, pour une raison ou une autre, ne conviennent tout simplement pas.

Mon invité aujourd’hui est Moshe Mikanovsky, fondateur et coach produit principal chez Products for Good et co-animateur du podcast Product for Product. Ayant travaillé dans le produit et l’ingénierie logicielle depuis 1989, Moshe s’est surtout concentré ces dernières années à aider les équipes produits à faire de meilleurs choix concernant les outils à mettre en place.

Il est à noter que Moshe a développé un cadre complet pour aider les organisations à choisir les bons outils selon leurs besoins, ce qui permet d’augmenter l’adoption et la productivité tout en réduisant les dépenses inutiles. Nous abordons certains des points saillants de ce cadre qui peuvent vous aider à mieux choisir vos outils dès aujourd’hui. Allons-y.

Bienvenue sur le podcast The CPO Club. Je suis aujourd’hui avec Moshe Mikanovsky. Il est le fondateur et coach produit principal chez Products for Good.

Moshe, merci beaucoup de nous rejoindre aujourd’hui.

Moshe Mikanovsky : Merci de m’accueillir, Hannah.

Hannah Clark : Nous allons commencer comme d’habitude. Pouvez-vous nous parler un peu de votre parcours et de ce qui vous a amené là où vous êtes aujourd’hui ?

Moshe Mikanovsky : Oui, j’ai commencé en tant que développeur logiciel il y a bien des années. Pendant les 20 premières années de ma carrière, j’étais du côté de l’ingénierie. J’ai eu la chance de travailler pour des petites organisations ou sur le terrain, en relation avec des clients et des utilisateurs. Je pense que c’est comme ça que j’ai développé une certaine empathie envers les utilisateurs et leurs besoins.

À cette époque-là. Et puis après 20 ans, j’ai décidé de passer à la gestion de produit. C’est ce que je fais depuis 14 ou 15 ans. J’adore ça. J’aime parler de gestion de produit. J’aime aider les autres à construire des produits. Voir ce qui existe, ce qui fonctionne, ce qui ne fonctionne pas, apprendre de nouvelles méthodologies.

Tout ce qui touche au produit fait partie de ce qui me motive le matin.

Hannah Clark : Vous êtes au bon endroit alors.

Aujourd’hui, nous allons discuter d’un sujet qui, je pense, intéresse tout le monde : les outils. Comment les équipes produits peuvent prendre de meilleures décisions dans le choix des outils de leur organisation. Un souci chronique. Et c’est aussi un de vos domaines d’expertise. Qu’est-ce qui vous a initialement inspiré à créer le cadre de sélection de produit dont nous allons parler ?

Moshe Mikanovsky : Oui. J’ai un podcast que je co-anime depuis quatre ans maintenant avec mon ami Matt Green. Ça s’appelle The Product for Product.

Dans ce podcast, nous couvrons principalement les outils utilisés par les gens du produit. Cela nous a toujours intéressé, chacun pour des raisons différentes : pour Matt, lors de son passage à la gestion de produit, pour moi, dans l’expérimentation de différents produits et le choix des produits, car personne d’autre ne le faisait pour moi et je devais m’en charger.

C’est toujours très intéressant de voir ce qui existe. Donc c’est ça qu’on fait dans le podcast. Et c’est en enregistrant les différents épisodes, sur différents sujets et produits à thèmes, que je me suis rendu compte qu’il y avait des points communs à pourquoi les gens utilisent tel ou tel produit, ce qu’ils aiment, ce qu’ils n’aiment pas.

Nous avons toujours interviewé des utilisateurs, sauf si c’est une startup. Dans ce cas, il n’y a pas beaucoup d’utilisateurs alors nous invitons le fondateur, mais majoritairement, ce sont les utilisateurs. Ils possèdent déjà des insights, des connaissances sur l’usage, ce qui fonctionne, ce qui ne fonctionne pas. De là, j’ai accumulé beaucoup de raisons et de critères à surveiller, ce qui m’a amené à tout rassembler dans un cadre que j’adore partager.

Hannah Clark : Selon vous, si nous voulons évoquer certaines des erreurs que les gens commettent avant de passer à la bonne façon de faire ou à un cadre adapté à leur organisation, quelles sont les erreurs les plus fréquentes que commettent les équipes produits à l’heure de choisir de nouveaux outils, et quelles en sont les conséquences ?

Moshe Mikanovsky : Oui, je pense que cela vient surtout de leur manière de choisir, sans chercher un véritable ajustement entre l’outil et leur organisation. Ce serait le premier point — et c’est l’essence du cadre — mais aussi, ils ne comprennent pas vraiment les outils avant de les choisir. C’est quelque chose qui revient souvent.

Nous sommes toujours très excités par un nouvel outil. Nous découvrons les différentes fonctionnalités. Nous croyons qu’il répondra à nos besoins, puis une fois implanté, on réalise que ce n’est pas exactement ce qu’on imaginait. Parfois, nous ne voyons que le marketing du fournisseur, qui ne nous donne pas toute l’histoire.

Ou les démos ne montrent pas tout, ou il y a des pièges que nous découvrons en le pratiquant. Donc, ce que j’observe fréquemment : ce n’est pas le meilleur ajustement pour l’organisation, et pas assez de compréhension sur la façon dont le produit fonctionnera vraiment pour elle.

Hannah Clark : Oui, c’est logique.

Alors, passons à votre processus de sélection. Votre cadre commence par identifier les problèmes, puis il y a priorisation, présélection, et enfin comparaison des outils. Donc, pas mal de travail en amont avant même d’entrer dans la phase de comparaison proprement dite.

Pourquoi ce travail préliminaire est-il si important avant de se lancer dans la comparaison des fonctionnalités ?

Moshe Mikanovsky : Je pense que c’est comme pour n’importe quel autre produit. J’essaie d’aborder, en tant que personne produit depuis des années, tout ce que je fais comme un produit. J’ai donc procédé ainsi ici. Comprendre le vrai problème qu’on veut résoudre est très important.

Nous ne voulons pas développer des fonctionnalités pour une solution qui ne sera jamais utilisée. De même, nous n’avons pas besoin de fonctionnalités spécifiques s’il n’y a pas de problème précis à résoudre. Le fait que tout le monde fasse quelque chose ne veut pas dire que vous devez le faire aussi, ni que la méthode des autres conviendra à votre organisation.

D’où l’importance du travail préliminaire avant d’examiner toutes les fonctionnalités : comprendre les vrais problèmes à résoudre, comprendre le travail, la mission de votre équipe produit, ce pour quoi vous avez besoin de ces outils. Puis, quelles sont les priorités parmi tout cela ?

Parfois, on ne peut pas acheter tous les produits d’un coup. Parfois, même obtenir du budget pour un seul produit est déjà beaucoup. On doit donc prioriser — quel est le plus gros problème du moment ? Peut-être que ce n’est pas toujours un problème, mais quelque chose qui nous prend beaucoup de temps à faire, ou il y a du désordre et il faut y remédier, etc.

Et sur la base de ce plus gros problème, prioriser et dire « c’est vraiment ça qu’on doit chercher d’abord… », puis créer une feuille de route pour sélectionner et mettre en œuvre les outils.

Hannah Clark : J’aimerais aborder un point particulier de votre processus de comparaison, à savoir la « philosophie du produit », qui est le premier critère ici.

Qu’entendez-vous par philosophie du produit et pourquoi est-ce important ? Quels types de différences cela recouvre-t-il, et comment cela impacte-t-il la compatibilité d’un outil avec une organisation ?

Moshe Mikanovsky : Oui, parmi tout ce que j’ai pu observer en parlant avec les gens, et également d’après mon expérience et celle de mon co-animateur Matt, c’est qu’on est tous différents dans notre manière de travailler, de communiquer, de mettre l’accent sur telle ou telle chose.

C’est pour cela que j’inclus la philosophie. Par exemple, certains veulent un produit unique qui fait absolument tout, où toutes les fonctionnalités nécessaires seront présentes. On n’a pas besoin d’en implémenter d’autres. Mais souvent, ces produits-là ne vont pas très loin dans chacune des fonctionnalités, ils optent plutôt pour la largeur.

D’autres au contraire, leur philosophie c’est « je veux le meilleur du meilleur pour chacun de mes besoins spécifiques ». Je veux que tout soit intégré, que tout communique ensemble, mais cela ajoute également de la complexité à la solution. Voilà un exemple du type de philosophie : qu’est-ce que vous êtes, en tant qu’organisation ?

Parfois, il est difficile de définir cela si vous ne savez pas comment fonctionne votre organisation, qui prend les décisions, mais c’est pourtant important pour cibler le bon produit ou présélectionner les outils. Une autre de ces philosophies, c’est : souhaitez-vous un produit flexible, ou déterministe ?

Certains produits vous permettent de créer n’importe quel workflow, définir n’importe quel champ, etc., ce qui est parfois générique mais flexible. Chaque organisation l’implémentera d’une manière un peu différente. D’autres produits dans la même catégorie peuvent être très déterministes : « Non, vous devez fonctionner de cette façon, nous ne l’avons développé que comme ça ». Je ne dis pas qu’un modèle est meilleur que l’autre. Parfois, c’est une question de maturité d’organisation — pas forcément lié à l’ancienneté, mais à la maturité de ses processus. Par exemple, si vous ne savez pas encore exactement comment faire des sprints ou du backlog grooming, prendre un produit très déterministe pourra vous enseigner le processus. Mais il ne vous l’enseignera qu’à une seule manière alors qu’il y a de nombreuses approches possibles. Une fois plus matures, il sera plus facile d’envisager un produit plus flexible. Voici donc des critères que je surveille dans le cadre, avant même d’envisager les fonctionnalités : quelle est votre culture, quels types de produits correspondent le mieux à votre organisation, etc.

Hannah Clark : En parlant de flexibilité, il y a un autre critère sur lequel je voudrais vous interroger, qui concerne les ressources d’ingénierie requises en continu. Comment les équipes doivent-elles évaluer les ressources nécessaires à l’intégration des différents outils, et comment cela peut-il impacter le succès sur le long terme ?

Moshe Mikanovsky : Cela relève aussi de la philosophie. Ma philosophie pour construire des produits, tant pour ma propre entreprise que lors de conseils à d’autres sociétés, c’est que nos ingénieurs doivent vraiment se concentrer sur la valeur ajoutée, et ne pas réinventer la roue sur des choses déjà développées des millions de fois.

De la même façon, quand j’ajoute des fonctionnalités à mon produit — messagerie intégrée ou analytics produit, par exemple — qui existent déjà dans des outils spécialisés, je ne veux pas que mes développeurs se soucient de ça. Je préfère une intégration simple et ensuite oublier, pour donner la main au chef de produit ou à d’autres profils non techniques pour paramétrer le reste afin d’en tirer toute la valeur. Pourtant, certains outils dans la même catégorie, pour la messagerie in app ou pour les analytics, nécessitent un recours constant aux développeurs, que ce soit pour définir les événements à remonter ou ajuster l’apparence de la messagerie intégrée.

Et pour moi — c’est un point de vue personnel, ce n’est ni bon ni mauvais — c’est une perte de temps pour les développeurs. Je préfère qu’ils travaillent sur la valeur propre à notre entreprise.

Hannah Clark : D’accord. Puisqu’on parle de culture d’entreprise et d’aspects plus uniques, vous avez aussi évoqué l’impact des valeurs d’entreprise et des styles de communication sur le choix des outils, ce que je trouve intéressant.

Auriez-vous une histoire illustrant la manière dont ces éléments impalpables influencent le succès d’un outil en entreprise ?

Moshe Mikanovsky : Oui, bien sûr. Je peux vous citer un exemple où j’ai travaillé, et où nous avions beaucoup de mal avec la communication asynchrone. Cela m’irritait car nous étions en télétravail et on pourrait penser qu’à distance, l’async aide à mieux collaborer, ailleurs que dans des réunions permanentes.

Pourtant, nous étions toujours obligés de faire des meetings pour avancer. Nous avions choisi, par exemple, un système de backlog (je crois que c’était Jira, mais c’est vrai pour d’autres outils), où on documente ses epics dans un doc Confluence, et ses stories avec critères d’acceptation.

On s’attendrait à ce que tout le monde parcoure ces docs, commente, collabore en asynchrone… mais ça ne fonctionnait pas. À chaque fois qu’on me disait « ah je n’avais pas vu ça » ou que ce genre de sujets remontaient en réunion, je pensais : mais tout était noté là-dedans !

C’était un problème de culture qui impactait la bonne utilisation des outils. J’avais parfois l’impression de nager à contre-courant. J’ai même fait une session pour expliquer ce qu’est la communication asynchrone et son importance. Je ne sais même plus si ça a aidé ou pas.

C’est ça que je veux dire : la façon dont fonctionne votre organisation peut empêcher un outil d’apporter tous ses bénéfices, car un outil ne va pas (de lui-même) transformer le mode de collaboration. Il peut soutenir de meilleures pratiques, à condition qu’on l’utilise vraiment. Il peut aider à améliorer les processus… ou pas si ceux-ci ne collent pas à l’outil.

En général, je recommande donc d’identifier d’abord les contraintes culturelles et de choisir en conséquence.

Hannah Clark : C’est beaucoup plus clair.

Revenons aux comparaisons de fonctionnalités, maintenant qu’on a parlé du travail en amont et des facteurs à considérer avant d’entrer dans le détail de chaque outil.

Beaucoup d’équipes comparent d’abord les fonctionnalités et les prix lors de l’évaluation des outils. Vous avez dit plus tôt que ces critères arrivent tard dans votre grille d’analyse. Pourquoi ?

Moshe Mikanovsky : Surtout parce que je ne veux pas que les gens se concentrent d’abord sur ce que permet de faire le produit, mais plutôt sur les résultats attendus.

Les fonctionnalités sont ce qu’il y a de plus facile à comparer. Les fournisseurs vous diront qu’ils ont telle ou telle fonctionnalité. Mais quand on regarde dans le détail, — parfois ces détails sont publics, parfois non, il faut fouiller — on constate que ce n’est pas toujours ce que l’on attendait.

Parfois, ils utilisent une terminologie différente, ou le prix varie énormément selon l’accès à telle ou telle fonctionnalité. Ce n’est pas grave, mais c’est à nous, consommateurs, de bien creuser pour trouver le bon produit.

Encore une fois, l’essentiel, c’est de rechercher un choix basé sur les résultats escomptés, pas juste la liste de ce que le produit sait faire. Ce n’est pas parce qu’un outil propose plus d’options qu’il est forcément meilleur pour nous.

Hannah Clark : J’aimerais maintenant aborder peut-être le point le plus frustrant lorsqu’on met en place un nouvel outil : faire adopter cet outil par tous, et aligner toute l’organisation sur la façon dont il doit être utilisé.

Surtout après autant de travail pour trouver le bon outil, faire toutes ces adaptations, on doit encore convaincre tout le monde de l’utiliser, et de la même façon. Quelles sont les principales stratégies pour assurer une adoption réussie à l’échelle de l’organisation ?

Moshe Mikanovsky : La première chose, c’est de sélectionner le bon outil, ou le moins inadapté possible (parce qu’il y a toujours des compromis). Le processus de sélection en lui-même est complexe. Ça dépend de qui en a la responsabilité, de la gouvernance en place.

On peut avoir des opposants dès cette étape. Je n’ai pas encore de recommandation définitive sur ce point, c’est un sujet auquel je réfléchis et je prévois d’étendre le cadre à l’avenir, notamment en glanant des retours d’expériences. Car si on implique beaucoup de gens dans la sélection, cela peut prendre beaucoup de temps, et ensuite : a-t-on un consensus ou se contente-t-on d’un consentement de principe ? Encore une question culturelle.

Se pose ensuite la question de la propriété de l’outil : pas seulement pour la sélection ou le déploiement, mais sur qui l’utilise et qui le fait vivre. Historiquement, beaucoup d’outils étaient sous la responsabilité du service informatique, car il fallait les installer. Donc l’IT « possédait » les outils mais ne se souciait pas toujours de leur implémentation effective — il fallait donc un champion ailleurs dans l’organisation. Cette question de la propriété est aussi importante.

Aujourd’hui, dans certains cas, le « Product Ops » facilite la donne, parce que ce service a le bon positionnement pour standardiser les outils, comprendre les besoins transverses, les différences entre équipes, les difficultés d’implémentation, etc. Ces obstacles peuvent être liés à la personnalité, à la gestion de projet, à bien d’autres facteurs.

C’est comme pour n’importe quel produit : il faut travailler pour l’adoption côté client. Ce sont des outils B2B, alors si vous développez vous-même ce genre de produits, vous savez de quoi je parle, et cela favorise également l’empathie. Si ce n’est pas le cas, cela crée parfois une déconnexion. Ce n’est pas facile : cela dépend de la taille de l’organisation, du nombre de projets, de produits en circulation… Mais si je devais résumer, je dirais : Qui prend la décision ? Qui possède l’outil ? Quelle gouvernance ? Comment les équipes acceptent-elles ces décisions et comment les outils sont-ils mis en œuvre, y compris via des itérations successives (on ne déploie pas tout d’un coup, on teste, on adapte, on évolue, comme pour un produit classique).

Hannah Clark : Oui, ça fait sens. Oui, organiser un onboarding plus progressif… Vous avez au moins plus d’accès à vos utilisateurs, c’est un avantage !

Moshe, merci beaucoup d’avoir été avec nous aujourd’hui. C’était très instructif. Je pense que cela va vraiment aider parce que nous avons tous, à un moment ou à un autre, à choisir de nouveaux outils, et toute la démarche pour les déployer est un sacré parcours. Nous vous remercions pour vos conseils. Où peut-on en savoir plus sur le cadre que vous avez développé et échanger avec vous en ligne ?

Moshe Mikanovsky : Oui. D’abord, merci à vous, c’était un plaisir ! Vous pouvez tous me retrouver sur LinkedIn, cherchez mon nom de famille Mikanovsky. Mon site web est productsforgood.co. Le cadre est disponible sous forme de tableau Miroverse ; le lien est sur mon site rubrique « resources ».

Je vous le partagerai aussi pour que vous puissiez le mettre en description d’épisode, je suis ravi de le partager avec tous. Vous pouvez le copier, l’utiliser, il y a des explications, beaucoup de ressources dans le framework comme un Airtable listant les produits par catégorie.

C’est toujours en cours de développement car je découvre sans cesse des nouveautés. Si vous voyez qu’il manque un produit, n’hésitez pas à me contacter sur LinkedIn, je serais ravi d’échanger.

Hannah Clark : Oui, ce sera un plaisir de le partager. Merci beaucoup pour toutes les ressources et votre temps.

Moshe Mikanovsky : Merci à vous, Hannah, vraiment.

Hannah Clark : Merci de nous avoir écoutés. Pour d’autres conseils, guides pratiques et tests d’outils, abonnez-vous à notre newsletter sur theproductmanager.com/subscribe. Vous pouvez entendre plus de conversations comme celle-ci en vous abonnant au CPO Club sur votre plateforme de podcasts préférée.