Voir la source de La stratégie produit implique de dire non

[[Category: Rôle du Product Manager]]
[[Category: Portail Planification]]
[[Category: Portail Product Owner]]
Auteur : Des Traynor<br />
Source : [https://www.intercom.com/blog/product-strategy-means-saying-no/ Product strategy means saying no]<br />
----
Traducteur : Fabrice Aimetti<br />
Date : 26/11/2022<br />
----
Traduction :<br />
<br/>
[[Fichier:Product Strategy Means Saying No Related V2.png|border|center|1000px|link=]]

  Si vous créez un produit, vous devez être capable de dire non. Pas "peut-être" ou "plus tard". Le seul mot est non.

Construire un produit de qualité ne consiste pas à créer des tonnes de fonctionnalités utiles d'un point de vue pratique et ayant peu de rapport entre elles. Il s'agit de fournir un produit cohérent avec des caractéristiques bien définies.

[[Fichier:Apple-No.png|border|center|link=]]

Comme le souligne la dernière publicité d'Apple, il existe littéralement des dizaines de milliers de variantes pour votre produit, en fonction de chaque ajout, mineur ou majeur. La plupart de ces variantes feront un flop. Seules quelques unes serviront correctement le marché.

==Tant de raisons de dire oui==
Lorsque votre produit gagne en popularité (''traction''), vous serez inondé de bonnes idées de fonctionnalités. Elles viendront de vos clients, de vos collègues et de vous-même. Parce que ce sont de bonnes idées, il y aura toujours de nombreuses raisons de les accepter. Voici 12 arguments dans le style de [http://www.don-lindsay-archive.org/skeptic/arguments.html Don Lindsay] qui sont souvent utilisés pour introduire en douce des fonctionnalités dans un produit :

===Mais les données semblent bonnes !===
[[Fichier:Engagement-data.png|border|center|link=]]
''"Nous avons testé cette fonctionnalité avec un petit groupe et l'engagement est exceptionnel."'' Cette approche souffre souvent d'une interprétation trop partielle des données. Les produits sont des systèmes complexes. Ce qui semble être une hausse de l'engagement n'est en fait qu'un simple déplacement de chiffres d'un endroit à l'autre. Même si les données sont fiables et que l'augmentation de l'engagement est bonne, vous devez vous demander si cela correspond à l'objectif du produit. Ajoutez Tetris à votre produit et vous verrez probablement une augmentation de l'engagement, mais cela signifie-t-il que votre produit est meilleur ?

===Mais cela ne prendra que quelques minutes !===
[[Fichier:Iceberg-cost.png|border|center|link=]]
Le principal problème avec cet argument est que la charge de travail ne devrait jamais être une raison d'inclure une fonctionnalité dans un produit. C'est peut-être une raison pour la mettre en avant sur la feuille de route, mais c'est une décision qui relève de la feuille de route, pas du produit.

Beaucoup de mauvaises idées peuvent être construites rapidement. Ne vous laissez pas séduire. [https://www.intercom.com/blog/there-are-no-small-changes/ Il n'y a pas de petits changements]. En outre, même les plus petits ajouts ajoutent une complexité cachée qui n'est pas prise en compte dans l'estimation [http://firstround.com/article/The-one-cost-engineers-and-product-managers-dont-consider "mais ce ne prendra que 5 minutes"].

===Mais ce client est prêt à nous quitter===
[[Fichier:Tweet-promises.jpeg|border|center|link=]]
C'est du chantage à la fonctionnalité. Aucun client ne peut être plus important qu'un bon produit. La route vers le produit est balisée ''juste cette fois-ci pour ce seul client''. Elle mène au produit parfait, pour ce seul client, à condition que vous continuiez à faire ce qu'il dit. Offrir une valeur ajoutée à un seul client revient à enlever de la valeur à de nombreux autres.

===Mais on peut le rendre facultatif !===
[[Fichier:Preferences-optional.png|border|center|link=]]
Cela entraîne la mort par les préférences. Le fait de rendre les fonctionnalités facultatives masque la complexité des écrans par défaut de l'interface, mais elle refait surface partout ailleurs. Le coût visible de cette pratique est une interface compliquée avec beaucoup de conditions pour la conception et une multitude de configurations. Le coût caché est que chaque fonctionnalité optionnelle affaiblit la structure de votre produit. Vous devenez "un outil de suivi du temps qui peut aussi envoyer des factures et, dans une certaine mesure, faire du recouvrement des paiements, mais pas du reporting, pas encore, je crois, mais bon, je ne sais pas".

===Mais le voisin de mon cousin a dit...===
[[Fichier:Appeal-to-the-anecdote.png|border|center|link=]]
C'est l'"appel à l'anecdote". Il est omniprésent dans les produits de consommation, ou dans une entreprise SaaS qui n'arrive pas à décider des missions précises qu'elle exerce. Extrapoler à partir d'un petit échantillon est un moyen facile de contourner des années d'expérience, de recherche, de données et de comportement pour aboutir à une affirmation qui semble raisonnable. Dire "l'entreprise de mon frère utilise Google Analytics, ils utilisent tous des segments avancés" est un moyen facile d'argumenter en faveur des segments avancés, en contournant la question de savoir ce que votre produit fait réellement, si l'entreprise de votre frère est vraiment un bon client cible, s'ils l'utilisent réellement ou s'ils disent simplement qu'ils le font, et si les segments avancés sont réellement la bonne solution pour ce que vos clients essaient de faire.

===Mais nous n'avons rien d'autre de prévu !===
[[Fichier:Free-nothing-else-to-do.png|border|center|link=]]
L'oisiveté est mère de tous les vices. Le problème ici est que quelqu'un voit un ou plusieurs ingénieurs inoccupés et se précipite immédiatement sur une nouvelle fonctionnalité pour les "occuper". Les décisions sont prises à la hâte et les conceptions sont improvisées, tout cela dans le but d'éviter les temps morts. C'est une mauvaise façon d'"améliorer" un produit.

Au lieu de rajouter de la dette technique ici, il y a une opportunité d'en rembourser une partie. Comme le savent tous ceux qui ont travaillé dans une cuisine : "si vous avez le temps de vous pencher, vous avez le temps de nettoyer". Il est préférable d'utiliser le temps libre pour corriger les bogues, nettoyer les jeux de tests, refactorer, etc. plutôt que de faire dérailler une vision produit juste pour "maintenir la productivité de l'équipe".

===Mais nous sommes censés avoir le droit de travailler sur ce que nous voulons !===
[[Fichier:Culture-pride.png|border|center|link=]]
Cet argument renvoie à la fierté culturelle. De nombreuses grandes entreprises promettent aux ingénieurs qu'ils peuvent construire ce qu'ils veulent et le livrer. [https://www.intercom.com/blog/you-cant-fake-culture/ Cette promesse a généralement deux conséquences] :
* C'est un mensonge raconté pour attirer les ingénieurs. Cela se remarque rapidement et tombe à l'eau. On ne peut pas truquer la culture.
* C'est vrai, et le résultat final est un produit à taille unique plein d'idées à moitié réalisées.
Il y a une différence entre encourager les ingénieurs à construire des choses en interne (une bonne chose) et laisser les gens ajouter des fonctionnalités à un produit sans passer par le product management (une mauvaise chose).

===Mais 713 000 personnes le veulent !===
[[Fichier:Faces-people.png|border|center|link=]]
Il faut toujours se méfier lorsque quelqu'un se sert de chiffres bruts pour justifier quelque chose. N'importe quel produit ayant un certain degré d'attraction peut faire croire à une émotion en utilisant des chiffres. Par exemple : "Vous pourriez entièrement remplir Dolores Park avec les personnes qui ont demandé l'intégration d'Excel". Une telle affirmation vous oblige à retirer votre chapeau de concepteur de produits et à faire partie des "gens". Allez-vous vraiment dire non à tous ces visages ?

Vous devez le faire. Parce que la majorité de vos utilisateurs en souffriront sinon. La question n'est pas "pourrions-nous entièrement remplir le parc Dolores avec [https://www.intercom.com/blog/making-things-people-want/ des gens qui veulent] cette fonctionnalité ?", mais "est-ce une fonctionnalité importante, dans notre domaine, que tous nos clients utiliseront ?".

===Mais nos concurrents l'ont déjà !===
[[Fichier:Menu-too-much-stuff.png|border|center|link=]]
Ça ne veut pas dire que c'est une bonne idée. Ça pourrait être quelque chose qu'ils expérimentent. Ça pourrait être une idée pourrie. Ça pourrait être quelque chose qu'ils ont l'intention de supprimer. C'est une erreur de supposer que vos concurrents sont de quelque manière que ce soit plus intelligents ou plus tactiques que vous. Être obsédé par les fonctionnalités de vos concurrents vous condamne à fournir en permanence la technologie d'hier pour demain.

===Mais si nous ne le construisons pas, quelqu'un d'autre le fera !===
[[Fichier:ProductScope-cinema-restaurant.png|border|center|link=]]
Cela ne signifie pas pour autant que cela doit faire partie de votre produit. Si quelqu'un d'autre le construit, les clients n'ont-ils plus besoin de votre produit ? Vont-ils tous le remplacer ? Dire simplement "quelqu'un d'autre le fera" résonne bien, mais ne signifie rien. Je me suis surpris à le dire souvent. C'est souvent la logique utilisée pour développer un produit parce que vous ne voulez pas admettre que votre produit a une limite. Vous avez peur de [https://www.intercom.com/blog/where-to-draw-the-line/ tracer la ligne].

Voici un exemple : un rendez-vous classique pourrait inclure un film, un dîner et le retour au domicile. Si le propriétaire d'un cinéma s'inquiète constamment de ce que d'autres entreprises vont construire, et s'il a envie de capter plus de valeur, il installera un restaurant dans son cinéma et créera une compagnie de taxis. Alors il sera nul dans les 3 domaines. Puis les restaurants commenceront à projeter des films...

===Mais le grand patron le veut vraiment !===
[[Fichier:Dilbert-fucking-right.png|border|center|link=]]
Si le grand patron est également le chef produit, et qu'il dispose du temps et des connaissances nécessaires pour prendre des décisions stratégiques intelligentes, tout va bien. Cependant, si quelqu'un essaie de gagner ses galons en se concentrant sur des projets favoris pour lesquels son manager a un penchant, c'est une source de problèmes.

===Mais ça pourrait être "le bon" !===
[[Fichier:TheOne-tags.png|border|center|link=]]
C'est un classique "Appel à l'inconnu". [http://andrewchen.co/2012/08/10/why-companies-should-have-product-editors-not-product-managers/ Éditer un produit] nécessite des décisions difficiles sur ce qu'il faut construire. Vous pouvez supposer que toute fonctionnalité non développée pourrait transformer votre produit. Mais les suppositions sont tout ce qu'elles sont et rien de plus. Lorsque vous avez peur de prendre des décisions difficiles, vous vous rabattez sur l'inconnu, et donc vous construisez tout. Vous vous retrouvez avec un référentiel de fonctionnalités, pas un produit.

==Pourquoi le "non" est-il important ?==
En fait, personne ne garde les mauvaises idées dans sa feuille de route. Identifier et éliminer les mauvaises idées est la partie facile. Les vraies décisions concernant les produits ne sont pas faciles. Elles exigent que vous regardiez une proposition et que vous vous disiez "C'est une idée vraiment géniale, je vois pourquoi nos clients l'aimeraient. C'est très bien. '''Mais nous n'allons pas la réaliser.''' À la place, voici ce que nous allons faire".