Résumé : si les éditeurs de logiciels consacrent des ressources au Product Management, c’est parce qu’ils ont besoin d’ordonnancer, de rationaliser, d’optimiser leur contenu produit. Cependant, il est vrai que ces objectifs peuvent parfois être difficiles à atteindre faute de méthodes claires et efficaces. Nous proposons ici quelques pistes pour aider à structurer cette activité clé.

Le Product Management en quelques mots

Faire le lien entre les besoins auxquels doit répondre son produit, ses capacités de développement, la faisabilité et le coût de développement, …, sérier le développement de nouvelles fonctionnalités de façon à satisfaire ses clients tout en permettant de conquérir de nouveaux marchés, …, rester concurrentiel et innover, …, tout éditeur se pose la question de savoir comment gérer le contenu fonctionnel de son produit, comment optimiser l’utilité du développement en fonction de tous ces paramètres, en conciliant long terme et court terme…. C’est tout l’objet de l’activité de Product Management.

Au carrefour entre la stratégie, le marketing, les retours des clients, les retours des commerciaux, et les contraintes et possibilités de la R&D, le Product Management s’occupe de définir ce qui doit être développé et intégré afin de faire évoluer harmonieusement le produit en fonction de toutes ces données.

Mais autant l’objectif parait évident, autant la façon de l’atteindre est souvent compliquée à appréhender. Nous allons voir dans la suite de cet article quelques pistes pour y parvenir.

La hiérarchie des échelles

De la vision à l’opérationnel, gérer le contenu de l’activité de développement produit est une nécessité. Mais il est difficile de traiter de la même façon une demande d’amélioration, un bug, une demande pour un nouveau module, ou un chantier de réduction de la dette technique !

L’agilité érigée en panacée promet souvent de résoudre cette difficulté. Mais il y a loin de la théorie à la réalité, et trop souvent, lors d’audits, nous constatons que les méthodes agiles gèrent mécaniquement tout cela plus ou moins, sans que la direction de l’éditeur n’ait réellement la main, ce qui peut mener, à terme, à une défaillance stratégique. Face à ce piège, nous proposons de bien identifier les différents niveaux de la planification produit et d’apporter des réponses différentes à chaque niveau.

On peut schématiquement distinguer les niveaux suivants qui correspondent à des échelles de temps différentes : vision (≈5-8 ans), stratégie (≈2 ans), macro-itérations (≈3-4 mois), sprint (2-3 semaines).

Le niveau de la vision

On entend par vision, l’expression à partir d’une anticipation à moyen-long-terme du marché et des offres, d’une ambition de position de l’éditeur. Il est souhaitable de la documenter. Et de la mettre à jour régulièrement (tous les ans, par exemple).

Le niveau stratégique

Pour atteindre l’objectif de long terme décrit par la vision, il faut choisir un chemin, des étapes. On ne peut pas partir dans trop de directions simultanément, il convient donc de dessiner un chemin qui, progressivement, conduise vers la vision. C’est ce qu’on appelle stratégie, qui est donc une façon de converger vers la vision en plusieurs étapes ou positions.

Par exemple, une stratégie en 4 étapes pour un éditeur désirant migrer son offre « On-Premise » vers le « Cloud » et confronté à une extension rapide de son marché vers les très petits clients, captés par des offres « cloud » concurrentes, pourrait être :

1. Préserver l’avance sur le marché historique et développer une offre complémentaire sur le cloud pour les très petits clients afin d’y prendre vite une part de marché conséquente.
2. Migrer progressivement le fonctionnel concernant les petits et moyens clients vers le produit cloud et commencer à inciter les petits clients à migrer.
3. Migrer progressivement le fonctionnel concernant les gros clients vers le produit cloud et inciter les petits et moyens clients à migrer.
4. Abandonner le produit historique « On-Premise » en proposant un accompagnement commercial et technique aux gros clients.

Il y a lieu de mettre en place un niveau de Product Management, qu’on dira « stratégique », correspondant à ce niveau de visibilité.

A ce niveau, les fonctionnalités sont vues de très haut, sans détails. Elles correspondent à de vrais enjeux de marché. Elles sont découpées en phases (en essayant de constituer, pour chaque phase, un contenu fonctionnel cohérent capable de créer de la valeur chez les clients). Chaque bloc fonctionnel ainsi obtenu est pesé grossièrement en termes d’efforts R&D de sorte que la roadmap stratégique sur laquelle ils sont positionnés, soit compatible avec les ressources planifiées.

Pour résumer, on maintient donc à ce niveau une roadmap stratégique de haut niveau et un plan prévisionnel de ressources. Bien entendu, cela doit être révisé régulièrement, au minimum une fois par an.

Le niveau opérationnel

Au niveau opérationnel, on se concentre sur une vision à 18 mois environ (pouvant varier en fonction de la société et de son marché). On parle ici de versions et le contenu fonctionnel est un peu détaillé, tout en restant appréhendable facilement.

L’idéal est d’identifier une dizaine de thèmes dans lesquels on va affecter les besoins identifiés et de composer des fonctionnalités qui répondent à ces besoins.

Le résultat de cette activité doit être une roadmap à 18 mois (+ ou -) avec, sur cette roadmap, les besoins satisfaits par thème. J’insiste ici sur le fait que la roadmap doit contenir non pas des fonctionnalités (features) mais des besoins à satisfaire, ce qui la rend opérationnelle pour le marketing et la vente.

Le cadencement sur cette roadmap est fait de versions successives, se succédant tous les 3 ou 4 mois environ (selon le contexte, cela peut être un peu différent). On entend ici par « version » un état stable et cohérent du produit qui peut être identifié d’un point de vue marketing, et donc promu et vendu.

Chaque version est ensuite développée comme un « nouveau » produit, découpée en sprints et gérée de façon agile.

Afin de planifier des versions faisables, le Product Manager doit demander au responsable du développement correspondant de procéder à des macro-chiffrages estimatifs des blocs à planifier et de vérifier avec lui la cohérence de la roadmap avec les ressources, quitte à revoir le contenu de la roadmap en fonction.

Structurer en thèmes

Que ce soit au niveau stratégique comme au niveau opérationnel, nous avons vu que l’identification de thèmes est très importante afin de réduire le nombre d’objets sur lesquels réfléchir en termes de planification (l’esprit humain est ainsi fait qu’il gère mieux un tableau de 10 lignes que de 100).

Mais également, en reliant ces thèmes à des besoins, cela permet d’éviter de considérer le produit en tant qu’ensemble de fonctionnalités (features en Anglais), comme le but ultime du développement. A contrario, cette structuration permet de rester concentré dans sa réflexion sur les besoins. Combien d’éditeurs ai-je audités qui, imaginant leur produit directement sans passer par cette structuration des besoins, découvraient au moment de la vente seulement que les fonctionnalités développées étaient incomplètes et n’apportaient finalement rien aux clients !

Redisons-le, on ne se le répète jamais assez, c’est la satisfaction de vrais besoins qui est l’objectif du développement Produit !

Besoin et Valeur

Les besoins doivent être analysés en termes de bénéfices, suivant qu’ils profitent au client acheteur (par exemple, le bénéfice d’un outil à destination d’opérateurs peut être de faire des économies dans la gestion des stocks), au client utilisateur, au vendeur, ou autre…

Pour faire simple et rapide, je recommande que l’identification des besoins réponde à un certain nombre de questions, inspirées de la célèbre méthode des 6 Ws : pour quel marché, pour quels acteurs du marché, pour quels types d’opérations, qui utilisent quoi sinon, pour quels bénéfices, en concurrence avec qui …

Derrière cette notion de bénéfices on trouve celle de valeur. On doit s’intéresser à la valeur que représente la satisfaction d’un besoin. Car il n’est pas égal de satisfaire un besoin critique et un besoin accessoire ! Et même si on ne doit pas s’interdire de faire plaisir aux utilisateurs (cf. paragraphe suivant), l’essentiel de l’investissement R&D doit être consacré à ce qui va créer de la valeur pour les clients, et ainsi, indirectement, donner de la valeur au produit que l’on vend.

Dans le domaine de la vente de logiciels d’entreprise, les méthodologies de vente basées sur la valeur (« value selling », ou « value-based selling » en anglais) sont très utilisées. Ces méthodologies permettent aux commerciaux de se focaliser sur les besoins des clients, et en particulier sur ceux de plus grande importance (ou valeur) sur lesquels le produit peut apporter le plus. Cette valeur peut se mesurer, par exemple, par du retour sur investissement (ROI en anglais). On trouvera par exemple ici quelques éléments d’argumentation en faveur de ces méthodes.

Besoin et Valeur sont des concepts communs à la direction, à la vente, au marketing et au produit. Ce sont, à mon avis, d’excellents juges de paix pour aligner les différents acteurs de l’entreprise éditrice de logiciels !

Budgéter

Avant de conclure, je voudrais évoquer une méthode qui est très adaptée à la gestion du contenu produit, en complément de ce dont nous avons déjà parlé plus haut : la budgétisation de l’effort à consacrer aux différents types de besoins.

En effet, comme nous l’avons vu plus haut, si un Product Manager doit arbitrer entre une fonctionnalité permettant de satisfaire un besoin critique et des petites features rendant plus facile l’utilisation du produit, ce devrait être toujours la première qui l’emporte. Or un produit ne peut pas ignorer les demandes non stratégiques, mais en satisfaire également quelques-unes, régulièrement, au fil des versions.

C’est pourquoi, je trouve sain de budgéter l’effort R&D en % de l’activité, et de suivre cette distribution du temps passé. On peut par exemple décider de consacrer 15% de son activité à la correction de bugs, 10% à l’ergonomie et l’amélioration de l’utilisabilité, 15% à la dette technique, 10% à la veille technologique et la formation, et 50% au développement stratégique du produit.

Ceci implique donc qu’un Product Manager doive également décomposer les objectifs d’une version en catégories : par exemple développement stratégique, quick win features, features pour aider à la vente, …. En s’assurant auprès du ou des responsables du développement que les estimations de charge respectives respectent les pourcentages définis.

Conclusion

Nous espérons vous avoir donné, à travers ce rapide panorama de méthodes de product management, des idées, des pistes pour gérer au mieux cette activité.

Nous pensons également que tout éditeur peut trouver bénéfice à se faire accompagner sur ce sujet, et c’est l’un des volets plébiscités de notre offre dédiée CTO#.