Create 2024-08-22-les-6-erreurs-du-product-management.md

_articles/fr/2024-08-22-les-6-erreurs-du-product-management.md

@@ -0,0 +1,78 @@
+---
+contentType: article
+lang: fr
+date: '2024-08-22'
+slug: 6-erreurs-product-management
+title: Les 6 erreurs du Product Management
+excerpt: >-
+  Aujourd’hui on parle de product management à tout va, pour qualifier tout et n’importe quoi. Comment identifier et éviter les premières erreurs ? La liste n’est pas exhaustive mais vous permettra déjà de mieux appréhender votre méthodologie produit. 
+categories: [agile]
+authors:
+  - mae
+cover:
+  alt: Les 6 erreurs du Product Management
+  path: /imgs/articles/2024-07-23-tester-spark-avec-pytest/cover.jpg
+keywords: 
+- product management
+- product manager
+- product owner
+---
+
+Aujourd’hui on parle de product management à tout va, pour qualifier tout et n’importe quoi. Un peu comme de l’agile il y a encore quelques années, sous ce prétexte il fallait être flexible et s’adapter à tous les caprices de la direction ou des stakeholders.
+
+Et comme pour les dérives autour des organisations agiles, cela se fait de nouveau sans prendre en considération le cœur du fonctionnement d’un bon product management. Ce qui entraîne assez logiquement la mise en place d’organisations produits sur des bases bancales, non adaptées et souvent vouées à l’échec. 
+
+Comment identifier et éviter ces erreurs ? La liste n’est pas exhaustive mais vous permettra déjà de mieux appréhender votre méthodologie produit. 
+
+## Ne penser qu’aux outputs 
+Le premier biais dans lequel tombent aujourd’hui les organisations aujourd’hui sans expérience en product management ou sans product manager formés au produit est de se focus uniquement sur la livraison de multiples features sans réfléchir à la valeur ajoutée de cette production. 
+
+Et tout notre intérêt en tant que PM est de pouvoir livrer de la valeur, sprint par sprint ou release par release aux utilisateurs finaux. Sans quoi l’utilisabilité et l’adoption de l’outil ne peut être garantie, et donc le temps investi dans le développement ne peut être valorisé.
+
+Posez-vous donc toujours la question du “Pourquoi” une fonctionnalité est priorisée dans votre backlog ou présente dans votre roadmap. Si vous n’avez pas d’enjeu business ou utilisateur à aligner en face, c’est que cette fonctionnalité n’a pas sa place dans la “To do” de vos développeurs. 
+Dans un registre un peu moins extrême, si vous estimez qu’elle n’est pas là pour rien, assurez vous de la valoriser afin de pouvoir la prioriser correctement avant de l’embarquer.
+Ce qui fait une bonne transition pour le biais suivant …
+
+## Priorisation sur des critères subjectifs
+En effet, en parlant de priorisation, il ne faut pas faire rentrer la part subjective dans le calcul. 
+Soit parce que votre client pense savoir ce qui est bon ou pertinent pour ses utilisateurs à leur place (ou vous-même pouvez prendre le raccourci d’avoir ce positionnement). Ce qui peut partir d’une bonne intention mais finalement ne permet pas de prouver que ces fonctionnalités subjectives auront la moindre valeur. 
+
+Soit parce qu’un de vos utilisateurs expriment un souhait sans que celui-ci n’ait été challengé ou même aligné sur la stratégie de l’entreprise. 
+
+Enfin, autre raccourci souvent vu et pris dans nos domaines et qui n’apporte que très rarement la valeur escomptée : suivre une tendance du marché sans vérifier qu’elle aura de la valeur pour votre entreprise ou pour vos utilisateurs. 
+
+En résumé, vérifiez toujours lors de la priorisation de vos fonctionnalités qu’elles le sont pour les bonnes raisons, en recroisant le besoin et les apports business visés.
+Ce qui nous amène à notre troisième biais…
+
+## Oublier les enjeux business
+En tant que product manager il est en effet souvent bien plus simple d’identifier et prioriser ce qui apportera de la valeur directe à nos utilisateurs finaux. Parce que celle-ci est parfois plus tangible, directement exprimée ou mise en lumière par des tests ou interviews utilisateurs. Il est donc aisé de ne pas pousser la réflexion plus loin en mettant en perspective la valeur qu’aura une feature pour l’entreprise par rapport à une autre. 
+
+L’important de recroiser les besoins utilisateurs ainsi que les apports business est de ne pas oublier qu’un des objectifs à travers la conception, le développement et globalement la production d’un produit est de permettre une rentabilité pour l’entreprise elle-même. 
+Que ce soit financièrement, en faisant gagner du temps à ses ressources, pour permettre de se démarquer face à la concurrence, etc… Chaque entreprise aura toujours un objectif en investissant dans un produit. 
+
+N’oubliez donc pas de remettre en perspective votre roadmap et vos priorisations aussi en vous mettant à la place de votre entreprise.
+
+## Ne pas communiquer avec les utilisateurs
+Règle d’or qui peut paraître immanquable en tant que Product Manager, il reste néanmoins important de l’ajouter à la liste des biais et des erreurs faites par les organisations qui s'improvisent “Produit” aujourd’hui.
+On ne sait pas mieux que nos utilisateurs ce dont ils ont besoin, que ce soit en tant que PM, stakeholders ou métiers. 
+
+Ne passez donc pas à côté des interviews utilisateurs et si vous en avez l’opportunité des tests utilisateurs pré-développement sur wireframe ou prototype ou sur votre outil après implémentation. Les feedbacks que vous récolterez auront énormément de valeur et renforceront le lien entre équipe et utilisateurs. Vous remarquerez très vite par ailleurs que ces derniers, s’ils comprennent votre démarche et constatent du réel intérêt qu’on porte à leur besoin, ils seront toujours partants pour vous accompagner dans votre démarche.
+
+A ce titre, n’hésitez pas non plus à vous rendre directement sur le terrain pour être le plus en condition réelle avec vos utilisateurs ! 
+
+## Ne pas démontrer par l’exemple
+Avant de se lancer dans des chantiers trop conséquents, il est toujours préférable de penser petit et de tester auprès des utilisateurs un postulat avant d’y lancer la majorité des ressources. 
+
+Ce qui vous permettra par la même occasion de donner du poids à la production déjà livrée auprès des stakeholders et / ou métiers, et ce aussi afin de les rassurer avant de se lancer dans la suite. 
+Vos meilleures armes seront les feedbacks utilisateurs déjà récoltées à leur partager pour mettre en lumière l’importance de la nouvelle feature.
+Sans oublier les metrics qui seront importants d’avoir mis en place et suivi afin de valoriser cette fois-ci l’apport pour l’entreprise.
+Ce qui nous amène cette fois à notre dernière erreur …  
+
+## Ne pas penser KPIs dès la conception
+Quand on se lance dans le product discovery, puis la conception fonctionnelle des features à réaliser on pense tout de suite spécifications fonctionnelles, enjeu business, acceptance criteria, parfois spécificité technique en fonction de la latéralité de votre intervention par rapport à l’équipe, wireframes ou même maquettes détaillées, etc…
+
+Il est moins évident cependant de penser dès le départ aux indicateurs de performance et de réussite à mettre en place pour s’assurer de l’impact attendu de la fonctionnalité une fois développée. 
+Cela vous sécurisera aussi bien dans la priorisation de votre roadmap qu’auprès des stakeholders qui seront rassurés et vous accorderont toute confiance. 
+
+## Conclusion
+Pour conclure, ces quelques erreurs simples à éviter vous permettront de mener à bien la conception et la production de votre produit avec plus de maîtrise de votre roadmap, backlog et priorisation. Ainsi que plus de certitude quant à vos choix et leur défense auprès des métiers et stakeholders.