L'unique raison pour laquelle les frameworks de priorisation ne fonctionneront jamais, et ce qu'il faut faire à la place
Auteur : Michael Goitein
Source : The One Reason Why Prioritization Frameworks Will Never Work, and What to Do Instead
Traducteur : Fabrice Aimetti
Date : 07/02/2024
Traduction :
Le Product Management implique d'être guidé par la stratégie, et non par des algorithmes de priorisation.
Retrouver l'essence du Product Management par rapport à celle du Project Management
Je devais coacher un nouveau Product Manager ayant une grande expérience dans son domaine, et nous étions au pied du mur.
Cela faisait des mois que nous n'avions pas livré de code. Beaucoup d'entre nous étaient coincés dans tellement de réunions d'avancement sur les raisons pour lesquelles nous ne livrions pas, que nous n'avions pas le temps de faire le travail de discovery et de delivery. Finalement, j'ai animé une session sur les moments clés du parcours utilisateur, un processus appelé "User Story Mapping".
Cela nous a permis de réduire notre produit à un ensemble ciblé de choix clairs. En 60 jours, nous sommes passés d'une série de post-its dans une salle de conférence à un logiciel opérationnel dans un point de vente, ce que l'organisation n'avait jamais fait auparavant ni depuis.
Cette étape a été suivie par des vagues successives de versions du produit, qui ont abouti à un déploiement national complet dans l'ensemble de notre zone de vente au détail.
Tout au long du processus, nous avons procédé à des itérations basées sur le feedback des utilisateurs.
Centré sur le client + Simplicité = Succès
Nous n'avons évidemment pas commencé avec le meilleur produit, mais en restant proches des besoins de nos utilisateurs et en apportant continuellement de petites améliorations, nous sommes rapidement passés d'un statut de second plan dans le portefeuille à celui de produit "sexy" que les autres dirigeants de l'organisation voulaient utiliser pour promouvoir leurs produits.
Nous avons rapidement été submergés par d'innombrables demandes, dont beaucoup semblaient en contradiction avec notre stratégie.
Avec des capacités d'ingénierie et un temps limités, ainsi qu'un contexte politique complexe, comment choisir la bonne fonctionnalité à ajouter ?
La résolution trimestrielle des problèmes...
Dès notre première version, notre prise de décision a été simple.
J'ai formé l'équipe à utiliser la double voie du Continuous Discovery et Delivery, en itérant sur une feuille de route basée sur les problèmes, en concentrant le travail de chaque trimestre sur la résolution d'un problème spécifique. Nous avons également identifié les points de dette technique, de dette UX et d'architecture technique que nous devions anticiper pour le problème à résoudre au cours du trimestre suivant.
Mais dès que le classement entre en jeu, la prise de décision devient de plus en plus difficile.
Jouer à la "roulette" de la priorisation
Les parties prenantes de l'ensemble de l'organisation s'intéressent désormais à notre produit.
Elles sont arrivées sur l'équipe de tous les côtés, chacune avec sa propre demande de fonctionnalité qu'elle voulait intégrer dans notre produit. Afin d'établir une forme de classement objectif, nous nous sommes tournés vers le framework de priorisation RICE.
Nous espérions que cela montrerait à nos parties prenantes comment nous avons priorisé les différentes demandes de fonctionnalités, en donnant une transparence et une impartialité objectives au processus de réflexion derrière ce que nous avons choisi de livrer en premier.
La seule chose à laquelle on donne la priorité, c'est d'avoir encore plus de fonctionnalités
Mais alors que nous étions occupés à prioriser l'ensemble des demandes de fonctionnalités, nous n'avons réalisé que trop tard que notre produit avait commencé à changer d'une manière que nous n'avions pas prévue.
Les fonctionnalités surdimensionnées et plébiscitées par nos utilisateurs, pour lesquelles ils devaient être formés, n'ont jamais été utilisées. Pire encore, des fonctionnalités indispensables pour résoudre les problèmes réels des clients n'ont jamais été prises en compte.
Et pourtant, nous avons continué à intégrer de plus en plus de fonctionnalités dans notre produit pour tenter de satisfaire la demande insatiable de chaque partie prenante. Au fil du temps, avec une dette technique et UX croissante, le produit s'est effondré sous le poids des fonctionnalités.
La direction a finalement mis fin à notre produit, optant pour le remplacer par une version dépouillée reconstruite à partir de zéro.
Que s'est-il réellement passé ?
Nous avions bien commencé en nous limitant à un ensemble clair de choix stratégiques axés sur l'utilisateur.
Au début, nous avons eu la chance d'être à la fois autonomes et dotés de moyens d'action, étant donné que nous possédions notre propre stack technologique et que nous avions été largement ignorés par le reste de l'organisation.
Nous n'étions tout simplement pas préparés à gérer le flot de demandes de fonctionnalités. Cela nous a obligés à dire "oui" à tout le monde et à essayer de prioriser pour choisir ce qu'il fallait construire en premier.
Rétrospectivement, il est clair que dès que nous avons commencé à jouer le jeu perdant de la priorisation des demandes de fonctionnalités, nous nous posions la mauvaise question.
Comment fonctionnent les frameworks de priorisation ?
Idéalement, ils devraient aider à exposer les différents mérites des différentes solutions, en les classant en fonction de différents paramètres.
Le RICE d'Intercom, par exemple, propose aux Product Managers d'évaluer les nouvelles demandes en fonction des quatre dimensions suivantes :
- Reach / Portée : combien de personnes seront touchées ?
- Impact : quel sera l'impact sur l'objectif ?
- Confiance : dans quelle mesure sommes-nous confiants dans notre estimation globale, étayée par des données ?
- Effort : combien de temps et d'efforts seront nécessaires pour mettre en place cette fonctionnalité ?
Ces chiffres sont introduits dans la formule suivante pour obtenir le chiffre "un" :
La formule du framework RICE d'Intercom. Avec l'aimable autorisation d'Intercom.
La logique qui sous-tend cette formule est que les Product Managers, armés du résultat, disposent d'une base pour des conversations plus riches sur l'ordre du backlog avec les parties prenantes.
Comment combattre la priorité ?
Mais j'ai constaté que les preuves générées sont plus souvent utilisées pour mettre fin aux conversations.
Du côté du Product Manager, il peut brandir le nombre craché par l'algorithme du framework de priorisation comme une "preuve" qu'il a fait les vérifications nécessaires et qu'il a fait le bon choix.
Dans certains environnements, toutes les données présentées par le PM sont contrées par un "HiPPO" ("Highest-Paid Person's Opinion" / l'Opinion de la Personne la Plus Payée), la partie prenante qui rejette ce score sophistiqué et insiste pour que le PM construise ce qu'on lui a dit de faire.
Fichier:HiPPO en.png
Souvent, c'est l'opinion de la personne la mieux payée ("HiPPO") qui décide de ce que nous construisons. Via HowGoogleWorks.net.
La seule raison pour laquelle les frameworks de priorisation ne fonctionneront jamais
Il n'en reste pas moins que les frameworks de priorisation sont une réalité quotidienne pour de nombreux Product Managers.
Certains leaders d'opinion en matière de produits célèbrent cette réalité en publiant des articles annonçant le "plus grand tour d'horizon des frameworks de priorisation les plus populaires". Il est révélateur que ces articles deviennent viraux, car ils témoignent du besoin généralisé de certitude que ces frameworks promettent.
Je pense qu'ils sont tous fondamentalement défectueux, car les Product Managers qui utilisent des frameworks de priorisation basés sur des feuilles de calcul pour déterminer quelle fonctionnalité construire ne résolvent pas le bon problème.
Pire encore, ils ne s'attaqueront jamais à ce qui doit être traité, ce qui se traduit par un mauvais product management, de mauvais produits et de mauvaises expériences pour les clients.
Pourquoi ?
Il est temps d'accepter que tous les frameworks de priorisation ne sont que des pansements couvrant un problème plus profond de manque de clarté stratégique.
En effet, lorsque les Product Managers en sont réduits à prioriser les fonctionnalités à l'aide de frameworks de priorisation, c'est le signe évident d'un manque de stratégie au sommet de l'entreprise.
Quel est le rôle du Product Manager ?
La tâche est d'autant plus ardue que le Product Manager est responsable du succès de son produit, mais qu'il n'a aucune autonomie dans le choix des fonctionnalités qui le composent.
La direction générale et le service des ventes lui fournissent souvent des listes de fonctionnalités prédéterminées, et il est blâmé lorsque le produit ne donne pas les résultats escomptés - ventes non réalisées, clients qui quittent l'entreprise. Dans ces environnements où les Product Managers ne sont responsables que du développement des fonctionnalités, leur travail est réduit à la gestion de projet.
Ils sont littéralement chargés de déterminer, parmi l'avalanche de fonctionnalités demandées par les parties prenantes dans le backlog de leur équipe, celle qu'ils doivent construire en priorité, et de veiller à ce qu'elle soit livrée le plus rapidement possible.
Le Product Management est un rôle stratégique
Si les Product Managers ont d'innombrables responsabilités, ils ne sont en fin de compte là que pour une seule raison :
Donner vie à la stratégie de l'organisation à un haut niveau grâce à leur produit, de manière à satisfaire les clients.
C'est tout. Ils sont l'interprète et le concepteur ultimes de l'imbrication de leur stratégie au niveau du produit dans la stratégie organisationnelle globale.
Tout le reste est une sorte de gestion de projet, d'équipe ou de développement.
La priorisation s'effectue au niveau des opportunités afin d'obtenir des outcomes et un impact sur l'entreprise par le biais de la stratégie. Image de l'auteur.
