Florence Arnal (ISEP 1992)

Cloud Marketplace and Cybersecurity Product Manager chez WALLIX group

Voila quelques années, j’avais écrit cet article. Au fil des meetups auxquels j’ai pu assister ces dernières semaines, je me rends compte que cet article reste totalement d’actualité. D’ou cette réédition.

Tout commentaire est le bienvenu. Si l’article vous a plu, n’hésitez pas à le partager et/ou me contacter.
Lire l’article en ligne

*-*-*-*-*-*-*-*-*-*-*-*-*-*

Si vous êtes en train de construire un nouveau produit, vous devez savoir dire non, pas “peut être” ou “plus tard”, le seul mot est “non”. Cela semble brutal mais construire un bon produit ne consiste pas en une accumulation de fonctionnalités vaguement utiles ou indirectement liées. Il s’agit de définir un produit cohérent en suivant un cap fixe et des lignes directrices fortes.

Ps: 1/ Naturellement, dire “non” doit se justifier. 2/ On a aussi le droit de dire “oui” de temps en temps 🙂

Pourtant, il y a tant de bonnes raisons de dire oui à une demande, alors que vous sentez au fond de vous qu’il vous faudrait dire non… Par exemple, lorsque votre produit se fait connaitre, vous allez être submergé par de nouvelles idées de vos clients, prospects ou collègues. Parce que ce sont de bonnes idées dans l’absolu, vous allez surement être tenté de dire oui.

Pour apprendre à résister, il faut savoir reconnaître les arguments couramment utilisés comme justificatif. En voici une petite dizaine…

Les données clients semblent bonnes

“Nous avons essayé cette fonction avec un petit groupe et les retours dépassent nos espérances“. Souvent cette approche souffre d’une analyse sélective des données. Les produits sont des systèmes complexes. Ce qui semble être une augmentation de l’engagement des clients pourrait se retourner contre vous. Vous devez vous demander si la demande est en ligne avec votre vision du produit et de son dessein.

Ca ne prendra que quelques minutes à développer

Tout d’abord, la charge de travail ne doit jamais être une raison d’inclure une nouvelle fonctionnalité dans un produit. Si l’idée mérite d’apparaître dans la Roadmap, elle doit l’être indépendamment de la charge de travail. De plus, ne vous laissez pas piéger : il n’y a pas de petits changements. Toutes les modifications ont un coût et certaines (parfois même les plus petites d’entre elles) peuvent ajouter une complexité cachée non anticipée dans l’estimation initiale des “quelques minutes”.

Le client est près de nous lâcher

Ceci semble avoir toutes les caractéristiques du chantage, non ? Seuls quelques clients très importants peuvent avoir autant de poids qu’un bon produit. Avant de céder à cet argument, assurez vous que la menace est réelle et sérieuse et que votre client est prêt à s’engager avec vous sur l’achat du produit qu’il demande ou sur le financement d’une partie au moins de ses développements spécifiques s’ils sont en dehors de votre roadmap. Sinon, faite tout pour éviter de créer de la valeur supplémentaire pour un seul client au détriment de tous les autres.

Nous pouvons simplement rendre la fonctionnalité optionnelle

Cet argument traduit souvent le manque de confiance du demandeur dans la pertinence de sa fonctionnalité. Généraliser cette approche conduit à la fragilisation de votre produit par la multitude des préférences et options. Abuser des fonctions optionnelles conduit de plus à une sur-complexité de l’interface utilisateur et à des surcoûts de conception et de cas de tests pour assurer toutes les combinatoires. Avec en coût caché, une augmentation de la complexité de votre produit, qu’il faudra gérer dans le long terme.

On m’a dit que…

Ceci est monnaie courante dans les sociétés qui ne peuvent décider un cap à leur produit. Dériver des conclusions à partir d’un petit échantillon de données ou d’opinions est un moyen facile de contourner une analyse réelle (ou de s’autoriser à ne pas en faire) par une déclaration qui semble raisonnable. Dire “la compagnie Untel utilise la fonctionnalité ABC du produit XYZ” est une façon de pousser la demande en contournant les questions telles que: Que sait faire notre produit ? La compagnie Untel est-elle une bonne cible client ? Utilisent-ils vraiment la fonction ? Est-ce la bonne réponse aux demandes de nos clients ? Est-ce en phase avec la vision / le cap du produit ?

Cela pourrait être la fonction

Ceci est un “appel à l’inconnu” classique. Faire évoluer un produit nécessite des prises de décisions difficiles. Ne tombez pas dans la spéculation. Lorsque vous avez peur de prendre des décisions difficiles basées sur des informations structurées, vous retombez sur l’appel à l’inconnu et donc le développement de tout et n’importe quoi. Vous vous retrouvez avec une accumulation de fonctionnalités, pas un produit.

Et quand vous deciderez d’une modification plus importante de votre produit (par exemple, une cure de jeunesse technologique, un passage en offre cloud, un changement de business model), vous vous retrouverez “coincé” avec une tonne de petites features dont vous aurez oublié le pourquoi.

Nous n’avons rien d’autre de prévu

Le problème se pose quand un manager voit un ou plusieurs développeurs semblant en sous-charge de travail et se précipite au travers une nouvelle fonctionnalité à les “garder occupés”. Ces décisions sont précipitées pour éviter les temps morts et naturellement une mauvaise façon d’améliorer un produit. Les temps d’inactivité peuvent être mis à profit pour fixer les problèmes ou corriger de la documentation plutôt que de pervertir une vision produit seulement pour garder une équipe en production.

Nos concurrents l’ont déjà

Cela ne veut pas toujours dire que c’est une bonne idée pour votre entreprise. Cette fonction marche-t-elle si bien, permet-elle de vendre plus ? Et si vos concurrents étaient en train de la sortir de leur offre ou la considéraient comme un simple essai. Ne vous sous-estimez pas. Il est faux de croire que vos concurrents sont plus intelligents ou plus stratèges que vous. Etre obsédé par les concurrents vous relègue à livrer la technologie d’hier… demain.

Le patron la veut vraiment

Un des arguments les plus difficiles à repousser lorsque vous êtes persuadé que c’est une mauvaise idée… Essayez d’engager l’argumentation avec votre patron mais à vous de savoir évaluer le risque que vous prenez en allant à l’encontre d’une décision qui vous dépasse sur le plan hiérarchique. Certains le feront, d’autre pas. C’est vous qui voyez… mais le mieux est peut-être de choisir un boss sait tenir un cap et qui comprend le Product Management, non ?

Sources of inspiration: Steven Haines (Sequent Learning Networks) et Des Traynor (Intercom)