Introduction 

Le rôle du Product Manager est de prioriser les idées de fonctionnalités et projets pour son développement produit. Une des principales méthodes de priorisation en product management est la méthode RICE. Ce système de priorisation peut-être utilisé notamment lors de la phase de discovery, ou pour le backlog produit. Découvrez en détail les 4 étapes Reach, Impact, Confidence et Effort , et nos exemples pour calculer le score RICE.

‍

Définition de la méthode RICE 

La méthode RICE a été développée par Intercom. Son acronyme signifie en français Portée, Impact, Confiance et Effort. L’objectif de la RICE roadmap est d’évaluer chaque idée de projet. Le RICE propose ensuite une formule qui permet d’obtenir une note par projet, et de définir votre feuille de route produit en les classant par ordre de priorité : 

‍

‍RICE = (Reach x Impact x Confidence) / Effort 

‍

On va développer plus en détail la méthodologie ci dessous, mais voici un résumé :

Reach (Portée): combien d’utilisateurs sont affectés par ce projet ? 

Impact (Impact) : quel serait l’impact sur votre metric en faisant ce projet ? 

Confidence (Confiance) : dans quelle mesure vous avez confiance en vos estimations du Reach et de l’Impact cités précédemment ? 

Effort (Effort) : combien de temps de planification et de développement sont nécessaires pour ce projet ? 

‍

Avantages de la méthode RICE 

En tant que Product Manager, vous êtes amenés à identifier plusieurs problèmes ou opportunités lors de la phase de discovery. Malheureusement, vous ne pouvez pas tout faire et il est crucial de prioriser ces projets potentiels. 

Les avantages de la méthode RICE sont multiples : 

• rationaliser la prise de décisions 
• d'optimiser les ressources (projet) tout en maximisant l'impact
• d’avoir un outil de communication pour expliquer vos choix de priorisation aux parties prenantes de l’entreprise 

‍

Les 4 étapes de la méthode RICE

Pour chaque opportunité identifiée, il nous faut évaluer le Reach, l’Impact, la Confiance et l’Effort pour ensuite les comparer :

‍

Étape 1 - Reach (Portée)

Il s’agit d’estimer le nombre d’utilisateurs qui seront affectés par le projet. Cela concerne tous les utilisateurs ? Une partie d’entre eux ? On cherche à déterminer le nombre d’utilisateurs qui en seront impactés. 

‍

Étape 2 - Impact (Impact)

L’idée est de mesurer l’impact du projet par rapport à une métrique définie et ainsi voir quelles sont les incidences de celle-ci sur notre projet. 

‍

Souvent, il est difficile de mesurer l’impact avant de développer votre fonctionnalité. Pour cela, Intercom propose dans son RICE framework d’utiliser des proxy. Ainsi, si l’on pense que l’impact de notre projet est très élevé, on va lui mettre la note de 3 par exemple.  

Étape 3 -Confidence (confiance)

Il s’agit de déterminer au vu des estimations faites précédemment sur le Reach ou encore l’Impact à quel point on est confiant. Ainsi, plus on a de data pour confirmer notre R et I, plus notre confiance va être élevée. La confiance est estimée en pourcentage. 

‍

Étape 4 -Effort

C’est le temps nécessaire pour développer la fonctionnalité. Généralement, cela s’effectue en semaines. 

Ainsi, plus d'effort n'est pas une bonne chose, car il vient diviser notre résultat final. L’effort est une estimation, ce n’est pas un chiffre exact. Généralement, on va l’estimer en nombre de semaines. 

‍

Après avoir estimé le R.I.C.E., nous allons déterminer le RICE score qui se calcule à partir de la formule suivante : 

‍

‍La méthode RICE en exemple : 

Prenons l’application The Fork (La Fourchette). Nous sommes PM chez The Fork, sur le produit de réservation pour les restaurants.
The Fork est utilisée par 415 millions de personnes à travers le monde. 

On cherche à résoudre le problème suivant : aujourd’hui, nos clients (les restaurants), se plaignent que les réservations effectuées via The Fork ne sont pas assez fiables : trop d’utilisateurs réservent et ne viennent pas, ou sont très en retard, ce qui constitue un manque à gagner pour eux. Cela génère un taux de satisfaction des restaurants bas, et un risque de churn. 

Lors de la phase de discovery, on a identifié 3 potentiels problèmes à résoudre : 

• Problème 1 : l’utilisateur a oublié la réservation
• Problème 2 : l’utilisateur a eu un imprévu et ne peut pas venir
• Problème 3 : l’utilisateur a du retard

‍

- Reach (Portée) 

On va d'abord estimer le nombre de personnes/utilisateurs qui seront impactés par le projet (l'objectif), car on ne souhaite pas développer une feature/fonctionnalité qui impacte un faible pourcentage de ses utilisateurs. 

‍

‍Project 1 : l’utilisateur a oublié sa réservation. Aujourd’hui, via l’application, on envoie des notifications de rappel en amont de la réservation : un email, et une notification push via l’app. On envisage, comme solution au problème, d’ajouter un SMS de rappel afin de toucher plus d’utilisateurs. 

‍Lors de la phase de discovery, vous avez envoyé un sondage a 1000 utilisateurs qui ne se sont pas rendues à la réservation, en leur demandant pourquoi. Il en ressort que 15% avaient oublié la réservation. Il s’avère que 10 000 réservations par mois ne sont pas honorées : si on applique ce pourcentage, on peut considérer que le reach serait de 1500. 

(NB : ce sont des chiffres fictifs, pour l’exemple !)

“L’échelle” du reach (par mois, par jour, par an) n’importe pas. Ce qui compte, c’est que le Reach de vos différents projets soit à la même échelle. 

Reach projet 1 = 1500

‍

‍‍‍Project 2 : l’utilisateur rencontre un imprévu de dernière minute qui l’empêche d’honorer sa réservation. On peut réfléchir à la mise en place de pénalités.

Selon le sondage cité précédemment, 20% des utilisateurs ne s’étant pas rendu à la réservation ont indiqué avoir eu un imprévu. Si l’on applique ce pourcentage aux 10 000 réservations non honorées par mois, cela nous donne 2000. 

Reach projet 2 = 2000

‍

‍‍Project 3 : l’utilisateur a du retard. Il serait pertinent de pouvoir notifier via l’application son retard afin que le restaurant puisse s’adapter et peut être allouer sa table en attendant. 

‍Aujourd’hui, la data nous permet difficilement d’évaluer le pourcentage d’utilisateurs en retard. Afin d’obtenir les éléments la dessus, nous avons effectué une dizaine d’interviews avec des restaurateurs, pour leur demander d’estimer le pourcentage de réservations en retard. Il ressort qu’en moyenne, les restaurateurs interviewés estiment qu’environ 1 utilisateur sur 10 est en retard. Cela représenterait environ 3000 utilisateurs / mois (chiffre fictif, encore une fois!). 

Reach projet 3 = 3000

‍

‍

- Impact 

L'impact dépendra de la métrique de votre équipe. Dans notre exemple, on cherche à : 

• Réduire le % d’utilisateurs en retard ou ne venant pas aux réservations
• Afin d’augmenter le taux de satisfaction des restaurateurs

‍

Il est souvent difficile d'évaluer l'impact avant de développer votre fonctionnalité. C'est pourquoi, à ce stade, vous pouvez utiliser des approximations : 3 pour "impact massif", 2 pour "élevé", 1 pour "moyen", 0,5 pour "faible", et enfin 0,25 pour "minimal". 

‍Project 1 : Pour rappel, aujourd’hui, via l’application, on envoie des notifications de rappel en amont de la réservation : un email, et une notification push via l’app. On envisage, comme solution au problème, d’ajouter un SMS de rappel afin de toucher plus d’utilisateurs. 

‍En tant que PM, on va aller regarder dans la data quel pourcentage d’utilisateurs ont activé les notifications push : 40%. On observe également que le pourcentage d’ouverture des emails de rappel est de moins de 20%. En ajoutant un SMS, on peut faire l’hypothèse que l’impact sera élevé, car il permettra de notifier tous les utilisateurs n’ayant pas activé les notifications push, ni lu l’email. 

‍Impact projet 1 = élevé = 2 (selon le RICE)

‍

‍Project 2 : on peut réfléchir à la mise en place de pénalités si l’utilisateur ne se rend pas à la réservation.  

‍Ici, nous ne disposons pas de data nous permettant de faire des hypothèses sur l’impact des pénalités. Afin d’en savoir plus, nous contactons un(e) Product Manager d’une autre marketplace ayant un mécanisme de pénalités (exemple : Livi, Airbnb, Wecasa…), afin de tenter d’obtenir une idée. Il ressort de ce rendez vous que la mise en place de la pénalité a réduit de 90% les annulations sur ce produit : l’impact est massif. 

‍Impact projet 2 = massif = 3 (selon le RICE)

‍

‍Project 3 : nous pouvons nous pencher sur la possibilité de notifier sur l’application son retard pour prévenir le restaurant. 

‍Ce projet permettra de notifier le restaurant et donc potentiellement limiter la frustration des restaurateurs, mais il ne résout pas le problème de base, les retards et personnes ne venant pas à la réservation. L’impact est donc moyen. 

‍Impact projet 3 = moyen = 1 (selon le RICE)

‍

‍
- Confidence (confiance)

Vous devez tenir compte du degré de confiance que vous avez dans les estimations que vous venez de faire (reach et impact). Si vous pensez qu'un projet pourrait avoir un impact considérable, mais que vous ne disposez pas de données pour l'étayer, la confiance vous aide à contrôler ce point. Dans ce cadre, la confiance est un pourcentage. 100 % correspond à une "confiance élevée", 80 % à une "confiance moyenne" et 50 % à une "confiance faible". Tout ce qui est inférieur à ce pourcentage est considéré comme “moonshot”. 

‍Project 1: On dispose de data claires à la fois sur l’impact et le reach, comme vu précédemment : la confiance est élevée. 

‍Confiance projet 1 = élevé = 100% (selon le RICE)

‍

‍Project 2: On dispose de data sur le reach grâce au sondage cité précédemment. Néanmoins, l’hypothèse faite sur l’impact est basée sur une discussion avec un(e) Product manager d’un autre produit - on ne sait pas à quel point cela sera applicable pour The Fork. La confiance est donc moyenne. 

‍Confiance projet 2 = moyenne = 80% (selon le RICE)

‍

‍Project 3: Nous avons fait des approximations basées sur une dizaine d’interviews avec des restaurateurs pour le Reach, et sur l’impact, nous n’avons pas de data. 

La confiance est faible  : 50%.

‍Confiance projet 3 = faible = 50% (selon le RICE)

‍

- Effort 

Il nous faut maintenant estimer le temps total qu'un projet demandera à tous les coéquipiers (et pas seulement aux ingénieurs) : produit, conception et développeurs. Contrairement aux autres facteurs positifs, plus d'effort est une mauvaise chose, c’est donc pour cela que dans la formule finale du RICE, on divise par l’effort. Bien sûr, il y a un certain nombre d'inconnues, donc vous devez donner une estimation approximative. Pour cette partie, vous allez travailler avec votre équipe Tech qui pourra réfléchir avec vous à l’estimation du travail de dev. 

‍

Pour revenir à notre exemple : 

‍Project 1: la mise en place d’une feature permettant l’envoi de reminders par sms avant la réservation est un projet qui pourrait demander 2 semaines de travail (1 semaine de planification, 1 semaine de développement.)

‍Effort projet 1 = 2 semaines

‍

‍Project 2: la mise en place de pénalités en cas d’imprévu est un projet qui pourrait demander 6 semaines de travail (1 semaine de planification, 1 semaine de design, 4 semaines de développement.)

‍Effort projet 2 = 6 semaines

‍

Project 3: l’implémentation d’une feature pour notifier sur l’application son retard afin d’éviter un no-show est un projet qui pourrait demander 4 semaines de travail. (1 semaine de planification, 1 semaine de design, 2 semaines de développement.)

‍Effort projet 3 = 4 semaines

‍

‍

RICE Score : ‍

Après avoir estimé, le R, le I, le C, le E, il nous faut maintenant calculer le score de priorisation avec la formule suivante. 

RICE = (Reach x Impact x Confiance) / Effort

Le calcul score rice va ensuite nous permettre de prioriser et de nous décider sur le projet à mener. 

Au vu des résultats obtenus pour notre exemple, le projet 1 semble être celui à privilégier.  

‍

‍

La méthodologie RICE semble donc indiquer que le projet 1 est le plus intéressant, et le plus prioritaire à mettre en place. 

Attention néanmoins : le RICE est un outil, il ne s’agit pas d’une formule magique ! Parfois, vous serez amenés à développer des fonctionnalités qui ne sont pas les plus prioritaires selon le RICE - par exemple dans le cas de dépendances, ou à cause de la capacité de votre équipe. 

‍

Résumé du score de priorisation :

‍
Reach : Combien de personnes vont être impactés ? 

Impact : Quel sera l’impact sur chaque utilisateur (Massif : 3, Élevé : 2, Moyen : 1 , faible : 0,5 et minime : 0.25) 

Confidence : Quel est le degré de confiance dans vos estimations (Élevé: 100%, Moyen: 80%, Faible : 50%) 

Effort : Combien de temps cela prendra-t-il ? 

‍

Comparaison avec d’autres méthodes de priorisation  : 

Comment le modèle notation RICE se distingue-t-il d’autres méthodologies ? 

Chez Noé, nous aimons particulièrement le protocole RICE car c’est le seul outil de priorisation qui prend en compte le niveau de confiance de vos estimations, ce qui est souvent crucial lorsque vous ne disposez pas de data sur tous vos projets. 

Par ailleurs, la notion de Reach est également intéressante et ne se retrouve pas dans les autres méthodologies de priorisation. 

Enfin, il faut avoir en tête que le RICE est un exercice un peu long et fastidieux - à prendre en compte dans votre choix d’outil de priorisation. 

Parmi les autres modèles de priorisation de projets : la méthode MoSCoW et le modèle Kano.

La méthode MoSCoW est une approche qui permet de hiérarchiser les user stories et les tâches. Elle est particulièrement utile pour un projet qui figure déjà sur votre roadmap.

MoSCow veut dire pour “Must”, “Should”, “Could” and “Won’t”. Pour chaque fonctionnalité, vous allez définir, les parties qui sont : 

• Must Have : le projet ne peut pas fonctionner sans
• Should have : cette partie apporte une grande valeur au projet
• Could have : cette partie ajouterait peu de valeur au projet
• Won’t have : nous ne développerons pas cette partie car elle n’apporte pas suffisamment de valeur. 

‍

Le modèle Kano quant à lui, se penche sur la satisfaction du client en classant les fonctionnalités en attracteurs, performants et indifférents, fournissant une perspective plus profonde sur les attentes des utilisateurs. 

‍

Conclusion 

L’outil RICE est une méthode de priorisation de gestion de projets ou fonctionnalités permettant d’en évaluer chaque critère : sa portée, son impact, sa confiance et l’effort qu’ils vont susciter. 

Cette méthode est un excellent outil de décision pour permettre aux Product Managers de trancher entre différentes fonctionnalités possibles. Le RICE en product management peut être utile lors de la discovery, mais est aussi compatible avec les méthodologies agile. 

En tant que Product Manager, vous êtes amenés à identifier plusieurs problèmes ou opportunités. Malheureusement, vous ne pourrez pas tout développer et le RICE s’avère être particulièrement utile pour répondre à cette situation !

‍