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 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.
