10 erreurs de roadmap produit à éviter

De Wiki Agile
Aller à : navigation, rechercher

Auteur : Roman Pichler
Source : 10 Product Roadmapping Mistakes to Avoid
Date : 01/11/2022


Traducteur : Fabrice Aimetti
Date : 07/11/2022


Traduction :

Photo-road-plenio-unsplash.jpeg
Photo de Johannes Plenio sur Unsplash

La feuille de route du produit est un excellent outil de gestion du produit. Mais elle peut causer des problèmes importants lorsqu'elle n'est pas utilisée de manière appropriée. Cet article présente dix erreurs à éviter pour tirer pleinement parti de votre feuille de route.

Vous pouvez écouter la version audio de cet article ici : https://www.romanpichler.com/podcast/product-roadmapping-mistakes-to-avoid/.

La feuille de route du produit est une planification basée sur les fonctionnalités

Les feuilles de route de produits traditionnelles sont généralement des planifications axées sur les résultats qui établissent une liste de fonctionnalités, telles que la saisie, la recherche et la création de rapports, selon un calendrier. Une telle feuille de route indique essentiellement quand un bout de fonctionnalité sera livré. Cela peut être rassurant pour les clients et les parties prenantes. Mais elle présente les trois inconvénients suivants :

  1. Une feuille de route basée sur les fonctionnalités peut faire naître et renforcer un état d'esprit d'usine à fonctionnalités où l'ajout de fonctionnalités est plus important que la création de valeur et l'impact positif sur la vie des gens et de l'entreprise.
  2. En se concentrant sur les fonctionnalités, on risque de transformer la feuille de route en un plan tactique qui se superpose au backlog du produit, en particulier lorsque des fonctionnalités à fine granularité sont utilisées. Cela rend la feuille de route plus difficile à comprendre et augmente les efforts pour la maintenir à jour.
  3. Une feuille de route de produit basée sur des fonctionnalités peut facilement être confondue avec un engagement plutôt qu'une planification de haut niveau susceptible d'évoluer. Les parties prenantes ne seront pas les seules à être déçues. Cela limitera également votre capacité à expérimenter et à apprendre, à organiser des sprints et à découvrir la meilleure façon de répondre aux besoins des utilisateurs et des clients et de créer de la valeur pour l'entreprise.

Vous pouvez éviter ces inconvénients en utilisant un autre type de feuille de route : une feuille de route produit axée sur les objectifs ou les résultats. Comme son nom l'indique, cette feuille de route se concentre sur les objectifs et les résultats du produit, tels que l'acquisition de clients, l'augmentation de l'engagement et la pérennisation du produit en éliminant la dette technique. Certaines fonctionnalités à grosse granularité peuvent encore être utilisées, mais elles dépendent désormais des objectifs : chaque fonctionnalité doit servir un objectif et être nécessaire pour créer un résultat spécifique.

Un outil pratique pour créer une feuille de route axée sur les objectifs est ma feuille de route produits (GO product roadmap), que vous pouvez télécharger gratuitement en cliquant sur l'image ci-dessous.

The-GO-Product-Roadmap EN.png

Les objectifs de la feuille de route sont des fonctionnalités déguisées

Si les feuilles de route axées sur les objectifs peuvent être très bénéfiques, elles ne sont pas toujours appliquées efficacement. Une erreur fréquente que je vois commettre par les gens du produit est d'utiliser des objectifs produits qui sont des fonctionnalités déguisées. Disons que je suis sur le point de créer une feuille de route pour un produit d'alimentation équilibrée. Les deux énoncés "mesurer l'apport calorique" et "déterminer le taux de glycémie" seraient-ils alors considérés comme des objectifs produit ? Je ne le pense pas. Dans mon esprit, elles décrivent les capacités ou les fonctionnalités du produit, et elles caractérisent la solution. Elles n'indiquent pas pourquoi il est intéressant de faire progresser le produit.

Veillez donc à ne pas confondre objectifs et fonctionnalités. Veillez à ce que les objectifs de votre produit reflètent toujours le résultat souhaité que le produit doit créer, et non la production. Un bon test pour comprendre si un objectif produit décrit un résultat est de poser la question du pourquoi. Par exemple, je pourrais me demander pourquoi il serait utile de mesurer l'apport calorique. La réponse révélerait alors le véritable objectif, tel que "aider les utilisateurs à améliorer leurs habitudes alimentaires".

Les parties prenantes déterminent le contenu de la feuille de route

Vos parties prenantes vous demandent-elles d'ajouter des fonctionnalités spécifiques à la feuille de route produit ? Si c'est le cas, vous n'êtes pas seul. Il n'est pas rare que les feuilles de route des produits soient déterminées par les demandes des parties prenantes et que certaines d'entre elles souhaitent que "leurs" fonctionnalités soient incluses.

S'il est important d'écouter activement les parties prenantes, vous ne devez pas les laisser dicter le contenu de la feuille de route. Votre travail ne consiste pas à faire plaisir aux parties prenantes, mais à assurer le succès du produit. Si vous acceptez toutes les demandes, vous risquez de créer un produit Frankenstein, c'est-à-dire un produit constitué d'un ensemble de fonctionnalités sans rapport les unes avec les autres, offrant une proposition de valeur médiocre et donnant lieu à une expérience utilisateur médiocre.

Déclinez les demandes des parties prenantes si elles ne sont pas alignées sur la stratégie produit. Si elles le sont, recherchez un objectif produit que la fonctionnalité soutient. S'il n'y en a pas, ajustez la planification en modifiant un objectif existant ou en en introduisant un nouveau, ou rejetez la demande de fonctionnalité. Cela suppose, bien sûr, que vous êtes suffisamment autonome et que vous avez le dernier mot sur les décisions stratégiques relatives au produit.

La personne en charge du produit crée la feuille de route toute seule

Une autre erreur courante de planification est l'inverse de celle qui vient d'être décrite : la personne en charge du produit crée la feuille de route toute seule, sans aucune contribution des parties prenantes et des équipes de développement.

Cette approche est problématique pour les trois raisons suivantes :

  1. Elle ne permet pas de tirer parti de la créativité et des connaissances des parties prenantes et des équipes de développement. Elle risque d'aboutir à une feuille de route de produit sous-optimale.
  2. Elle risque de créer une planification qui n'est pas claire pour les parties prenantes et les membres de l'équipe de développement, qui manque d'une compréhension commune et qui n'est pas adaptée à la situation. Elle risque de créer une planification qui n'est pas claire pour les parties prenantes et les membres de l'équipe de développement, qui manque de vision partagée et qui entraîne un désalignement.
  3. Les gens sont moins susceptibles de soutenir une feuille de route produit s'ils n'ont pas eu l'occasion d'y contribuer. Dans le pire des cas, les parties prenantes et les équipes de développement n'adhèrent que du bout des lèvres à la planification, partent dans des directions différentes et suivent leurs propres objectifs.

Vous devez donc adopter une approche collaborative en impliquant les principales parties prenantes et les membres de l'équipe de développement dans la création, la revue et la mise à jour de la feuille de route produit, de préférence sous la forme d'ateliers collaboratifs. Efforcez-vous d'élaborer une planification qui contribue à maximiser la valeur créée par votre produit tout en recueillant le plus de soutien possible, comme je l'explique plus en détail dans mon article Making Effective Product Decisions.

La feuille de route n'est pas systématiquement reliée à la stratégie et au backlog

Si la feuille de route produit est une planification à part entière, c'est une erreur de la créer et de la gérer de manière isolée. Il en résulterait une feuille de route qui n'est pas alignée sur la proposition de valeur du produit et les objectifs de l'entreprise, et un backlog produit qui n'est pas lié à la feuille de route. Ce qui, à son tour, peut conduire à des décisions incohérentes et erronées concernant le produit : les décisions stratégiques n'orientent pas les décisions tactiques, et les enseignements tirés du développement ne permettent pas de faire progresser la feuille de route.

Mon modèle de stratégie produit, présenté ci-dessous, positionne la feuille de route du produit entre la stratégie et le backlog : la feuille de route indique comment la stratégie sera mise en œuvre dans les mois à venir, et elle oriente le backlog produit. La feuille de route est réalisée en traduisant les besoins et les objectifs métiers énoncés dans la stratégie produit en objectifs produit. Et l'objectif produit suivant est utilisé pour orienter le backlog produit.

Product-roadmap-between-strategy-and-backlog EN.png

La feuille de route est une planification figée

Certaines personnes confondent la feuille de route produit avec une planification figée qui doit être exécutée. Mais toute feuille de route est basée sur ce qui est actuellement connu. Au fur et à mesure que vous commencez à la mettre en œuvre et que vous en apprenez davantage sur la façon de répondre au mieux aux besoins des utilisateurs, des clients et de l'entreprise, la feuille de route du produit est susceptible de changer. C'est une bonne chose : cela vous aide à maximiser la valeur créée par le produit et à offrir le meilleur produit possible, au lieu de suivre aveuglément une planification qui pourrait être obsolète. Vous devez donc revoir et adapter la feuille de route régulièrement.

Pour ce faire, tenez compte de tout changement de stratégie produit, de l'avancement du développement et des modifications plus importantes du backlog produit qui peuvent affecter la feuille de route. En règle générale, évaluez la feuille de route produit avec les principales parties prenantes et les membres de l'équipe de développement au moins une fois tous les trois mois. Envisagez de combiner les revues de la stratégie et de la feuille de route pour vous assurer que les deux plans restent étroitement alignés et minimiser le temps passé en réunions, comme je l'explique plus en détail dans mon livre Strategize.

La feuille de route est hypothétique

Aussi utile que puisse être une feuille de route produit, il ne sert à rien de créer une planification hypothétique fondée sur des vœux pieux plutôt que sur des preuves empiriques. Cela se traduirait très probablement par une déception et un échec. Pour maximiser les chances de créer une feuille de route réaliste et exploitable, vous devez d'abord créer et valider une stratégie produit, comme le montre l'image ci-dessous. Cela implique d'aborder systématiquement les principales hypothèses et les risques contenus dans la stratégie et de collecter des données qui montrent que vous avez choisi le bon groupe cible, les bons besoins, les meilleures fonctionnalités et le bon objectif métier. En d'autres termes, ne créez pas de feuille de route produit si vous n'avez pas mis en place une stratégie produit validée.

Validated-ps-actionable-pr EN.png

En outre, ne vous projetez dans l'avenir que dans la mesure où vous pouvez le faire de manière réaliste. N'utilisez pas de feuille de route si vous ne pouvez pas voir au-delà du prochain objectif produit, ce qui peut arriver lorsque vous travaillez sur un tout nouveau produit innovant. Dans ce cas, n'utilisez que le seul objectif produit que vous avez identifié. En travaillant sur cet objectif, vous comprendrez mieux comment faire évoluer votre produit à l'avenir et serez en mesure de créer une feuille de route réaliste.

La feuille de route est trop ambitieuse

Il peut être tentant de créer une planification ambitieuse qui impressionne les parties prenantes et assure le soutien et le financement. Mais une feuille de route produit avec des objectifs irréalistes peut transformer l'effort de développement en une "descente aux enfers". Les membres de l'équipe de développement font régulièrement des heures supplémentaires, sont stressés en permanence et finissent par être épuisés.

Par conséquent, la créativité, la motivation et la productivité diminuent, et le bien-être et la santé des personnes en souffrent. En outre, les erreurs et les fautes sont plus nombreuses et la qualité logicielle est souvent compromise, ce qui rend la mise à jour du produit plus difficile et plus coûteuse à l'avenir. Vous devez donc faire de votre mieux pour vous assurer que votre feuille de route est réaliste et qu'elle soutient un rythme durable, c'est-à-dire que les membres de l'équipe peuvent la mettre en œuvre sans être surmenés, sans perdre leur motivation et sans tomber malade.

La meilleure façon d'élaborer une telle feuille de route est d'impliquer les membres de l'équipe de développement dans le travail d'élaboration de la feuille de route, de préférence sous la forme d'ateliers collaboratifs, comme indiqué ci-dessus. Écoutez leurs points de vue avec un esprit ouvert, et ne les poussez pas à accepter le contenu de la feuille de route. Au contraire, prenez leurs préoccupations au sérieux, itérez sur le planning et adaptez-le jusqu'à ce qu'il devienne réalisable.

La feuille de route est confondue avec un planning de versions

Certaines feuilles de route produits prévoient comment une version majeure ou une nouvelle version d'un produit est développée. Mais c'est une erreur à mon avis, car la feuille de route n'est pas le bon outil pour ce travail. La meilleure façon de gérer un effort de développement est d'établir un planning de version, par exemple, un release burndown chart.

Le burndown chart vous aide à suivre la progression d'un sprint à l'autre et vous permet d'anticiper si un objectif produit spécifique peut être atteint dans les délais et le budget - ou combien de temps cela prendra et combien cela coûtera. Cela vous aide à guider le travail de l'équipe de développement et à faire les ajustements nécessaires, par exemple en supprimant une fonctionnalité du backlog de produit. En d'autres termes, un planning de version vous aide à maximiser les chances d'atteindre un objectif spécifique du produit.

La feuille de route produit, en revanche, indique comment un produit est susceptible d'évoluer sur une période plus longue. Elle n'est pas basée sur le backlog produit mais sur la stratégie produit, et elle contient plusieurs objectifs produit. Par conséquent, ne confondez pas les deux planifications mais utilisez des artefacts distincts pour les représenter, comme je l'explique plus en détail dans mon article intitulé The Product Roadmap and the Release Plan.

Le meilleur outil de roadmap de produit est ce qui compte le plus

Une dernière erreur que je vois commettre par les responsables produits est de croire que le bon outil va résoudre leurs problèmes de feuille de route. Il y a quelque temps, je travaillais avec l'équipe de gestion des produits d'une grande maison d'édition. L'équipe ne disposait pas d'une approche efficace de roadmapping des produits. Mais au lieu d'acquérir les connaissances pertinentes et de découvrir les bonnes pratiques de roadmapping, l'équipe a essayé de raccourcir le processus en achetant une licence pour un puissant outil de roadmapping. Ne disposant pas de l'expertise nécessaire, elle n'a pas été en mesure d'adapter l'outil à ses besoins et n'a pas su en tirer parti. Comme l'a dit un jour Grady Booch : "Un idiot avec un outil est toujours un idiot".

Je vous recommande donc d'établir une approche de roadmapping produit qui fonctionne pour vous avant de décider quel outil de roadmapping spécialisé, s'il y en a un, vous convient. Pour commencer, choisissez un outil simple, facile à utiliser et qui permet aux parties prenantes et aux membres de l'équipe de développement de visualiser la planification et d'y contribuer. Il peut s'agir d'un document PDF, d'une feuille de calcul ou de l'outil de collaboration que vous utilisez dans votre entreprise.