Roadmaps Produits

De Wiki Agile
Aller à : navigation, rechercher

Auteur : Marty Cagan
Source : Product Roadmaps
Date : 07/01/2009


Traducteur : Fabrice Aimetti
Date : 21/11/2022


Traduction :

Je ne peux pas vous dire combien de fois les chefs de produit m'ont montré leurs feuilles de calcul et leurs algorithmes sophistiqués pour classer par ordre de priorité leur longue liste de demandes de fonctionnalités (en pondérant divers facteurs comme le coût, la complexité, le risque, l'impact sur le client, l'impact prévu sur les ventes, la documentation, les dépendances, etc.) pour finalement aboutir à une seule feuille de route globale et priorisée.

Je comprends d'où cela vient, et il y a de nombreuses années, je l'ai fait moi-même, mais j'essaie d'expliquer pourquoi c'est une erreur à plusieurs niveaux.

Premièrement et avant tout, votre travail n'est pas de prioriser et de documenter les demandes de fonctionnalités. Votre travail consiste à livrer un produit de valeur, utilisable et faisable. La feuille de calcul des demandes de fonctionnalités va à l'encontre de cet objectif en faisant passer des fonctionnalités que les utilisateurs ne valorisent pas ou dont ils n'ont pas besoin, en augmentant la complexité, en diminuant l'utisabilité et en gaspillant des cycles de développement. J'ai écrit plusieurs fois sur les dangers de confondre les exigences du client et les exigences du produit (voir l'erreur numéro 1 en matière de produit ici : www.svpg.com/papers/toppmmistakes.pdf, et les gars de 37signals ont publié un bon article sur le sujet il y a quelque temps : " Oubliez les demandes de fonctionnalités ".

Deuxièmement, cette approche va à l'encontre de la vision holistique de votre produit. Votre objectif est d'augmenter la conversion, ou d'aider les utilisateurs à faire leur travail, ou de permettre aux utilisateurs de trouver et de jouer leur musique, ou quoi que ce soit d'autre. Les demandes de fonctionnalités sont des théories spécifiques sur ce qui pourrait y contribuer, mais au stade de la feuille de route, vous n'avez pas la moindre idée de la pertinence des fonctionnalités décrites, ni de la possibilité de les concevoir de manière à ce qu'elles soient utiles et utilisables. Cela viendra lors de la découverte du produit. Verrouiller des fonctionnalités spécifiques au niveau de la feuille de route revient à sauter la partie la plus importante de votre travail, et la pierre angulaire des grands produits, à savoir la découverte du produit.

Troisièmement, comme je l'ai déjà dit à maintes reprises (voir www.svpg.com/great-products-by-design), tout tourne autour de l'expérience de l'utilisateur, et ceux d'entre vous qui travaillent avec de vrais designers d'interaction savent que pendant la découverte du produit, vous changerez très probablement d'idée sur ce qui est réellement "nécessaire". Une bonne conception et la découverte du produit de manière générale peuvent rapidement vous conduire dans des directions différentes lorsque vous réalisez que nombre de vos idées préconçues sur ce qui est nécessaire ne correspondent pas à l'utilisateur ou ne sont pas utilisables ou faisables.

De plus, l'obsession que nous avons, en tant que profession, pour les fonctionnalités fait plus de mal que de bien, et si nous voulons résoudre ce problème, nous devons le combattre à la source, ce qui est généralement le cas avec ces feuilles de route axées sur les demandes de fonctionnalités.

L'une des raisons de la confusion qui entoure ce sujet est qu'il existe différents types de "feuilles de route". Chaque produit a généralement une "feuille de route de produit", mais comme les différents produits de l'organisation sont généralement construits par une même organisation de développement, avec des dépendances entre les projets, cela crée le besoin d'une "feuille de route de portefeuille", qui est généralement à un niveau d'abstraction un peu plus élevé, autrement il y a trop de détails.

Pour rendre les choses encore plus confuses, l'organisation marketing produit souvent ses propres feuilles de route - des feuilles de route de produits ou de portefeuilles externes ou publiques. Il est à espérer qu'elles soient dérivées des feuilles de route de vos produits réels, sinon vous avez encore un autre type de (gros) problème, mais n'oubliez pas que ce sont essentiellement des outils de vente. Aujourd'hui, heureusement, beaucoup moins d'entreprises produisent ces feuilles de route publiques, et vous devriez faire tout ce que vous pouvez pour les éviter si possible, mais elles sont parfois nécessaires. En effet, les gros clients, la presse et les analystes du secteur veulent souvent savoir ce que l'avenir leur réserve. La clé ici est de maintenir les feuilles de route publiques à un niveau d'abstraction très élevé, et avec des dates très approximatives. Je préfère fournir des versions publiques de la stratégie produit. Partagez la vision si vous le devez, mais donnez-vous la plus grande marge de manœuvre possible quant à la manière dont cette vision sera réalisée.

Ceci dit, les feuilles de route produits sont l'un de mes outils préférés. Lorsqu'elles sont bien faites, elles sont incroyablement utiles au chef produit, au management, au marketing et surtout aux ingénieurs.

La feuille de route du produit doit décrire le chemin à parcourir depuis votre situation actuelle jusqu'à la réalisation de la vision que vous avez définie dans votre stratégie produit. Vous avez une stratégie produit, n'est-ce pas ? Si ce n'est pas le cas, votre feuille de route produit n'a pas de véritable fondement, ce qui constitue un sérieux problème (voir svpg.com/product-strategy-in-an-agile-world).

Les feuilles de route des produits doivent être très simples et de très haut niveau. Elles doivent refléter vos réflexions actuelles sur les objectifs les plus importants. S'agit-il de rendre le produit international ? De prendre en charge les appareils mobiles ? De prendre en compte des personas supplémentaires ? De résoudre les principaux problèmes d'utilisabilité ? La feuille de route n'a pas vocation à être une spécification, ni une liste exhaustive de fonctionnalités.

N'oubliez pas non plus que si vous indiquez habituellement des dates cibles sur une feuille de route ("au premier trimestre, nous voulons lancer le produit au Royaume-Uni"), ces dates ne sont en fait que des espoirs et des souhaits. Ce n'est que lorsque vous définissez le produit dans le cadre de la découverte produit, que vous travaillez avec l'ingénierie sur les coûts réels en termes de temps, et que la gestion de projet/PMO planifie réellement le travail, que vous avez des dates réelles auxquelles vous pouvez croire.

Aujourd'hui, les feuilles de route des produits sont presque toujours stockées sur un Wiki afin que l'équipe projet puisse les trouver facilement et prendre connaissance de vos dernières réflexions et raisonnements.

Pour les équipes Agile, tous ces problèmes peuvent encore exister, mais il y a une autre catégorie de problèmes dont je parlerai dans un prochain article.

Il s'agit d'un vaste sujet et il existe plusieurs techniques utiles et éprouvées pour s'assurer que vous choisissez les bonnes priorités et que vous communiquez votre planification à l'organisation. J'aborderai ces sujets plus en détail dans de futurs articles, mais si vous faites partie de ces chefs produits qui passent leur journée à passer au crible les demandes de fonctionnalités, à les classer par ordre de priorité et à les documenter, j'espère que cette note vous incitera à prendre du recul et à vous demander si ce n'est pas une raison pour laquelle votre produit ne progresse pas vraiment.