« L'unique raison pour laquelle les frameworks de priorisation ne fonctionneront jamais, et ce qu'il faut faire à la place » : différence entre les versions

De Wiki Agile
← Modification précédente
VisuelWikicode
Aucun résumé des modifications
Aucun résumé des modifications
 
(18 versions intermédiaires par le même utilisateur non affichées)
Ligne 1 : Ligne 1 :
[[Category: Portail Product Owner]]
[[Category: Portail Product Owner]]
[[Category: Portail Planification]]
[[Category: Portail Planification]]
[[Catégorie:Stratégie]]
[[Catégorie:Rôle du Product Manager]]
Auteur : Michael Goitein<br />
Auteur : Michael Goitein<br />
Source : [https://michaelgoitein.com/the-one-reason-why-prioritization-frameworks-will-never-work-and-what-to-do-instead/ The One Reason Why Prioritization Frameworks Will Never Work, and What to Do Instead]<br />
Source : [https://michaelgoitein.com/the-one-reason-why-prioritization-frameworks-will-never-work-and-what-to-do-instead/ The One Reason Why Prioritization Frameworks Will Never Work, and What to Do Instead]<br />
Ligne 10 : Ligne 12 :
<br />
<br />
[[Fichier:Prioritization-vs-strategy1400.jpg|800px|border|link=]]<br/>
[[Fichier:Prioritization-vs-strategy1400.jpg|800px|border|link=]]<br/>
<small>''WA : Winning Aspiration - WTP : Where to Play - HTW : How to Win - MHC : Must-Have Capabilities - EMS : Enabling Management Systems''</small><br/>


''Le Product Management implique d'être guidé par la stratégie, et non par des algorithmes de priorisation.''<br/>
''Le Product Management implique d'être guidé par la stratégie, et non par des algorithmes de priorisation.''


==Retrouver l'essence du Product Management par rapport à celle du Project Management==
==Retrouver l'essence du Product Management par rapport à celle du Project Management==
Ligne 87 : Ligne 90 :
Dans certains environnements, toutes les données présentées par le PM sont contrées par un "HiPPO" ("Highest-Paid Person's Opinion" / l'Opinion de la Personne la Plus Payée), la partie prenante qui rejette ce score sophistiqué et insiste pour que le PM construise ce qu'on lui a dit de faire.<br/>
Dans certains environnements, toutes les données présentées par le PM sont contrées par un "HiPPO" ("Highest-Paid Person's Opinion" / l'Opinion de la Personne la Plus Payée), la partie prenante qui rejette ce score sophistiqué et insiste pour que le PM construise ce qu'on lui a dit de faire.<br/>
<br/>
<br/>
[[Fichier:HiPPO en.png|800px|border|link=]]<br/>
[[Fichier:HiPPO HowGoogleWorks FR.png|border|link=Google_-_Ne_laissez_pas_votre_HiPPO_tuer_vos_idées|800px]]<br/>
<small>''Souvent, c'est l'opinion de la personne la mieux payée ("HiPPO") qui décide de ce que nous construisons. Via HowGoogleWorks.net.''</small><br/>
<small>''Souvent, c'est l'opinion de la personne la mieux payée ("HiPPO") qui décide de ce que nous construisons. Via HowGoogleWorks.net.''</small><br/>


Ligne 104 : Ligne 107 :


En effet, lorsque les Product Managers en sont réduits à prioriser les fonctionnalités à l'aide de frameworks de priorisation, c'est le signe évident d'un manque de stratégie au sommet de l'entreprise.<br/>
En effet, lorsque les Product Managers en sont réduits à prioriser les fonctionnalités à l'aide de frameworks de priorisation, c'est le signe évident d'un manque de stratégie au sommet de l'entreprise.<br/>
==Quel est le rôle du Product Manager ?==
La tâche est d'autant plus ardue que le Product Manager est responsable du succès de son produit, mais qu'il n'a aucune autonomie dans le choix des fonctionnalités qui le composent.<br/>
<br/>
La direction générale et le service des ventes lui fournissent souvent des listes de fonctionnalités prédéterminées, et il est blâmé lorsque le produit ne donne pas les résultats escomptés - ventes non réalisées, clients qui quittent l'entreprise. Dans ces environnements où les Product Managers ne sont responsables que du développement des fonctionnalités, leur travail est réduit à la gestion de projet.<br/>
<br/>
Ils sont littéralement chargés de déterminer, parmi l'avalanche de fonctionnalités demandées par les parties prenantes dans le backlog de leur équipe, celle qu'ils doivent construire en priorité, et de veiller à ce qu'elle soit livrée le plus rapidement possible.<br/>
===Le Product Management est un rôle stratégique===
Si les Product Managers ont d'innombrables responsabilités, ils ne sont en fin de compte là que pour une seule raison :<br/>
Donner vie à la stratégie de l'organisation à un haut niveau grâce à leur produit, de manière à satisfaire les clients.
C'est tout. Ils sont l'interprète et le concepteur ultimes de l'imbrication de leur stratégie au niveau du produit dans la stratégie organisationnelle globale.<br/>
<br/>
Tout le reste est une sorte de gestion de projet, d'équipe ou de développement.<br/>
===Rareté de la clarté stratégique===
Dans les environnements où la stratégie est mal formulée, voire contestée aux niveaux les plus élevés, ce manque de clarté finit par se répercuter vers le bas, plaçant les Product Managers et leurs équipes sous une pression constante de la part de multiples acteurs.<br/>
<br/>
Ils ont alors recours au "théâtre des priorités".<br/>
<br/>
Mais il est déjà trop tard, car nous établissons des priorités dans le mauvais espace :<br/>
L'espace des Solutions, au lieu de l'espace des Problèmes.
Et [https://www.mironov.com/strat-layers/ Rich Mironov d'écrire] :
"...nous ne pouvons pas prioriser le travail de manière générique, valider les améliorations potentielles auprès de toutes les parties prenantes, ou supposer que chaque segment de clientèle appréciera les bénéfices de la même manière. Selon moi, trier les backlogs et établir des feuilles de route en se basant uniquement sur des feuilles de calcul à plusieurs colonnes, sur le coût du retard ou sur le WSJF est fondamentalement erroné. C'est une faute professionnelle en matière de "Product Management".
Et [https://swkhan.medium.com/why-you-should-avoid-prioritization-frameworks-779a61c0087 Saeed Khan], leader d'opinion en matière de Product Management, d'écrire :
"Vous ne devriez pas donner la priorité aux "fonctionnalités". Oui, j'ai bien dit cela. Les fonctionnalités sont des implémentations liées à des problèmes ou à des opportunités. Vous devriez vous concentrer sur la priorisation des problèmes et des opportunités qui sont liés à des objectifs et des stratégies à un niveau plus élevé. Vous ne devriez pas donner la priorité aux fonctionnalités.
Comme le souligne [https://medium.com/product-manager-hq/what-is-the-best-framework-to-prioritize-what-to-work-on-next-b20c091b1829 Andrea Saez, la priorisation nous fait défaut au niveau le plus élémentaire] :
"Par-dessus tout, les frameworks manquent un aspect fondamental du Product Management : l'empathie".
===Sommes-nous coincés en pleine Paralysie de l'Analyse ?===
Ainsi, lorsque nous nous plaçons dans l'espace de la solution (ou "Output") en donnant la priorité aux fonctionnalités, nous abandonnons notre rôle essentiel de Product Manager.<br/>
<br/>
Nous nous concentrons intrinsèquement et analytiquement sur la planification, plutôt que de donner vie à notre stratégie par le biais de notre produit pour nos utilisateurs finaux.<br/>
<br/>
Car ce qui distingue la stratégie de la planification, c'est la prise de conscience que nous travaillons pour faire avancer quelque chose qui, par nature, échappe à notre contrôle :<br/>
===''Oucomes'' / Résultats===
Un '''résultat''', ou un changement dans le comportement humain, prépare les clients à réussir d'une manière qui leur convient, ainsi qu'à notre entreprise.<br/>
<br/>
Si nous essayons de nous concentrer sur l'obtention de résultats spécifiques en matière de changement de comportement des clients, nous devons travailler à rebours de quelque chose d'autre :<br/>
===Opportunités===
Les opportunités sont les besoins non satisfaits des clients, exprimés avec leurs propres mots.<br/>
<br/>
Ils nous aident à répondre aux questions suivantes :
* Pour qui construisons-nous cette fonctionnalité, afin qu'ils puissent finalement faire quoi ?
* Quels sont les besoins non satisfaits que cette fonctionnalité les aide à satisfaire ?
* Comment cette fonctionnalité est-elle liée aux choix stratégiques de l'entreprise à un niveau plus élevé ?
<br/>
Nous avons donc choisi de prioriser les besoins de nos clients cibles sur les bons canaux et dans les bonnes zones géographiques (nos choix " Où jouer ?"). Pour répondre à ces besoins, nous avons identifié des moyens spécifiques pour les aider à réussir. (Nos choix "Comment gagner ?").<br/>
<br/>
Travailler à rebours à partir du bon problème du client avec les bons choix " Où jouer ?" et " Comment gagner ?" nous aide à comprendre facilement ce qui doit être construit ensuite - aucun framework de priorisation n'est nécessaire.<br/>
<br/>
<br/>
[[Fichier:Outs opps outcs short FR.png|border|900px|link=]]<br/>
[[Fichier:Outs opps outcs short FR.png|border|900px|link=]]<br/>
<small>''La priorisation s'effectue au niveau des opportunités afin d'obtenir des outcomes et un impact sur l'entreprise par le biais de la stratégie. Image de l'auteur.''</small><br/>
<small>''La priorisation s'effectue au niveau des opportunités afin d'obtenir des outcomes et un impact sur l'entreprise par le biais de la stratégie. Image de l'auteur.''</small><br/>


==Comment la stratégie répond aux questions de priorisation==
Dans les environnements où la stratégie est une compétence fondamentale au sein de l'organisation, les Product Managers guident leurs équipes et les parties prenantes pour concevoir ensemble des choix stratégiques au niveau du produit et qui s'inscrivent efficacement dans le cadre d'une stratégie de plus haut niveau.<br/>
<br/>
Malheureusement, la stratégie est plus souvent isolée dans des petits groupes, ou rarement communiquée avec clarté par la direction générale.<br/>
===Nous avons toujours eu une stratégie===
Mais il y a une solution : reconnaître que [https://rogermartin.medium.com/strategy-is-what-you-do-not-what-you-say-a6e483840557 la stratégie est ce que nous faisons déjà, et non ce que nous prétendons faire].<br/>
<br/>
Est-elle bien comprise et clairement énoncée ? Parce que la stratégie est devenue un art perdu, tant dans le domaine de la conception que dans celui de la communication efficace, chose rare. Mais il existe un moyen non seulement de comprendre la stratégie qui sous-tend nos choix actuels, mais aussi de tester sa logique sous-jacente, ce qui nous permet de faire de meilleurs choix stratégiques au niveau du produit.<br/>
<br/>
Les [https://michaelgoitein.com/the-playing-to-win-framework-part-iii-the-strategy-choice-cascade/ cinq boîtes de la Cascade des Choix Stratégiques] représentent un framework éprouvé et solide qui aide les équipes à identifier, tester et concevoir des ensembles de choix stratégiques englobant tout ce qui est nécessaire à la fois pour la "stratégie" et pour l'"exécution".<br/>
<br/>
[[Fichier:Scc5box text.jpg|border|link=|800px]]<br/>
<small>''Les Cinq Boîtes du framework de Cascade des Choix de la Stratégie "Jouer pour gagner". Image de l'auteur tirée du travail de Roger L. Martin.''</small><br/>
<br/>
La Cascade des Choix Stratégiques peut vous aider de trois manières différentes :<br/>
====Rétro-ingénierie de votre stratégie actuelle====
En collaboration avec notre Trio produit et les principales parties prenantes, nous avons procédé à une rétro-ingénierie rapide de notre stratégie actuelle dans les cinq boîtes.<br/>
<br/>
L'essentiel est de ne pas trop réfléchir au processus et de l'aborder de manière rapide et légère. Vous voulez commencer à mettre votre stratégie implicite dans un espace où vous pouvez la voir.<br/>
<br/>
[[Fichier:Reverse-engineering example strategy using the Strategy Choice Cascade.png|border|link=|800px]]<br/>
<small>''Rétro-ingénierie de la stratégie d'OŪRA Ring à l'aide de la Cascade des Choix Stratégiques. Image de l'auteur.''</small><br/>
<br/>
À partir de cette base stratégique claire, il est généralement toujours facile de savoir ce qu'il faut faire ensuite.<br/>
====Se demander "Qu'est-ce qui devrait devenir vrai ?"====
Maintenant que nous connaissons nos choix stratégiques, nous voulons poser la question la plus importante en matière de stratégie : [https://rogermartin.medium.com/what-would-have-to-be-true-83dac5bd2189 "Qu'est-ce qui devrait devenir vrai ?"]<br/>
<br/>
Cette question peut sembler subtile, mais elle représente un changement majeur. Habituellement, il s'agit de l'opinion d'une personne par rapport à une autre sur ce qu'elle croit être vrai. En passant de la question "Qu'est-ce qui est vrai ?" à "Qu'est-ce qui devrait devenir vrai ?", nous sommes en mesure de tester la logique qui sous-tend trois forces essentielles : les Clients, l'Entreprise et la Concurrence.<br/>
<br/>
En tant que groupe, nous posons la question "Qu'est-ce qui devrait devenir vrai ?
* '''Nos clients''' : qu'est-ce qui devrait arriver à nos clients pour qu'ils adhèrent à ces choix ?
* '''Notre entreprise''' : qu'est-ce qui devrait arriver à notre entreprise pour qu'elle soit en mesure de répondre efficacement à ces choix ?
* '''Notre concurrence''' : qu'est-ce qui devrait arriver à nos concurrents pour qu'ils réagissent à nos choix ?
====Demander quel serait le plus grand obstacle à notre réussite ?====
Sur la base des réponses à nos questions "Qu'est-ce qui devrait arriver ?", nous pouvons maintenant tirer parti de l'expertise de l'équipe qui procède à la rétro-ingénierie de la stratégie.<br/>
<br/>
Quelqu'un pourrait souligner que les clients n'utilisent pas la solution que nous leur avons fournie, malgré l'avalanche de documents marketing et d'efforts de formation insistant sur le fait qu'ils le font. Il pourrait même y avoir des données à l'appui, comparant l'utilisation prévue à l'utilisation réelle.<br/>
<br/>
Il est tout aussi important de savoir pourquoi les clients n'ont pas adopté notre produit en discutant avec eux. La condition "Qu'est-ce qui devrait arriver ?" ne tient donc pas et les efforts déployés pour tester et lever cet obstacle majeur orienteront la feuille de route.<br/>
<br/>
L'identification et l'élimination de ces obstacles dans les espaces d'Opportunité et de Résultat / ''Outcome'' fourniront un cadre de référence pour ajuster nos choix et apporteront une plus grande clarté dans l'approche de la feuille de route de notre produit.<br/>
==A retenir & TL;dr (''trop long, pas lu'')==
Les Product Managers n'ont pas à être réduits à des Project Managers priorisant des listes de fonctionnalités demandées.<br/>
<br/>
Cette approche fonctionnera même si nous sommes coincés dans une "usine à fonctionnalités", même si personne ne peut ou ne veut articuler clairement notre stratégie. En prenant du recul et en cartographiant notre stratégie actuelle avec notre équipe clé et nos parties prenantes, nous aurons enfin la possibilité de faire des choix qui s'alignent sur les choix stratégiques faits à des niveaux plus élevés.<br/>
<br/>
La Cascade des Choix Stratégiques offre un framework éprouvé qui expose et teste la logique sous-jacente à notre stratégie produit, l'aidant ainsi à s'imbriquer et à s'aligner efficacement sur la stratégie de l'entreprise à un niveau plus élevé.<br/>
===Vous ne savez pas quoi construire ensuite ?===
* '''Faites une rétro-ingénierie collaborative de votre stratégie actuelle''' afin de l'aligner sur celle de votre équipe et de vos parties prenantes.
* '''Demandez ce qui devrait devenir vrai ?''' à propos des clients, de l'entreprise et des concurrents pour que ces choix se réalisent.
* '''Identifier les plus grands obstacles.''' Au lieu de vous concentrer sur l'espace de la solution "Output", concentrez-vous plutôt sur les plus grands obstacles dans l'espace de l'opportunité client et du résultat du changement de comportement. Priorisez les éléments do Continuous Discovery pour surmonter ces obstacles.
<br/>
À partir de cette base stratégique claire, il est toujours facile de savoir ce qu'il faut construire ensuite.
==Références==
* '''Rich Mironov - La stratégie produit dépend de la stratégie de l'entreprise''' : https://www.mironov.com/strat-layers/
* '''Roger L. Martin - La stratégie, c'est ce que l'on FAIT, pas ce que l'on DIT''' : https://rogermartin.medium.com/strategy-is-what-you-do-not-what-you-say-a6e483840557
* '''Roger L. Martin - Qu'est-ce qui devrait devenir vrai ?''' : https://rogermartin.medium.com/what-would-have-to-be-true-83dac5bd2189
* '''Saeed Khan - Pourquoi vous devez éviter les frameworks de priorisation''': https://swkhan.medium.com/why-you-should-avoid-prioritization-frameworks-779a61c0087
* '''Andrea Saez - Quel est le meilleur framework pour prioriser ce sur quoi il faut travailler ensuite ?''' : https://medium.com/product-manager-hq/what-is-the-best-framework-to-prioritize-what-to-work-on-next-b20c091b1829
<br/>
----
----
[[Fichier:Outs opps outcs short EN.jpg|border|900px]]
[[Fichier:Outs opps outcs short EN.jpg|border|900px]]
Récupérée de "https://wikiagile.coach/L%27unique_raison_pour_laquelle_les_frameworks_de_priorisation_ne_fonctionneront_jamais,_et_ce_qu%27il_faut_faire_à_la_place"