Les frameworks de priorisation sont souvent vus comme la baguette magique pour organiser sa roadmap : on entre quelques valeurs, on calcule un score, et le tour est joué, les priorités apparaissent comme par enchantement. Parmi eux, le framework RICE (Reach, Impact, Confidence, Effort) est particulièrement populaire. Mais voilà, dans le quotidien d’un product manager, prioriser ne se résume pas à additionner des chiffres. Et se fier aveuglément à ces scores peut mener à des pièges. Le RICE et les autres frameworks sont des outils, pas des oracles. Le PM doit rester le cerveau derrière les chiffres, pas leur serviteur.
Imaginons que tu dois décider quelles initiatives prioriser pour le trimestre, et après avoir passé tes solutions au crible du RICE, une d’elles sort avec un score impressionnant. Est-ce que cela signifie pour autant qu’elle est la top prio ? Pas nécessairement. Ce n’est pas parce qu’une solution a un score élevé que c’est le choix évident. Le framework te donne des indications, mais il ne comprend pas la stratégie, ni les contraintes du moment.
Prenons un exemple pour illustrer ce point. Supposons que ta squad puisse servir deux objectifs distincts : l’acquisition et la rétention. Une initiative d’amélioration de l’interface utilisateur pourrait avoir un score RICE élevé pour la rétention, mais est-ce que cela sert l’objectif prioritaire du trimestre ? Si la stratégie du moment est de renforcer l’acquisition, cette initiative pourrait être reléguée au second plan, malgré son score. Le RICE ne fait que poser un avis brut. À toi d’y ajouter le contexte, la direction stratégique et les priorités réelles du moment.
Un des travers des frameworks de priorisation comme le RICE, c’est qu’ils incitent parfois à comparer des initiatives qui ne sont pas faites pour être opposées. Si l’objectif principal du trimestre est l’acquisition de nouveaux utilisateurs, comparer une initiative d’acquisition à une initiative d’optimisation de la rétention devient presque insensé. Tu cherches à servir un objectif à la fois, et le framework devrait simplement t’aider à juger les options disponibles pour cet objectif précis.
C’est ici que la stratégie produit devient cruciale : en début de trimestre, clarifie l’objectif prioritaire. Une fois cet objectif établi, tu peux utiliser un framework comme RICE pour comparer les solutions qui contribuent spécifiquement à cet objectif. Cette approche t’évitera de fausser les priorités en mélangeant des initiatives aux impacts trop différents.
Les frameworks de priorisation comme le RICE semblent offrir une objectivité rassurante. On imagine que chaque score final est un nombre fiable, nous permettant de classer les initiatives avec une précision rigoureuse. En réalité, ces scores sont plus proches de plages de valeurs probables que de chiffres exacts. Pourquoi ? Parce que chaque paramètre — qu’il s’agisse de Reach, Impact, Confidence ou Effort — repose sur des estimations sujettes à une forte incertitude.
D'un point de vue statistique, les valeurs que tu attribues sont rarement suffisamment précises pour permettre une comparaison claire entre des scores proches. Le score obtenu avec le RICE représente donc une fourchette d’incertitude. Par exemple, si tu attribues un Impact de 3 et un Reach de 5 à une initiative, ces valeurs sont en fait des moyennes basées sur une estimation, mais la vraie valeur pourrait osciller autour de ces chiffres dans une fourchette plus large. Ce qui signifie que le score final de ton initiative est une zone probable plutôt qu’une donnée fixe.
Ce qui complique encore les choses, c'est que si les plages probables de deux initiatives se chevauchent (par exemple, une initiative avec un score de 315 pourrait en réalité se situer entre 300 et 330, tandis qu’une autre avec un score de 320 pourrait se situer entre 310 et 335), alors la comparaison entre elles perd toute fiabilité. L'incertitude est tellement élevée que distinguer une initiative de l’autre devient arbitraire.
Le RICE inclut bien un paramètre de confiance (Confidence) pour aider à jauger l’incertitude. Mais là encore, ce score reste subjectif. La valeur de la confiance que tu attribues est elle-même influencée par des facteurs personnels ou contextuels : ton expérience, tes ressentis ou les données disponibles à l’instant T. Ce qui signifie que même cette tentative de quantifier la précision reste fragile.
Finalement, mieux vaut voir le RICE comme une aide pour organiser les idées et explorer les options, plutôt qu’un outil capable de donner une réponse définitive. Cela t’évitera de tomber dans le piège d'une pseudo-science et te permettra d’accepter l’incertitude comme une partie intégrante de la prise de décision, tout en gardant une flexibilité pour ajuster tes choix.
En tant que PM, tu connais bien ce moment où les stakeholders demandent pourquoi telle ou telle initiative a été retenue à la place de leur "super" idée. Les frameworks de priorisation sont souvent mal compris et, à vrai dire, tes stakeholders n’ont pas besoin de tout connaître de tes méthodes. Leur donner une explication détaillée de chaque score RICE serait une perte de temps, et ne serait pas le meilleur moyen de justifier tes décisions. A la place il est préférable de bien savoir dire non.
Au lieu de chercher à défendre tes scores, il est plus judicieux de s’appuyer sur des arguments stratégiques et des résultats concrets. Plutôt que de dire “cette initiative a un score RICE plus élevé,” montre comment elle s’aligne avec l’objectif prioritaire du trimestre, ou en quoi elle répond à un besoin spécifique du marché ou des utilisateurs. Le RICE est là pour t’aider, pas pour te piéger dans des discussions techniques interminables. En bref, utilise-le pour prendre tes décisions, mais ne le transforme pas en un outil de justification.
Les frameworks comme le RICE sont là pour te donner un cadre et structurer tes réflexions. Mais garde ton esprit critique : ils ne doivent jamais dicter tes choix. La stratégie, les objectifs trimestriels et une compréhension fine de ton produit sont bien plus puissants que les chiffres. Les frameworks sont au service du product manager, pas l’inverse.