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 :


WA : Winning Aspiration - WTP : Where to Play - HTW : How to Win - MHC : Must-Have Capabilities - EMS : Enabling Management Systems

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.


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.

Rareté de la clarté stratégique

Dans les environnements où la stratégie est mal formulée, voire contestée aux niveaux les plus élevés, ce manque de clarté finit par se répercuter vers le bas, plaçant les Product Managers et leurs équipes sous une pression constante de la part de multiples acteurs.

Ils ont alors recours au "théâtre des priorités".

Mais il est déjà trop tard, car nous établissons des priorités dans le mauvais espace :

L'espace des Solutions, au lieu de l'espace des Problèmes.

Et Rich Mironov d'écrire :

"...nous ne pouvons pas prioriser le travail de manière générique, valider les améliorations potentielles auprès de toutes les parties prenantes, ou supposer que chaque segment de clientèle appréciera les bénéfices de la même manière. Selon moi, trier les backlogs et établir des feuilles de route en se basant uniquement sur des feuilles de calcul à plusieurs colonnes, sur le coût du retard ou sur le WSJF est fondamentalement erroné. C'est une faute professionnelle en matière de "Product Management".

Et Saeed Khan, leader d'opinion en matière de Product Management, d'écrire :

"Vous ne devriez pas donner la priorité aux "fonctionnalités". Oui, j'ai bien dit cela. Les fonctionnalités sont des implémentations liées à des problèmes ou à des opportunités. Vous devriez vous concentrer sur la priorisation des problèmes et des opportunités qui sont liés à des objectifs et des stratégies à un niveau plus élevé. Vous ne devriez pas donner la priorité aux fonctionnalités.

Comme le souligne Andrea Saez, la priorisation nous fait défaut au niveau le plus élémentaire :

"Par-dessus tout, les frameworks manquent un aspect fondamental du Product Management : l'empathie".

Sommes-nous coincés en pleine Paralysie de l'Analyse ?

Ainsi, lorsque nous nous plaçons dans l'espace de la solution (ou "Output") en donnant la priorité aux fonctionnalités, nous abandonnons notre rôle essentiel de Product Manager.

Nous nous concentrons intrinsèquement et analytiquement sur la planification, plutôt que de donner vie à notre stratégie par le biais de notre produit pour nos utilisateurs finaux.

Car ce qui distingue la stratégie de la planification, c'est la prise de conscience que nous travaillons pour faire avancer quelque chose qui, par nature, échappe à notre contrôle :

Oucomes / Résultats

Un résultat, ou un changement dans le comportement humain, prépare les clients à réussir d'une manière qui leur convient, ainsi qu'à notre entreprise.

Si nous essayons de nous concentrer sur l'obtention de résultats spécifiques en matière de changement de comportement des clients, nous devons travailler à rebours de quelque chose d'autre :

Opportunités

Les opportunités sont les besoins non satisfaits des clients, exprimés avec leurs propres mots.

Ils nous aident à répondre aux questions suivantes :

• Pour qui construisons-nous cette fonctionnalité, afin qu'ils puissent finalement faire quoi ?
• Quels sont les besoins non satisfaits que cette fonctionnalité les aide à satisfaire ?
• Comment cette fonctionnalité est-elle liée aux choix stratégiques de l'entreprise à un niveau plus élevé ?

Nous avons donc choisi de prioriser les besoins de nos clients cibles sur les bons canaux et dans les bonnes zones géographiques (nos choix " Où jouer ?"). Pour répondre à ces besoins, nous avons identifié des moyens spécifiques pour les aider à réussir. (Nos choix "Comment gagner ?").

Travailler à rebours à partir du bon problème du client avec les bons choix " Où jouer ?" et " Comment gagner ?" nous aide à comprendre facilement ce qui doit être construit ensuite - aucun framework de priorisation n'est nécessaire.


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.

Comment la stratégie répond aux questions de priorisation

Dans les environnements où la stratégie est une compétence fondamentale au sein de l'organisation, les Product Managers guident leurs équipes et les parties prenantes pour concevoir ensemble des choix stratégiques au niveau du produit et qui s'inscrivent efficacement dans le cadre d'une stratégie de plus haut niveau.

Malheureusement, la stratégie est plus souvent isolée dans des petits groupes, ou rarement communiquée avec clarté par la direction générale.

Nous avons toujours eu une stratégie

Mais il y a une solution : reconnaître que la stratégie est ce que nous faisons déjà, et non ce que nous prétendons faire.

Est-elle bien comprise et clairement énoncée ? Parce que la stratégie est devenue un art perdu, tant dans le domaine de la conception que dans celui de la communication efficace, chose rare. Mais il existe un moyen non seulement de comprendre la stratégie qui sous-tend nos choix actuels, mais aussi de tester sa logique sous-jacente, ce qui nous permet de faire de meilleurs choix stratégiques au niveau du produit.

Les cinq boîtes de la Cascade des Choix Stratégiques représentent un framework éprouvé et solide qui aide les équipes à identifier, tester et concevoir des ensembles de choix stratégiques englobant tout ce qui est nécessaire à la fois pour la "stratégie" et pour l'"exécution".


Les Cinq Boîtes du framework de Cascade des Choix de la Stratégie "Jouer pour gagner". Image de l'auteur tirée du travail de Roger L. Martin.

La Cascade des Choix Stratégiques peut vous aider de trois manières différentes :

Rétro-ingénierie de votre stratégie actuelle

En collaboration avec notre Trio produit et les principales parties prenantes, nous avons procédé à une rétro-ingénierie rapide de notre stratégie actuelle dans les cinq boîtes.

L'essentiel est de ne pas trop réfléchir au processus et de l'aborder de manière rapide et légère. Vous voulez commencer à mettre votre stratégie implicite dans un espace où vous pouvez la voir.


Rétro-ingénierie de la stratégie d'OŪRA Ring à l'aide de la Cascade des Choix Stratégiques. Image de l'auteur.

À partir de cette base stratégique claire, il est généralement toujours facile de savoir ce qu'il faut faire ensuite.

Se demander "Qu'est-ce qui devrait devenir vrai ?"

Maintenant que nous connaissons nos choix stratégiques, nous voulons poser la question la plus importante en matière de stratégie : "Qu'est-ce qui devrait devenir vrai ?"

Cette question peut sembler subtile, mais elle représente un changement majeur. Habituellement, il s'agit de l'opinion d'une personne par rapport à une autre sur ce qu'elle croit être vrai. En passant de la question "Qu'est-ce qui est vrai ?" à "Qu'est-ce qui devrait devenir vrai ?", nous sommes en mesure de tester la logique qui sous-tend trois forces essentielles : les Clients, l'Entreprise et la Concurrence.

En tant que groupe, nous posons la question "Qu'est-ce qui devrait devenir vrai ?

• Nos clients : qu'est-ce qui devrait arriver à nos clients pour qu'ils adhèrent à ces choix ?
• Notre entreprise : qu'est-ce qui devrait arriver à notre entreprise pour qu'elle soit en mesure de répondre efficacement à ces choix ?
• Notre concurrence : qu'est-ce qui devrait arriver à nos concurrents pour qu'ils réagissent à nos choix ?

Demander quel serait le plus grand obstacle à notre réussite ?

Sur la base des réponses à nos questions "Qu'est-ce qui devrait arriver ?", nous pouvons maintenant tirer parti de l'expertise de l'équipe qui procède à la rétro-ingénierie de la stratégie.

Quelqu'un pourrait souligner que les clients n'utilisent pas la solution que nous leur avons fournie, malgré l'avalanche de documents marketing et d'efforts de formation insistant sur le fait qu'ils le font. Il pourrait même y avoir des données à l'appui, comparant l'utilisation prévue à l'utilisation réelle.

Il est tout aussi important de savoir pourquoi les clients n'ont pas adopté notre produit en discutant avec eux. La condition "Qu'est-ce qui devrait arriver ?" ne tient donc pas et les efforts déployés pour tester et lever cet obstacle majeur orienteront la feuille de route.

L'identification et l'élimination de ces obstacles dans les espaces d'Opportunité et de Résultat / Outcome fourniront un cadre de référence pour ajuster nos choix et apporteront une plus grande clarté dans l'approche de la feuille de route de notre produit.

A retenir & TL;dr (trop long, pas lu)

Les Product Managers n'ont pas à être réduits à des Project Managers priorisant des listes de fonctionnalités demandées.

Cette approche fonctionnera même si nous sommes coincés dans une "usine à fonctionnalités", même si personne ne peut ou ne veut articuler clairement notre stratégie. En prenant du recul et en cartographiant notre stratégie actuelle avec notre équipe clé et nos parties prenantes, nous aurons enfin la possibilité de faire des choix qui s'alignent sur les choix stratégiques faits à des niveaux plus élevés.

La Cascade des Choix Stratégiques offre un framework éprouvé qui expose et teste la logique sous-jacente à notre stratégie produit, l'aidant ainsi à s'imbriquer et à s'aligner efficacement sur la stratégie de l'entreprise à un niveau plus élevé.

Vous ne savez pas quoi construire ensuite ?

• Faites une rétro-ingénierie collaborative de votre stratégie actuelle afin de l'aligner sur celle de votre équipe et de vos parties prenantes.
• Demandez ce qui devrait devenir vrai ? à propos des clients, de l'entreprise et des concurrents pour que ces choix se réalisent.
• Identifier les plus grands obstacles. Au lieu de vous concentrer sur l'espace de la solution "Output", concentrez-vous plutôt sur les plus grands obstacles dans l'espace de l'opportunité client et du résultat du changement de comportement. Priorisez les éléments do Continuous Discovery pour surmonter ces obstacles.

À partir de cette base stratégique claire, il est toujours facile de savoir ce qu'il faut construire ensuite.

Références

• Rich Mironov - La stratégie produit dépend de la stratégie de l'entreprise : https://www.mironov.com/strat-layers/
• Roger L. Martin - La stratégie, c'est ce que l'on FAIT, pas ce que l'on DIT : https://rogermartin.medium.com/strategy-is-what-you-do-not-what-you-say-a6e483840557
• Roger L. Martin - Qu'est-ce qui devrait devenir vrai ? : https://rogermartin.medium.com/what-would-have-to-be-true-83dac5bd2189
• Saeed Khan - Pourquoi vous devez éviter les frameworks de priorisation: https://swkhan.medium.com/why-you-should-avoid-prioritization-frameworks-779a61c0087
• Andrea Saez - Quel est le meilleur framework pour prioriser ce sur quoi il faut travailler ensuite ? : https://medium.com/product-manager-hq/what-is-the-best-framework-to-prioritize-what-to-work-on-next-b20c091b1829

---