Product Inbox

Share this post

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

productinboxnewsletter.substack.com

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

Timothé Frin
May 5, 2022
25
Share this post

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

productinboxnewsletter.substack.com

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

  • 120+ outils indispensables aux Ă©quipes produit

  • + de 20K ressources sur le product en 30+ databases


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 : 

  1. A partir de quel stade faut-il penser Ă  la priorisation ?

  2. Comment priorises-tu dans ta boite ?

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

  4. Comment faire cohabiter des sujets impactants avec des petits sujets moins impactants ?

  5. Comment mesurer le succĂšs de la priorisation ?

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

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

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

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

Les points principaux à retenir 🧠

  1. La priorisation se fait Ă  tous les stades de dĂ©veloppement d’un produit

  2. Il existe des tas de framework de priorisation dont l’utilisation dĂ©pend de la granularitĂ© des dĂ©cisions Ă  prendre

  3. 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


  4. 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.

  5. 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

  6. Le travail de priorisation se fait main dans la main avec tous les stakeholders d’une entreprise, y compris les utilisateurs

  7. 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

  8. 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 Ă  :

  1. Aligner l’équipe

  2. Déployer la stratégie

  3. 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


💌 Envoie-moi un mail si quelque chose te vient en tĂȘte :) Je lis et rĂ©ponds Ă  tous vos messages.

Pour me soutenir :

Si l’édition t’a plu, ce serait super que tu la partages 🙏

Share

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é

Share this post

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

productinboxnewsletter.substack.com
TopNew

No posts

Ready for more?

© 2023 Timothé Frin
Privacy ∙ Terms ∙ Collection notice
Start WritingGet the app
Substack is the home for great writing