Product Inbox đŹ Focus #6 - Comment bien prioriser ? Le REX de 4 top PM et CPO
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 :
La méthode en 10 étapes pour bien choisir son job de Product
10+ méthodes et modÚles mentaux fondamentaux pour un·e PM
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.Â
10/ Pour aller plus loin
a. Ressources
155 Feature Prioritization Ideas for Product Managers, Jordan Lamborn
Prioritizing at startups, Lenny Rachitsky
Prioritizing a roadmap, Lenny Rachitsky
Ruthless prioritization, Brandon Chu
How to choose your Product Prioritization Framework, Andrew Quan
Enter The Matrix â Lean Prioritisation, Andy Wicks
b. Templates
Simplest possible prioritization framework
Ginaâs sample prioritization template
Optimizelyâs prioritization framework
Lenny Rachitsky favorite roadmap template
đ« Qu'est-ce que Stellar ?
Jâai cofondĂ© Stellar pour accompagner les dirigeants de startups Ă faire de leur Produit un moteur de croissance inarrĂȘtable.
Et pour activer cette croissance, on a créé :
Un collectif de 12 CPO des meilleures boßtes tech (Zenly, Yousign, BlaBlaCar)
Des formats dâintervention rapides (moins dâune semaine)
Des solutions concrÚtes à actionner dans la foulée.
RĂ©sultats : vous amĂ©liorez vos metrics business, votre vitesse dâexĂ©cution et la qualitĂ© de votre Produit.
Nous avons accompagnĂ© 40 clients depuis notre lancement (Zeliq, Edusign, Predict4health, Jaji,âŠ).
Notre ambition : vous faire atteindre vos objectifs business et positionner votre produit en leader de son marché.
Envie de travailler ensemble ?
Pour me soutenir :
Si lâĂ©dition tâa plu, ce serait super que tu la partages đ
Tu peux aussi mâaider en cliquant sur le petit coeur en dĂ©but dâĂ©dition. đ€
A dans 15 jours pour la prochaine Ă©dition đ
Timothé