Dix méthodes pour réussir grâce à une présentation de feuille de route produit

La présentation d'une feuille de route produit peut aussi bien donner des sueurs froides aux développeurs qu'aux responsables produit : les uns ont travaillé dur pour proposer une vision et les autres font face à une inconnue qui va influencer leur travail.

J'ai moi-même ressenti cette tension lorsque je travaillais comme développeur, et les feuilles de route élaborées par les gestionnaires de produits me laissaient souvent sur ma faim. Les décisions ne me convenaient pas toujours. Je quittais souvent les réunions de planification en me disant : « Cela me paraît insensé, mais s'ils le voient de cet œil… » ou pire : « Nous allons nous débrouiller nous-mêmes et donner l'impression que ce que nous faisons correspond à la feuille de route. »

Vous me direz peut-être que le problème venait probablement du fait que j'avais développé le syndrome NIH (Not Invented Here ou ce n'est pas moi qui l'ai inventé) et vous auriez raison. En tant que développeur, j'avais des opinions bien arrêtées sur la marche à suivre. À présent que je suis responsable produit, je me rends compte de ce qui creusait cet écart et des leçons que mes pairs peuvent tirer pour faire l'unanimité en présentant leur prochaine feuille de route. Après tout, si l'équipe technique accepte et comprend l'idée générale, les décisions quotidiennes sur la conception et l'implémentation seront prises dans un contexte adéquat. Vous obtiendrez ainsi les produits que vous aviez imaginés.

Voici mes dix grandes méthodes pour rallier des équipes grâce à une présentation de feuille de route produit.

Si des expressions en vogue comme « analytique Big Data », « machine learning » et « initiative IoT (Internet of Things) » sont perçues comme des points d'ancrage de haut niveau dans le monde des affaires, elles sont inutiles et inexploitables pour les équipes techniques. Les ingénieurs ont besoin de savoir ce qu'ils développent, en quoi leur travail concerne les produits actuels, de quelle manière le produit sera livré, qui sera l'utilisateur final et à quelle fin le produit sera utilisé.

Définir des thèmes majeurs pour structurer la feuille de route et le contexte est une bonne idée, mais veillez à ne pas vous arrêter en si bon chemin et tenez-vous prêt à répondre à des questions sur les aspects qui se cachent derrière ces grands thèmes. Par exemple, si vous avez intitulé l'un de vos thèmes « Services intelligents », assurez-vous de le décomposer en initiatives et epics clés nécessaires à la réalisation du projet concerné.

Les équipes techniques ont besoin d'un contexte qui leur explique pourquoi tel ou tel élément figure dans la feuille de route. Aucune équipe technique ne vous dira : « Dis-moi simplement ce que tu veux et je te le développe. » Au contraire, les ingénieurs ont besoin de preuves démontrant la nécessité d'une fonctionnalité. Laissez parler les données, mais racontez aussi une histoire convaincante du point de vue de vos utilisateurs. Utilisez des personas, parlez de certaines solutions que vous avez rejetées et expliquez pourquoi. L'objectif ? Aider toute l'équipe à comprendre la feuille de route, sachant que la question du « pourquoi ? » revêt autant d'importance que celle du « quoi ? ».

Si un élément semble irréfléchi ou irréaliste et qu'il figure quand même dans la feuille de route, c'est qu'il y a un problème. Vous ne voulez pas donner l'impression à votre équipe technique qu'elle doit développer une fonctionnalité jusque parce que vous l'avez promis à quelqu'un. Par exemple, parce que vous vous êtes engagé auprès d'un client ou parce que « la direction en a décidé ainsi ». Bref, soyez prudent lorsqu'il est question d'engagement. Même si vous sentez qu'une pression repose sur vous pour effectuer un changement en particulier, veillez à bien comprendre et à transmettre le raisonnement à l'équipe, et à vous y tenir personnellement.

Avoir une vision, c'est bien. Mais si tout le monde est convaincu qu'elle est réalisable, c'est encore mieux. Le plan ne doit pas forcément être précis, mais si la première chose qu'un responsable du développement voit lorsqu'il examine une feuille de route est un énorme goulot d'étranglement (par exemple, si la feuille de route est axée sur la conception et le front-end, mais que l'équipe compte un seul concepteur et a rencontré des difficultés en rapport avec le front-end ces derniers mois), attendez-vous à ce qu'il descende votre feuille de route pendant tout le reste de votre présentation.

Veillez à confronter vos idées à la réalité avec l'équipe en amont et imaginez des scénarios hypothétiques. Vous devez préparer des réponses, élaborer un plan d'action clair et envisager un tant soit peu la « marche à suivre » avant de demander à tout le monde de s'engager.

Vous devez savoir quels sont les atouts d'un produit et de l'équipe, tant aujourd'hui que demain. C'est bien de se développer dans de nouveaux domaines, qui nécessitent certainement de nouvelles compétences au sein de l'équipe ou une rupture avec les technologies actuelles, mais ne vous contentez pas de noter vos rêves pour l'année prochaine. Pensez plutôt à une manière réaliste de les concrétiser. Acquérir des talents et adopter de nouvelles technologies prend du temps. Délaisser les produits existants requiert de prendre des engagements clairs et d'élaborer un plan de transition.

Business case, dites-vous ? Oui. Les équipes techniques s'intéressent aux business cases. Peut-être pas autant que les responsables seniors, mais tous les membres d'une équipe de développement veulent savoir pourquoi un produit est pertinent pour l'entreprise, s'il génère des résultats concrets et comment ces résultats seront mesurés. Appuyez-vous sur les membres de l'équipe les plus aguerris. Chacun est directement concerné par la réussite de l'entreprise dans son ensemble et peut apporter de précieux commentaires et idées.

En outre, avoir une vision claire de l'impact sur l'entreprise et assister à la réalisation des objectifs peut être un bon facteur de motivation. Développer et livrer une fonctionnalité, c'est bien, mais obtenir des résultats, c'est encore mieux.

Les ingénieurs veulent développer des produits uniques et innovants dont ils peuvent être fiers. Si vous utilisez la même histoire que celle déjà ressassée par vos prédécesseurs, vous risquez de les démotiver. Faites des recherches pour vous assurer que votre histoire est aussi originale que vous le pensez. Outre des développeurs découragés, le manque de créativité peut avoir des conséquences encore plus désastreuses sur l'entreprise.

Cela dit, les feuilles de route elles-mêmes nécessiteront toujours de trouver un équilibre entre de nouvelles fonctionnalités intéressantes et des tâches moins passionnantes d'un point de vue technique, mais qu'il faut tout de même accomplir. Faites en sorte que même les tâches banales sur votre feuille de route soient motivantes.

Si créer un produit minimum viable puis une version 1 est une chose, pensez aussi à toutes les étapes qui suivent le lancement : opérations, maintenance, demandes de fonctionnalités de la part des utilisateurs, améliorations continues et création de nouvelles versions d'autres produits et/ou de plateformes intégrés. Si vous pensez rapidement aux défis et obstacles qui pourraient survenir après le lancement, vous n'aurez aucun mal à entrevoir la suite des événements et les ingénieurs vous seront reconnaissants d'avoir tenu compte de ces réalités. Selon des estimations approximatives, les efforts initiaux consentis pour développer une nouvelle fonctionnalité ne représentent que la moitié, voire un tiers de l'ensemble des efforts déployés pendant toute sa durée de vie. En d'autres termes, la suite est plus lourde de conséquences que le développement initial et certains « détails insignifiants » peuvent prendre des proportions considérables à long terme.

Les estimations sont utiles. Elles donnent des orientations et sont fondées sur les connaissances les plus approfondies du gestionnaire de produit à un moment donné. Cependant, beaucoup d'hypothèses se révèlent totalement inexactes lorsque vous passez à l'implémentation ou au peaufinage du design. Veillez à préparer et à présenter la feuille de route de manière à pouvoir la modifier en toute flexibilité.

Une feuille de route sert à donner des orientations. Il ne s'agit pas d'un plan d'exécution détaillé. Tous les membres d'une équipe de développement en sont conscients. Il n'est pas nécessaire de la vendre comme quelque chose de différent de ce qu'elle est. Par conséquent, si vous ne possédez pas encore tous les détails concernant un sujet, jouez franc-jeu. Exposez ce que vous savez, le but recherché, les questions ouvertes et les risques auxquels il faut encore remédier. Signalez les domaines qui nécessitent une expérimentation et des recherches plus approfondies pour répondre avec précision à la question du « quoi ? ». N'oubliez pas de prendre en compte ce temps d'expérimentation dans la planification.

Votre équipe mérite une feuille de route qui présente une vue d'ensemble, sans pourtant négliger les réalités. En outre, votre équipe mérite une feuille de route motivante et palpitante, qui inclut suffisamment d'informations pour que tous les membres sachent quelles seront leurs tâches au cours des quelques prochains sprints, convaincus qu'ils obtiendront de bons résultats avec un impact concret sur l'entreprise.

Besoin d'aide supplémentaire ? Consultez les fonctionnalités de feuille de route dans Jira Software et un modèle de feuille de route produit dans Jira. Sinon, essayez gratuitement l'outil conçu pour les responsables produit : Jira Product Discovery.