Product Inbox 📬 Focus #6 - Comment bien prioriser ? Le REX de 4 top PM et CPO

May 5, 2022

Après avoir lu cette édition, si tu as aimé le contenu, ce serait super que tu cliques sur le petit ❤️ situé à côté de la photo de ma tête. Cela me permet de connaître les sujets qui t’intéressent !

Hello👋, si tu lis cette newsletter pour la première fois, bienvenue ! Je m’appelle Timothé et deux fois par mois, je partage aux abonné·e·s de Product Inbox, une curation des meilleurs contenus dédiés au Product Management. Si tu aimes l’audio, j’échange également avec des top entrepreneurs et product managers sur Clef de voûte.

Si tu n’es pas encore abonné·e, voici ce que tu as manqué ces derniers mois :

Hello,

J’espère que tu vas bien :)

C’est parti pour une nouvelle édition “Focus” de Product Inbox sur la priorisation. C’est une thématique qui m’a été beaucoup demandée par les lecteurs de la newsletter. Je suis vraiment ravi de t’envoyer l’édition aujourd’hui 🤩.

Je tiens à remercier chaleureusement mes 4 invité·e·s qui ont consacré du temps pour produire cette édition. J’ai nommé 🥁 :

Olivier Courtois, cofondateur de uku.wtf (et ex. VP Product de Comet)
Manon Prévot, Product Manager chez Captain Contrat
Charles Buseyne, Chief Product Officer chez Equify
Matthieu Le Berre, Chief Product Officer chez Guest Suite

Je tiens à préciser que je n’ai de partenariat commercial avec aucun produit ou service cité dans cette édition. Comme d’habitude, ma volonté est d’apporter du contenu utile et neutre pour t’aider dans ton quotidien :)

DISCLAIMER : pour une même question, tu verras que les réponses de mes invité·e·s peuvent être très différentes.

Et ceci pour plusieurs raisons :

Mes invité·e·s évoluent dans des contextes, cultures et sociétés différentes
Ils n’ont pas tous vécu leur expérience de PM de la même manière
Ils n’ont pas les mêmes backgrounds ni le même niveau d’expérience

Pour réaliser cette édition, j’ai posé 8 questions à mes invités :

A partir de quel stade faut-il penser à la priorisation ?
Comment priorises-tu dans ta boite ?
Quels sont les critères les plus importants à considérer dans la priorisation ?
Comment faire cohabiter des sujets impactants avec des petits sujets moins impactants ?
Comment mesurer le succès de la priorisation ?
Avec qui doit se faire ce travail de priorisation ?
Que penses tu des frameworks suivants pour prioriser sa roadmap ?
Quels sont les meilleurs frameworks à chaque stade de développement d'une boite ?
Quelles sont tes ressources préférées sur le sujet de la priorisation ?

Les points principaux à retenir 🧠

La priorisation se fait à tous les stades de développement d’un produit
Il existe des tas de framework de priorisation dont l’utilisation dépend de la granularité des décisions à prendre
Les critères à prendre en considération dans la priorisation dépendent de tas de paramètres : le temps investi sur différents types de travaux produit, l’alignement avec la stratégie…
Pour faire cohabiter des sujets en fonction de leur niveau d’impact, différents modes d’organisation existent. Les tracks de travail en 80/20, les équipes Jedi et Mad, l’équilibre entre quick wins et sujets de fonds etc.
Le succès d’une priorisation se résume à l’impact généré pour les utilisateurs. Il est mesurable via données quanti et quali
Le travail de priorisation se fait main dans la main avec tous les stakeholders d’une entreprise, y compris les utilisateurs
RICE est un des frameworks les plus utilisés mais manque de précisions dans certains contextes. Kano manque de flexibilité et est plus adapté à des environnements moins centrés produit. WSJF est complexe à implémenter
Le RICE est assez pertinent pour des entreprises mid et late-stage. Une stratégie posée est suffisante pour prioriser en environnement early-stage

1/ A partir de quel stade faut-il penser à la priorisation ?

Olivier Courtois, Uku

Le plus tôt possible ! Plus la société est jeune, moins elle est résiliente à des pertes de temps. Le focus & la vitesse sont clés. Dans ce contexte, les fondateurs doivent absolument fournir un cadre stratégique clair :

Quelle est l’audience prioritaire (= je priorise une cible d’utilisateurs) ?
Quel est le first used-case que l’on doit servir (= je priorise un besoin primaire) ?
Comment positionne-t-on le produit sur le marché (= je choisis un angle unique) ?
Quels sont les objectifs prioritaires (= je priorise des outcomes, 2,3 max) ?

Si l’entreprise (et son leadership) n’est pas au clair là-dessus, il faut pousser ce travail via des méthodes comme celle de Gibson Biddle, le radical focus présenté par Rémi Guyot ou la récente publication de Thiga sur la stratégie produit.

Charles Buseyne, Equify

The essence of strategy is to choose what NOT to do - Michael Porter

C’est la loi numéro 1 du Produit : on ne peut pas tout faire. On aura toujours plus d’idées que de temps disponible pour les mettre en oeuvre. Avoir une stratégie, c’est prioriser. La stratégie, c’est d’abord choisir le problème à résoudre en priorité. Il faut commencer par là, avant de prioriser des solutions entre elles, jusqu’à descendre aux tâches, où il y aura toujours des arbitrages tactiques nécessaires. Donc oui, on priorise à tous les stades de développement du produit. A l’inverse, la mission et la vision sont plutôt des références, en principe assez stables, qui vont donner un cadre à la priorisation.

Manon Prevot, Captain Contrat

Sur chaque étape on a besoin de prioriser :

Les problèmes : on reçoit énormément de problèmes de la part des utilisateurs, d’autres équipes, du business, etc. Il faut réussir à comprendre ce qui est le plus impactant et qui nécessite d’être résolu en priorité
La discovery : on pourrait passer des heures en discovery, il faut rationaliser et voir ce qui peut nous apporter le plus de réponses
Les solutions : ce qui paraît le plus évident mais chaque solution que l’on conçoit doit être priorisée au sein de l’ensemble du backlog

Matthieu Le Berre, Guest Suite

La priorisation intervient à partir de l’étape de définition de la stratégie produit. Les étapes précédentes (mission et vision) permettent de définir pourquoi notre produit existe et où on veut l’emmener : pas de limite sur les moyens mis en oeuvre, pas de renoncement à cette étape et donc pas d’élément à prioriser. Dès la définition de la stratégie, on rentre dans le “quoi” de notre produit ce qui implique de définir aussi ce qu’il n’est pas : renoncer est pour moi le premier niveau de priorisation. C’est aussi à cette étape qu’on peut définir le niveau d’impact / performance que l’on veut avoir dans les métiers qu’on exerce, ce qui implique aussi une priorisation.

2/ Comment priorises-tu dans ta boite ?

Olivier Courtois, Uku

De mon point de vue un framework de priorisation sert avant tout à :

Aligner l’équipe
Déployer la stratégie
Donner un cadre à la priorisation (et les discussions associées).

Chez uku, la société est toute jeune et le produit cherche son product/market fit. Du coup, le process se fait essentiellement entre co-fondateurs, tous les mois (et pas mal en continu).

On priorise :

Les problèmes et opportunités identifiées en discovery (en prenant en compte le marché, la performance du produit existant, les utilisateurs actuels et prospects)
Les solutions imaginées

Plus la société est jeune, plus je tends vers un modèle simple, aka la question qui tue : qu’est-ce qu’il serait stupide de ne pas avoir fait d’ici 90 jours ?
Tout le reste est mis de côté et fait l’objet d’une liste de “hard choices” (= toutes les bonnes idées que l’on ne touchera pas. C’est inspiré par le Radical Focus présenté par Rémi Guyot). Le focus & la vitesse sont nos super-pouvoirs. Tous les efforts devraient contribuer à un seul objectif commun.

Charles Buseyne, Equify

On combine plusieurs approches, suivant la granularité des décisions.
Concrètement, on se réunit tous les 3 mois entre C-Levels, dans un “Leadership Day”. L’objectif est de rafraîchir notre diagnostic stratégique, et de le traduire en objectifs. C’est là qu’on décide, à grosses mailles, comment on veut répartir nos efforts entre les différents axes sur les mois à venir : acquisition, rétention, monétisation, scalabilité, innovation, etc. Où veut-on appuyer ? Sur quoi est-ce qu’on accepte, au contraire, d’aller moins vite ou de faire plus tard ? C’est ça qui servira de base à nos OKR et à notre roadmap.

Ensuite, le travail beaucoup plus décentralisé commence pour identifier les problèmes à attaquer en priorité, et les initiatives qui nous feront le plus avancer sur ces objectifs. Là, les Product Managers sont en première ligne, et gardent la main jusqu’au bout.

Notre référence, c’est l’Opportunity Solution Tree de Teresa Torres (ou l’outcome-based roadmap, très proche). On l’a choisi parce qu’il permet de faire ce lien entre la Big Picture et les décisions tactiques. Quand on est sur des arbitrages plus micro (exemple : choisir entre plusieurs A/B tests d'optimisation d'un funnel de conversion), d’autres frameworks peuvent être utilisés en complément, comme le Rice et le Moscow. On a aussi un système d’upvote des tickets, très pratique pour voir ce qui est le plus attendu. On a trouvé comment le faire en Notion, l’astuce est ici.

Manon Prevot, Captain Contrat

En général on utilise le RICE (Reach, Impact, Confidence, Effort) : ce qui obtient le plus gros score RICE est priorisé. C’est ce qui nous paraît le plus complet pour prendre en compte à la fois l’impact et l’effort, pour prendre des décisions rapidement.

Après on y ajoute aussi pas mal de bon sens, quand on peut faire passer des quick-wins au milieu de notre roadmap, on le fait, tant que ça ne retarde pas nos sujets prioritaires.

Matthieu Le Berre, Guest Suite

Temps 1 : construction de nouvelles feature et organisation en feature team

Roadmap du quarter :
- Priorisation des “macro features” ou des thèmes identifiés en amont en échangeant avec les équipes business
- Atelier de priorisation sous forme de “buy your feature” avec les boss et C-Level. Nous avons choisi cette méthodologie car elle est ludique, accessible et sensibilise à “on ne peut pas tout faire”.
Sprint : priorisation des features via le RICE, réalisée par les équipes produit et tech.

Temps 2 : traitement des problèmes principaux de notre produit

Roadmap au quarter :
- Identification des problèmes majeurs via data sur notre support + entretiens avec les CSM qui assurent le niveau 1
- Priorisation des problèmes en utilisant le Moscow car il est accessible à tout le monde et la priorisation est simplifiée via 3 niveaux
Sprint : priorisation des solutions aux problèmes via le RICE, réalisée par les équipes produit et tech.

3/ Quels sont les critères les plus importants à considérer dans la priorisation ?

Olivier Courtois, Uku

Ça dépend du contexte de l’entreprise et du produit. Pour que cela soit efficace j’essaie d’avoir 2 discussions:

Une discussion de haut niveau
- Quels objectifs on se donne ? (success metrics avec niveau d’ambition & timeframe)
- Comment investir notre temps entre les différentes composantes de la stratégie ainsi que les différents types de travaux produit ? (feature work, scaling work, growth work, pmf expansion)
Une seconde discussion sur les meilleures opportunités qui fonctionnent avec le temps imparti et les niveaux d'ambition visés. Généralement exprimé sous forme d’Opportunity Solution Tree.

Charles Buseyne, Equify

S’il fallait retenir un seul critère, je dirais l’alignement avec la stratégie. Est-ce que cette évolution produit va vraiment nous rapprocher de ce qu’on veut être dans 3 mois, 1 an, 5 ans ?

Ensuite, il y en a beaucoup d’autres : l’impact client (le R et le I du RICE), le coût, le niveau de risque, le niveau d’urgence (ou “cost of delay”), etc.

Quels que soient les critères retenus, on a besoin de données fiables en entrée. Aux Product Leaders, justement, de créer l’environnement favorable à la collecte de “data points” fiables. D’où l’importance de la discovery et d’un bon outillage analytics dans l’ensemble de la boîte. Une recommandation concrète là-dessus : travaillez avec vos équipes Customer Success pour que les raisons du départ de chaque client (le “churn”) soient systématiquement enregistrées, catégorisées (problème produit ou pas) et accessibles. C’est une mine d’or ensuite quand tu dois prioriser des sujets liés à la rétention. Un exemple de churn analysis template.

4/ Comment faire cohabiter des sujets impactants (à prioriser) avec des petits sujets moins impactants ?

Olivier Courtois, Uku

Généralement je mets en place 2 tracks de travail. 80% du temps de l’équipe est planifié via une roadmap, 20% est le tout venant (ex : bug, quick-wins, small feedbacks). Il n’y a pas de backlog pour ça et on suit une priorisation sommaire. On répond juste aux questions : pourquoi maintenant ? Qui sera impacté ? On les insère dans la colonne “todo” au bon niveau. Les sujets qui passent sont généralement développés dans la semaine.

Charles Buseyne, Equify

Chez Equify, on a résolu la question d’une manière très simple, en créant 2 équipes. Les “Jedi” et les “Mad”. Jedi, ça veut dire Just Do It (JDI). Mad, c’est pour “Make a Difference”.
Nos Jedi sont dimensionnés pour traiter d’abord les bugs, puis, avec le temps restant, prendre le maximum de quick-wins. La seule condition : rien qui ne prenne plus d’un jour ou deux. Et la priorisation est super light. Just. Do. It.
Les Mad, eux, s’attaquent aux initiatives de plus grande ampleur. Et on formalise beaucoup plus le travail produit : définition et mesure du succès, discovery, plan de go-to-market, etc. Point super important : les équipes tournent. Tu peux être Jedi sur un cycle et Mad sur le suivant.

Cette formule permet d’abord de matérialiser notre focus sur la qualité d’exécution et l’expérience utilisateur. Ensuite, cette bande passante “Jedi” évite de transformer l’équipe Produit en simple machine à dire non. Faire les petites choses “de bon sens”, ça contribue à instaurer un vrai climat de confiance et de coopération entre les équipes. C’est indispensable si derrière, on veut avoir les meilleurs insights.

Ta priorité quand tu es Mad, c’est le Big Stuff. Quand tu es Jedi, le Small Stuff. Mais jamais les deux en même temps.

Manon Prevot, Captain Contrat

J’essaye de garder un petit ratio (environ 10% de la bande passante dev.) pour toutes les petites améliorations et corrections de bugs, dans un run continu. S’il s’agit vraiment d’une typo/coquille, pas besoin de le faire passer dans un processus de priorisation, on l’envoie dans le backlog directement.

Matthieu Le Berre, Guest Suite

Nous avons des sujets que nous taggons en “quick-wins” dans Product Board.
A chaque sprint on en intègre 3 ou 4 afin d’avoir des choses plus “légères” à faire.
On en introduit aussi un peu plus (7 à 8) en parallèle des sprint de Cool Down (tous les 4 sprints).

5/ Comment mesurer le succès de la priorisation ?

Olivier Courtois, Uku

Je ne le mesure pas vraiment. Une priorisation réussie crée de l'alignement et du focus pour l’équipe, tout en encourageant des apprentissages réguliers, donc de la flexibilité. Il faut éviter de tomber dans le piège de se battre pour une roadmap qui aurait perdu du sens pendant la période. En fin de compte, le succès réel d’une priorisation, c’est l’impact que tu génères pour l’entreprise et les utilisateurs. Ce qui se verra dans les verbatims (en quali) et dans les datas (en quanti).

Charles Buseyne, Equify

Je ne le mesure pas en tant que tel. Ce qu’on mesure, c’est le succès du produit, son outcome. Mais quand on fait des post-mortems pour comprendre pourquoi un produit n’a pas marché, il arrive qu’on tombe sur un problème de priorisation. Parfois, un sujet qui s’est retrouvé dans la roadmap sans qu’on sache vraiment pourquoi, et sans que toute la discovery ait été faite comme il faut. Un bon outil pour éviter ce type de déconvenues, c’est le pre-mortem. Voir par exemple son implémentation chez Stripe par Shreyas Doshi.

Manon Prevot, Captain Contrat

On mesure le succès de nos releases au fur et à mesure (en définissant en amont les success metrics en fonction de la feature : taux de conversion, taux de sign-up, taux d'usage de la feature), et on voit à quelle vitesse on arrive à obtenir de l’impact. Si nos premières releases n’ont aucun impact, ce n’était peut être pas la bonne priorisation.

6/ Avec qui doit se faire ce travail de priorisation ?

Olivier Courtois, Uku

Généralement :

Avec les stakeholders de ta squad / produit pour créer de l’alignement. Cela peut être des équipes à l’interface avec les utilisateurs (Customer Support, Sales, CSM) ou utilisatrices elles-mêmes (Logistique, Sales, …)
Avec les utilisateurs quand c’est possible : utilisateurs internes ou customer advisory board (attention aux biais)
Avec ton équipe
Avec le leadership si nécessaire

Charles Buseyne, Equify

Je vois ça comme un sablier. Au milieu, la partie la plus étroite, c’est le Product. C’est lui, qui, au final, tranche. C’est le cœur de son métier et c’est une délégation de la DG. Mais pour décider, il faut avoir réuni le maximum d’insights, de toute la boîte. C’est la partie haute du sablier. Dans ces interlocuteurs-clés, il ne faut surtout pas oublier les Engineering Managers, qui vont aider à déterminer ce qui peut rentrer dans l’appétit qu’on a pour un sujet (le temps qu’on souhaite y passer). Entre le Product Manager et son Product Leader, ça doit être un principe de subsidiarité : une fois le cadre fixé (typiquement : quel problème on veut résoudre), on essaye de déléguer au maximum.

Ensuite, il faut diffuser largement cette priorisation et obtenir le meilleur “buy-in” des parties prenantes. C’est la base du sablier. Les parties prenantes, ce sont par exemple les Customer Success, les Opérations, le Marketing, les Sales… mais aussi la Direction.

Manon Prevot, Captain Contrat

Avec les développeurs pour mesurer l’effort nécessaire
Avec les stakeholders du projet, pour valider l’impact et la méthode de priorisation

Matthieu Le Berre, Guest Suite

Les représentants de chaque équipe (Sales, Market, customer success) au niveau macro : ils sont la voix des prospects et clients. Evidemment aussi avec l’équipe tech qui est au coeur du produit au quotidien.

7/ Que penses-tu des frameworks suivants pour prioriser sa roadmap ?

a. Rice (en savoir plus sur la méthodo)

Olivier Courtois, Uku

Une matrice impact x effort qui exprime mieux ses hypothèses. Je l’utilise régulièrement à ma sauce en décomposant le critère d’impact pour encapsuler les besoins particuliers de la stratégie d’entreprise et du stade de développement du produit. Imaginons que l’entreprise prépare une nouvelle levée (et donc on cherche à créer des retombées dans la presse), je vais créer un champ “Impact sur la communication”.

Charles Buseyne, Equify

C’est une excellente arme anti grandes gueules ! Si tu es dans un contexte très politique, avec des risques de décisions “à la tête du client”, RICE va t’aider à remettre les choses en place et à donner de la confiance à la prise de décision.

Manon Prevot, Captain Contrat

C’est d’après moi le framework le plus précis pour faire une priorisation, mais certains critères peuvent être durs à mesurer, et deviennent imprécis quand on se force à leur donner une note (d’où l’utilité de la note de confiance).

Matthieu Le Berre, Guest Suite
Très efficace car il intègre à la fois des éléments tangibles et l’incertitudes qui structurellement ne peut qu’exister. Mais compliqué pour intégrer par exemple des stakeholders non tech en co-priorisation

b. MoSCoW (en savoir plus sur la méthodo)

Olivier Courtois, Uku

J’aime beaucoup la partie qui exprime les choses à spécifiquement ne pas faire. Pour le reste, je trouve le modèle un peu trop simple car sans mise en valeur des hypothèses.

Charles Buseyne, Equify
Le MoSCoW, avec ses Must-Have et ses Nice-to-Have, on s’en sert beaucoup dans la phase de delivery. On est en “Shape-up”, avec temps fixe et périmètre variable, donc il faut savoir couper et arbitrer. MoSCoW est simple et utile dans ce contexte.

Manon Prevot, Captain Contrat

Intéressant pour séparer ce qui est vraiment nécessaire pour l’utilisateur, ce qui ferait la différence mais qui n’est pas non plus vital, et ce qui est uniquement du “gadget”. Ça sert également à bien se mettre au clair avec tout le monde sur le fait qu’on va “déprioriser” certaines choses qui nous paraissent moins pertinentes (par rapport à notre bande passante ou notre vision produit)

c. Kano (en savoir plus sur la méthodo)

Olivier Courtois, Uku

Bien que j’apprécie l’emphase portée sur les utilisateurs finaux (très nécessaire dans bien des entreprises), ce modèle m’a rarement appris quoi que ce soit et ressemble parfois trop à du design par “comité”. Demander à un utilisateur ce qu’il voudrait est très discutable (versus ce qu’il fait aujourd’hui et quelles alternatives il utilise). Je l’utiliserai avec parcimonie, dans une entreprise où la voix des utilisateurs est trop peu écoutée, en prenant soin d'incorporer de nouvelles features ainsi que des anciennes (pour contrôler que les réponses concordent avec l’usage réel des features existantes).

Charles Buseyne, Equify

Le Kano est intéressant aussi parce qu’il te ramène à ta promesse client, que le RICE peut zapper. Kano te rappelle qu’il y a un seuil minimum, le “basique”, en-deça duquel tu risques de frustrer fortement tes clients et où tu ne tiens juste pas ta promesse. Donc tu le fais. A l’inverse, Kano te rappelle aussi qu’avec un produit juste fait de must-have, tu ne vas pas forcément intéresser grand monde.

Manon Prevot, Captain Contrat

C’est une alternative au MoSCoW plus précise car basée sur des retours utilisateurs concrets. Mais elle est du coup beaucoup moins facile à mettre en place car elle requiert une grande bande passante de user research. Ça marche pour des gros projets sur la priorisation des features, mais pas facilement sur le reste.

d. Weighted Shortest Job First (en savoir plus sur la méthodo)

Olivier Courtois, Uku

Jamais utilisé. De mon point de vue le framework n’est pas si important tant qu’il capture la stratégie de l’entreprise, les besoins fondamentaux des utilisateurs, permet de faciliter les discussions et ne se contente pas de prioriser des sujets peu coûteux (= risque des matrices impacts / efforts). Pour avoir un impact, il faut aussi savoir prendre des paris ambitieux.

Charles Buseyne, Equify

Le WSJF apporte une dimension complémentaire de l’importance : l’urgence. Parfois un sujet doit être pris en premier parce que les autres dépendent de lui. Parfois tu as une date limite non négociable. C’est l’exemple emblématique de Doctolib, Maïa et Keldoc avec la campagne de vaccination l’an dernier. Tu peux aussi être sur un marché de marketplace “Winner takes all” où la vitesse d’acquisition est fondamentale. Comme toujours, c’est d’abord ton contexte stratégique et de marché qui va driver ta priorisation.

Manon Prevot, Captain Contrat

Une alternative au RICE mais qui finalement demande plus de calculs complexes, sachant que tout n’est pas mesurable dans ce qu’on souhaite prioriser. Je trouve ça intéressant sur le papier mais compliqué à mettre en place.

8/ Quels sont les meilleurs frameworks à chaque stade de développement d'une boite ?

Olivier Courtois, Uku

En early-stage : une stratégie posée (= cible d’utilisateurs claire, first use case, objectives) + répondre à la question que faut-il absolument faire dans les 90j ?
En late-stage : un framework qui permet de créer de l’alignement et déployer la stratégie. Dans mon cas, c’est généralement un RICE dont je décompose les critères en fonction de mes besoins.

Charles Buseyne, Equify

J’ai travaillé dans des boîtes de toutes tailles, qui ont chacune itéré sur leurs frameworks, mais je ne peux pas en tirer de règles. La seule chose que je dirais, c’est que tu dois proportionner ton temps d’étude à l’impact de ta décision. Quand ton produit est utilisé par des millions de personnes et mis en oeuvre par des centaines de Techs, c’est normal qu’on te demande de “blinder” davantage ton sujet. En early-stage, tu dois au contraire itérer rapidement et tester tes hypothèses jusqu’à trouver ton Product Market Fit. Te planter n’est pas un droit, c’est presque une obligation !

Manon Prevot, Captain Contrat

Early Stage : on a peu de ressources et peu de bande passante, on a tout à développer, donc on peut utiliser plus facilement le RICE et le MoSCoW
Mid-sized : on peut se permettre d’être plus précis dans la donnée, donc on continue en général à utiliser le RICE et le MoSCoW, mais avec des notes plus précises et en se basant sur plus de data
Scale-up : ces boîtes ont en générale des User Researchers et des Product Analysts, qui sont à 100% sur la discovery, et ont beaucoup plus de data qualitative et quantitative à disposition. Elles peuvent donc se permettre d’aller plus souvent sur du Kano et Weighted Shortest Job First. Pour des priorisations à faire rapidement, le RICE et le MoSCoW sont toujours efficaces et peuvent continuer à coexister avec les autres.

9/ Quelles sont tes ressources préférées sur le sujet de la priorisation ?

Olivier Courtois, Uku

Cet article de Mironov résume bcp ma pensée.

Pour piocher des techniques et les adapter à la situation particulière de son entreprise/son produit, c’est cool de connaître les principaux modèles “communs”.
En voici 20.

Charles Buseyne, Equify

D’abord Rich Mironov, et en particulier Prioritization Beyond Algorithms. C’est brillant et ça nous rappelle qu’aucune formule miracle ne remplacera jamais une bonne stratégie, qui est la base de tout. Et puis Product Management Mental Models for Everyone, de Brandon Chu (déjà recommandé dans Product Inbox #37). Un must-read.