Voir la source de Planification à l'aide de roadmaps de résultats

[[Catégorie:Itamar Gilad]]
[[Category: Rôle du Product Manager]]
[[Category: Portail Planification]]
Auteur : Itamar Gilad<br />
Source : [https://itamargilad.com/outcome-roadmaps/ Planning With Outcome Roadmaps]<br />
----
Traducteur : Fabrice Aimetti<br />
Date : 10/03/2024<br />
Crédit : Vincent Billon<br/>
----
Traduction :<br />
<br/>
À l'heure où j'écris ces lignes, le cycle de planification annuel tant redouté arrive à grands pas et le débat sur les roadmaps refait surface. D'une part, il est clair que les roadmaps classiques qui présentent les versions sur une ligne de temps entraînent à la fois des coûts de planification élevés et un gaspillage important. D'autre part, les tentatives d'élaboration de roadmaps autour de résultats et de thèmes (souvent sans calendrier) peuvent laisser l'organisation sur sa faim. Les roadmaps classiques sont très prometteuses : elles permettent de planifier les ressources, de suivre les progrès et de coordonner les lancements. Bien qu'elles ne tiennent pas vraiment leurs promesses, le désir de disposer de ces éléments n'est pas près de disparaître.<br/>
<br/>
Et si nous essayions de combiner les deux mondes - une roadmap des résultats qui montre le travail réel effectué pour atteindre les objectifs, selon un calendrier. Une telle roadmap permet de communiquer efficacement les éléments que la plupart des roadmaps omettent, tout en soulignant que le plan doit être adapté au fur et à mesure de la découverte de nouvelles données.<br/>
<br/>
Les éléments de cette roadmap sont les suivants 
* Objectifs
* Recherche (facultatif) 
* Product Discovery (découverte du produit)
* Product Delivery (livraison du produit)
* Effet Retard
<br/>
Voici à quoi pourrait ressembler une telle feuille de route pour un seul objectif.<br/>
<br/>
[[Fichier:Outcome-Roadmap-Single-Goal.jpg|border|link=|1000px]]<br/>
<small>''Une roadmap de résultats pour un seul objectif, présentée sur une ligne de temps''</small><br/>
<br/>
Voici un [https://itamargilad.com/outcomes-roadmap-template/ modèle de roadmap de résultats sur Miro] que vous pouvez copier. <br/>
<br/>
Examinons de plus près chaque élément de la roadmap.<br/>

==Objectifs==
Une omission flagrante dans la plupart des roadmaps de production est qu'il n'y a pas d'objectifs visibles. Il n'y a que des livrables (''outputs''), pas de résultats (''outcomes''). Un bon point de départ consiste donc à essayer de faire figurer les objectifs de l'entreprise sur une ligne de temps.<br/>
<br/>
[[Fichier:Outcomes-Roadmap-1536x755.jpg|border|link=|1000px]]<br/>
<br/>
Si vous êtes familiarisé avec les objectifs et les résultats clés (''OKR''), ce diagramme devrait être assez facile à comprendre. Les quatre lignes représentent les quatre objectifs annuels de l'entreprise, quelque peu abrégés. Le losange indique la date à laquelle l'objectif sera atteint, et nous ajoutons un ou plusieurs résultats clés qui indiquent ce qu'est la réussite. Je n'en ai cité qu'un seul par souci de simplicité, mais le tableau des OKR peut en comporter d'autres.<br/>
<br/>
La présentation de vos objectifs sur une ligne de temps comme celle-ci nous aide déjà à évaluer si nous sommes ambitieux tout en restant réalistes. Les CTO expérimentés peuvent détecter à partir d'une telle image si l'organisation de développement va être trop sollicitée. Naturellement, il s'agit là d'estimations très approximatives que vous devrez ajuster au fur et à mesure que vous avancerez, comme pour tout plan.<br/> 
<br/>
Vous pouvez vous arrêter à ce niveau et, dans certains cas, cette structure est suffisante pour démarrer. Mais si vous souhaitez une planification plus claire, vous pouvez zoomer sur chacun des objectifs et planifier le travail nécessaire pour les atteindre.<br/>

==Recherche et idéation==
La première étape pour atteindre un objectif consiste à se demander si l'on comprend suffisamment le contexte pour effectuer un travail significatif. Le contexte peut inclure les besoins des clients, les technologies applicables, le paysage concurrentiel et les partenaires, les défis et les opportunités, etc. Par exemple, si nous souhaitons réduire le taux de désabonnement (''churn''), savons-nous ce qui pousse les clients à se désabonner ? Si nous souhaitons lancer notre produit dans de nouveaux pays, savons-nous quel pays présente la meilleure opportunité ?<br/> 
<br/>
Il est tentant de répondre à ces questions par un oui. Les clients se désabonnent parce que nous n'avons pas les fonctionnalités A, B et C. Le meilleur pays pour le prochain lancement est l'Inde parce qu'il y a une demande massive pour notre type de produit. Mais il faut alors être honnête et se poser la question suivante : dans quelle mesure sommes-nous sûrs de ces hypothèses ? En d'autres termes, quelles sont les preuves ?<br/> 
<br/>
L'indicateur de confiance peut vous aider à calibrer vos hypothèses :<br/>
<br/>
[[Fichier:Confidence-Meter-900px.jpg|border|link=|1000px]]<br/>
<small>''L'indicateur de confiance (téléchargez la calculatrice gratuite [https://itamargilad.com/resources/confidence-meter-calculator/ ici]''</small><br/>
<br/>
Si votre conviction repose sur des opinions, des thèmes ou des preuves anecdotiques, votre confiance dans vos hypothèses doit être faible. Dans ce cas, il est préférable de consacrer du temps à la recherche, également connue sous le nom de recherche exploratoire ou générative, et de porter le niveau de confiance à moyen-faible ou moyen.<br/> 
<br/>
Il existe de nombreux types de recherches : études d'utilisateurs, études de marché, études concurrentielles, études technologiques, etc. Vous devez décider du type de recherche à mener et y consacrer le temps et les ressources nécessaires.<br/>  
<br/>
La recherche n'est pas un vilain mot - une once de recherche peut vous épargner une tonne de travail inutile à la recherche d'opportunités qui n'existent pas. Les résultats de la phase de recherche doivent être clairs : des idées (''insights'') et des opportunités étayées par des preuves de niveau moyen à faible.<br/> 
<br/>
La recherche mène souvent à l'idéation, c'est-à-dire à l'élaboration de moyens potentiels pour atteindre l'objectif. D'autres idées viendront en dehors de votre recherche - de la part des clients, des managers, des parties prenantes et des membres de l'équipe. Tout cela est normal et sain. Nous devons recueillir toutes les idées que nous trouvons pour les utiliser dans la phase suivante.<br/>

==Product Discovery==
Une fois que nous avons une bonne compréhension du contexte et une première ébauche d'idées, nous pouvons nous lancer dans la product discovery.  La product discovery (terme défini par [[L'Origine du Product Discovery|Marty Cagan (fr)]]) est un vaste sujet traité par de nombreux auteurs et le thème principal de mon livre Evidence-Guided (''Guidé par les faits''). En bref, lors de la product discovery, nous évaluons et validons plusieurs idées par rapport à l'objectif, en éliminant celles qui ne fonctionnent pas et en redoublant d'efforts pour celles qui fonctionnent.<br/>
<br/>
[[Fichier:GIST-Core-900px.jpg|border|link=|1000px]]<br/>
<small>''Source de l'image : [http://evidenceguided.com/ Evidence-Guided] : Créer des produits à fort impact face à l'incertitude.''</small><br/>
<br/>
Le résultat de la Product Discovery est un petit ensemble d'idées suffisamment validées pour passer à l'étape de delivery. On me demande souvent combien de temps il faut consacrer à la discovery, et la réponse est le temps qu'il faut, car si l'on abrège, on risque de construire les mauvaises choses. Toutefois, vous pouvez fixer un délai pour votre travail de discovery, en sachant que si vous n'avez pas trouvé d'idées validées dans un délai de quatre semaines, par exemple, vous passerez à un autre objectif ou reviendrez à un travail de recherche pour trouver d'autres idées.<br/>

==Product Delivery==
Une fois que nous avons découvert une idée susceptible de contribuer à l'objectif, l'étape suivante consiste à la construire et à la lancer. Avec un peu de chance, une seule idée permettra d'atteindre l'ensemble de l'objectif, mais il en faudra souvent plusieurs. La plupart des idées qui ont fait l'objet d'une product discovery sont déjà partiellement développées, et vous devriez avoir une bien meilleure idée du temps et des efforts qu'il faudra consacrer à leur réalisation.<br/> 
<br/>
Notez que cette partie de la roadmap est équivalente à la roadmap classique - une série de projets avec des lancements concrets sur une ligne de temps. Hélas, en l'absence de recherche et de product discovery, nous ne pouvons pas prédire quelles seront ces idées et combien de temps il faudra pour les développer. Commencer par cette partie de la roadmap n'est donc pas du tout une bonne idée.<br/>

==Effet retard==
Les résultats que vous essayez d'obtenir (par exemple un taux de fidélisation des clients plus élevé) n'apparaissent souvent pas immédiatement après le lancement ; il y a généralement un certain délai dû au calendrier de déploiement, au calendrier des ventes/du marketing, au délai d'adoption, etc. Lorsque nous établissons une roadmap pour les résultats plutôt que pour les lancements, nous devons également tenir compte de ces délais. L'équipe produit est généralement libre de travailler sur d'autres choses pendant cette période, mais nous devons continuer à suivre les résultats même après le lancement.<br/>
<br/>
Voici deux objectifs mis côte à côte, la partie relative au product delivery étant toujours indiquée comme "TBD - To-Be-Determined" (à gauche), tandis que la partie relative aux 3 idées est mise en évidence (à droite) :<br/>
<br/>
[[Fichier:Full-outcome-roadmap-Miro-1.jpg|border|link=|1000px]]<br/>
<br/>
'''Techniques avancées :''' voici quelques idées d'experts en matière de roadmap. [https://www.linkedin.com/in/jannabastow/ Janna Bastow], PDG et cofondatrice de ProdPad, recommande le modèle de lancement en douceur, dans lequel le changement de produit est d'abord "lancé" auprès des ventes et du marketing, qui préparent ensuite le lancement proprement dit. Un autre modèle consiste à lancer les changements, puis à prévoir des "ajustements" après le lancement afin d'optimiser les changements et d'améliorer les résultats (source : [https://www.linkedin.com/in/brucemccarthy/ Bruce McCarthy], auteur de Product Roadmaps Relaunched) - il s'agit essentiellement de lancer et d'itérer, mais la partie "itérer" est budgétisée dans la roadmap.<br/> 
<br/>
Voici le [https://itamargilad.com/outcomes-roadmap-template/ modèle complet de roadmap des résultats (Miro Board)] que vous pouvez utiliser comme point de départ.

==Conclusion==
Je ne vous recommande pas nécessairement d'utiliser ce format de roadmap, mais si vos managers et les parties prenantes insistent pour avoir un plan assorti d'un calendrier, il peut être utile de le présenter et d'organiser une discussion. Points clés à aborder :
* Voulons-nous obtenir des résultats ou des lancements ?
*Pouvons-nous être certains d'avoir trouvé les bonnes idées sans recherche ni product discovery ? 
*La recherche et la product discovery contribuent-elles à la réalisation des objectifs de l'entreprise (je soutiens que oui) ? 
*Ce modèle est-il plus lent ? dans quel sens : le temps de production des objets ou le temps d'obtention des résultats ?
<br/>
Cette discussion sera au cœur du désaccord sur les roadmaps de livrables (''output''), mais j'espère que vous serez mieux armé pour faire valoir votre point de vue. L'objectif n'est pas de s'opposer à la planification, mais de la rendre honnête et adaptable.