Victor Dulieu, Head of Product, s’interroge dans cette tribune sur les pratiques Produit en France. Les entreprises et les Product Managers appliquent-ils réellement les standards de la discipline ? L’auteur en doute et partage, entre autres, les dérives qu’il a pu observer.
Avez-vous déjà entendu dire, au détour d’une conversation : “Avant, tout le monde nous bassinait avec l’Agile. Maintenant, on entend tout le temps parler de Product Management… J’ai l’impression que c’est la nouvelle lubie !”
Je suis assez aligné avec ce constat. Les organisations Produit ont toujours aimé surfer sur des tendances pour se convaincre qu’elles sont dans l’air du temps. Cela a un effet pervers que l’on avait vu naître avec l’Agile Trap : les pratiques et méthodes, voire les valeurs véhiculées par ces approches sont détournées. Très vite, elles sont associées à des poncifs qui les vident de leur substance et les décrédibilisent.
Les entreprises françaises qui se targuent de faire du Product Management en font-elles vraiment ? Tous les Products Managers respectent-ils la discipline ? Pourquoi certains sont-ils, sans le vouloir, tombés dans ce que l’on pourra alors appeler un “Product Trap” ?
J’aimerais vous partager ma vision de ce qui freine les organisations à réellement faire du Product Management, c'est-à-dire répondre aux besoins des clients/utilisateurs par des solutions apportant de la valeur et des revenus à l’entreprise..
Toute ressemblance avec votre quotidien est fortuite
Avant d’entrer dans les détails, rappelons que faire du Product Management repose sur trois familles d’activités clés :
- La Product discovery pour déterminer en premier lieu quels problèmes et besoins sont importants pour les clients/utilisateurs.Des solutions adaptées et vecteurs de valeur sont ensuite proposées.
- Le Product delivery pour réaliser ces solutions en cohérence avec les compétences techniques et les cycles de développement de l’entreprise. C’est la casquette Product Owner (PO) du Product Manager (PM).
- Le Product growth pour mesurer que l’usage de la solution est en adéquation avec les hypothèses posées en discovery. Le travail du PM ne s’arrête pas quand une fonctionnalité est livrée mais lorsqu’elle remplit sa mission chez le client/l’utilisateur et donc participe au revenu de l’entreprise.
Vous pensez peut-être que ce résumé est grossier ? Vous n’avez pas tort ! Je suis allé volontairement à l’essentiel car cela permet déjà de dire que si des équipes n’interviennent pas sur ces trois axes, alors elles ne font tout simplement pas de Product Management.
Je pense notamment au troisième axe qui est souvent le parent pauvre des PMs en France, Il n’y a que dans mes expériences dans le e-commerce, chez ManoMano ou encore 24S par exemple, que j’ai vraiment été challengé sur l’usage de mes produits par mes parties prenantes, du fait de leur impact direct sur le CA par exemple. C’est dommage car je peux vous garantir que démontrer le gain business - voire financier - vous attirera les bonnes grâces de vos dirigeants.
Maintenant que l’on a dit tout cela, quels éléments peuvent confirmer que vos pratiques doivent évoluer pour apporter de la valeur et donc réellement faire du Product Management ?
Être obsédé par les outputs et non pas les outcomes
On retrouve beaucoup d’éléments sur le sujet dans la littérature. C’est ce que Mélissa Perri théorise dans son livre Escaping the Build Trap: How Effective Product Management Creates Real Value avec la notion de Build Trap, parfois on parle de feature factory ou usine à fonctionnalités.
Pour y remédier, je vous conseille de vérifier que chaque sujet de votre roadmap est lié a mimina à un enjeu qu’un client exprime ou un enjeu business chiffré. N’oubliez jamais que c’est votre rôle de savoir expliquer “pourquoi”. Je me souviens de cette confidence de Alessandro Costa, CPTO de Eldo : “Si tes PMs te disent que les fonctionnalités sont dans la roadmap parce qu’on leur a demandé, alors tu as un problème…”
Détourner des méthodes en les appliquant mal
Pour aller un cran plus loin, dans beaucoup d'organisations les équipes ont le sentiment de faire du Produit uniquement en appliquant des frameworks.
Un exemple criant de cette dérive est l'utilisation des OKR comme un prétexte pour ne pas remettre en question certains choix. Fabrice des Mazery - qu’on ne présente plus - appelle ça “la gabegie des OKR”. Voici ce qu’il me confie : “Certains pensent que les OKR sont une sorte de remède magique pour tout ce qui concerne le Product Management. Ils se trompent ! C'est souvent du top-down déguisé ! On nous dit quoi faire, et on doit ensuite aligner nos OKR en conséquence. Et puis, il y a ce problème récurrent où les objectifs sont ultra-segmentés entre les équipes Tech et Produit. Franchement, ça n'a aucun sens si on veut vraiment responsabiliser le trio (Design ; Produit ; Dev). Trop souvent, c'est un prétexte pour se dédouaner. Les gens se disent : 'Ce sujet est dans mes OKR, donc c'est ma priorité.'.”
Ce que décrit Fabrice des Mazery participe parfaitement à ce Product Trap : des pratiques Produit mal utilisées, donc vidées de leur substance. Tout cela participe à décrédibiliser nos métiers.
Prioriser uniquement sur des critères subjectifs
Je l’ai vu dans quasiment toutes les organisations où je suis passé et cela se manifeste de plusieurs manières.
Parfois à partir d’une bonne intention :
- Exprimer un souhait client mais qui n’a pas forcément été mis en perspectives, ou qui n’est pas en accord avec la vision de l’entreprise.
- Suivre les tendances du marché. Je suis convaincu que vous avez déjà été confronté à des sujets simplement parce qu'ils étaient en vogue, comme lors de votre dernière conversation à propos de l'utilisation de ChatGPT. Dans ces situations, le mieux reste toujours de demander “pourquoi”.
Parfois pour des raisons moins louables :
- Chercher à imposer les choses pour confirmer son pouvoir sur les autres. Si vous ne voyez pas de quoi je parle, renseignez-vous sur l’effet HIPPO (Highest Paid Person's Opinion, Highest Paid Person in the Office).
- Faire (uniquement) preuve de convictions. Vous avez déjà entendu cette phrase : “On sait mieux que nos clients ce dont ils ont besoin” ; à mon sens, il est toujours bon de vérifier et comprendre les clients avant d'affirmer quoi que ce soit.
Le mieux dans ces situations est de documenter un maximum les choix avec, par exemple, des verbatims clients, des analyses et benchmarks de la concurrence ou des résultats de tests. Les équipes Sales et Customer Care seront vos meilleurs alliés dans ce cas car ils vous permettront d’illustrer facilement vos propos par des éléments tangibles. Si vous complétez ces retours qualitatifs par de la donnée quantitative, issue de l’analytics par exemple, alors vos suggestions seront plus que justifiées.
Oublier les enjeux business
Ici aussi, je partage le point de vue de Fabrice des Mazery qui confie : “J’en connais qui sont tellement concentrés sur la satisfaction utilisateur qu'ils en oublient complètement le côté business. Le nerf de la guerre c'est de vérifier si les utilisateurs sont prêts à payer pour utiliser le produit. Pourquoi vont-ils le faire, et comment l'ensemble des équipes, trio inclus (Design ; Produit ; Dev), vont participer à le vendre ?”
Trop souvent, on oublie qu’une des prérogatives fondamentales du Product Manager et du trio est de s’organiser pour aussi apporter du revenu à l’entreprise ! Je vous conseille à ce sujet l’excellente tribune de Valentin Ménard, Group Product Manager chez ManoMano qui développe parfaitement ce point.
Ne pas parler à ses utilisateurs
Tout est dans le titre ! Aucune excuse ne peut vous être accordée si vous omettez ce principe de base, que vous fassiez du B2B ou du B2C et même si vos moyens sont limités. La frugalité est souvent source d'ingéniosité…
Pour remédier à cet “oubli”, je vous conseille de multiplier les points de contact :
- Testez en interne selon le principe de “eat your own dog food”. N’oubliez pas que vos collègues peuvent être de très bons premiers testeurs.
- Allez sur le terrain ! Quand je travaillais sur les applications mobiles des facteurs pour La Poste je partais en tournée et en centre de tri par exemple.
- Partez à la rencontre de vos utilisateurs. Chez 24S nous allions très souvent devant les grands magasins à Paris pour faire des user tests directement avec des clients en leur tendant un smartphone. Et vous savez quoi ? Ils jouaient le jeu !
- Récupérez les leads auprès des sales. Chez Lisy, quand un client n’était pas totalement prêt à payer pour la solution, on lui proposait de l’embarquer dans la recherche utilisateur, cela permet alors de créer une relation avec lui et - qui sait ? - de construire des éléments qui finiront par le convaincre.
Pour tous ces éléments la règle c’est : “n’ayez pas peur” ; vous serez surpris de constater que vos clients sont souvent très motivés et se formalisent peu pour la prise de feedbacks. Souvenez vous de ce que dit Teresa Torres dans Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value “Nous sous-estimons considérablement à quel point nos clients veulent aider”
Comment combattre le “Product Trap”
L’idée est de mettre en place des pratiques qui vous donneront raison progressivement. Il ne faut surtout pas être dogmatique mais plutôt convaincre vos interlocuteurs par des résultats concrets.
Lancer des premiers chantiers et prouver par l’exemple
De mon point de vue, mieux vaut avoir de l’impact sur des petits sujets bien menés que d’essayer de révolutionner une entreprise.
Livrer et communiquer autour de premiers succès mesurables démontre la valeur délivrée à plusieurs métiers. Cela permet d’enclencher un cercle vertueux : réduire la dette produit et démontrer par l’exemple le bien fondé de la méthode employée.
Ce que j’encourage pour y arriver c’est non pas seulement présenter les fonctionnalités livrées en démonstration, mais aussi les jalons qu’elles ont permis d’atteindre, ou a minima les feedbacks utilisateurs qu’elles ont générés.
Réfléchir aux modalités de mesure dès la conception
Trop souvent la mise en place de l’analytics arrive trop tard dans les organisations, et représente un sérieux sujet de dette produit.
Voilà pourquoi à chaque nouvelle opportunité je me pose deux questions :
- Comment j’en mesure la pertinence pour mieux la prioriser dans la roadmap ?
- Comment j’en mesure ensuite son utilisation pour confirmer son impact sur le business/sur l’expérience ?
Pour chaque opportunité, mettez en place une test card ou bien des modalités de vérification. Cela n’a pas besoin d’être trop complexe.
S’attaquer aux vrais problèmes
Trop souvent les gens se positionnent sur des sujets sur lesquels ils ont de la confiance : les “low hanging fruits”.
Or, selon Fabrice des Mazery encore, il faut réussir à tester des éléments qui vont réellement créer de la rupture car “l'enjeu est de responsabiliser les trios (Design, Produit et Dev) pour aller chercher ces vrais éléments qui porteront demain la stratégie, ceux qui représentent vraiment un ROI.”
L’idée ici n’est pas de faire les kamikazes en travaillant uniquement sur des sujets risqués, mais de se laisser de la bande passante pour creuser des sujets en rupture. Progressivement et par vos tests, vous confirmerez des hypothèses sur ces sujets et prouverez par l’exemple que ces sujets apportent de la valeur et méritent d’être adressés.
Pour conclure, n’oubliez jamais qu’un Product Manager doit avoir une posture proactive au sein de son organisation, l'objectif étant de progressivement convaincre par la valeur délivrée. Mais attention à ne pas être trop campé sur ses positions ! Les puristes sont souvent considérés comme hors sols, hors de la réalité de l’entreprise…. Au point d’agacer parfois.
Je pense donc que rester pragmatique est la clé. En tant que Product Manager, nous devons veiller à cela mais aussi à déterminer ce qui marche le mieux dans le contexte de l’entreprise. Bref, relativisez.
Enfin, si jamais vous décidez de changer d’entreprise, voici quelques questions à poser en entretien et qui pourront vous aider à savoir si l’entreprise qui vous recrute n’est pas victime de ces écueils :
- Comment est priorisée la roadmap ?
- Quels sont les prochains sujets à tester avec vos utilisateurs ?
- Sur quels KPIs l’équipe Produit est-elle objectivée ?
- Quel a été le plus gros fail produit ? / le plus gros succès ?
Vous aurez ainsi une idée de ce qui vous attend en étudiant ce que l’on vous répond.
Si cela vous intéresse de creuser ces derniers points ou même de débattre des éléments de cet article n’hésitez pas à me contacter.
Pour en savoir plus : télécharger notre livre Les Clés du Product Management
