Dans une ère ou le Product Management s'est égaré dans la feature factory, redéfinissons le rôle du Product Manager, de simple exécutant à génie créatif focalisé sur la valeur réelle et la croissance à long terme. Découvrez comment passer de la direction d'une "Feature Factory" à celle d'un "Value Generator Captain".
Le Product Management a débarqué sur le devant de la scène il y a 27 ans, quand Ben Horowitz sortait sa tribune Good Product Manager/Bad Product Manager.
27 ans… Et pourtant en 2023, qu’on le veuille ou non, la plupart des Product Managers se retrouvent à la tête de feature factories, cochant toutes les cases du “Bad Product Manager” décrit par Ben.
Ce serait trop facile de blâmer les Product Managers, j’ai souvent été contraint de gérer des feature factories alors que je rêvais d’appliquer les principes du Lean Startup.
Voilà 10 ans que je fais du Product Management et souvent le constat est le même chez mes pairs : “on a le mauvais rôle dans la boîte”, “on est le bouc-émissaire”, “on nous impose des roadmaps déconnectées des besoins”, “mon backlog est un puits sans fond, j’en fais des cauchemars la nuit”, “on est tout le temps en retard”, “c’est ça un burn-out..?”.
Repartons des bases pour comprendre ce phénomène, la plupart des startups du numérique reposent sur un produit unique, qui a lui seul fait la valeur de la boîte.
On commence par un MVP simple (trop simple ?) et on se dit que chaque ajout au produit va le rendre meilleur et finalement apporter de plus en plus de valeur.
Et on se laisse prendre dans un engrenage… L’amélioration d’un produit numérique, contrairement au produit physique, est sans fin.
En interne, on n’est jamais parfaitement satisfaits et c’est très facile d’inputer la médiocrité de notre croissance sur le manque de fonctionnalités de notre produit. Plutôt que d’aller voir du côté du market-product fit, du product-model fit ou encore du product-channel fit.
“Allez, encore ces 2-3 features et notre produit sera enfin parfait ! Ça va décoller je vous le dis”.
Mais cette mauvaise habitude vient aussi de la pression extérieure, des leads qui nous disent “c’est prometteur, mais on ne signera que si vous développez telle feature” ou encore des innombrables “solutions” proposées par nos utilisateurs qu’on priorise en se disant “mais oui c’est évident ! c’est ça qui va faire la différence !”.
En partant de ce constat, on s’est dit que plus on shippait rapidement ces features, plus vite le produit était amélioré, meilleure était notre croissance.
Simple. Basique.
Une course en avant sans fin… et souvent sans but car rien n’est réellement mesuré pour savoir si on prend vraiment le bon chemin.
Mais bon, c’est pour gérer cette soif de vitesse que les boîtes ont commencé à engager des Product Managers.
Avec un seul objectif : shipper toujours plus vite.
(Est-ce que c’est pour cette raison qu’en France on préfère embaucher des PO, bons petits soldats, plutôt que des PM ?).
Le problème c’est que, maintenant, c’est largement prouvé : aussi sérieusement que la roadmap a été imaginée, les deux tiers des idées que l’on va développer n’auront en fait aucun impact, voire un impact négatif, sur notre business et nos utilisateurs.
Et… ça ne s’arrête pas là. Car chaque addition au produit rajoute un coût de maintenance, complique le code et l’interface utilisateur et rend chaque futur développement plus difficile encore.
En partant de là, gardons en tête que tout ce qui n’a pas impact vraiment positif a un impact négatif.
On se retrouve rapidement dans un cercle vicieux infernal.
Plus on ship vite, plus on produit de déchets rapidement, plus notre vélocité s’enraye, moins on tient nos deadlines, plus on se concentre sur l’optimisation de notre vélocité au dépens de la valeur qu’on apporte au business et aux utilisateurs.
Et… Rapidement, le Product Manager n’a plus envie de se lever le matin pour aller bosser. Ses stakeholders lui en veulent de ne pas respecter les deadlines, les développeurs lui en veulent de leur mettre trop la pression et sont de moins en moins motivés par un produit de plus en plus complexe, une dette technique toujours plus grande. Et les utilisateurs ? complètement laissés pour compte dans toute cette histoire.
C’est simple : elles voient leurs équipes produit comme des générateurs de valeur, pas comme des usines à features.
Les Product Managers priorisent des “outcomes”, pas des solutions. Gardons l’anglicisme car il est utilisé couramment dans la littérature Product, mais on peut le traduire par des “résultats concrets attendus” par l’utilisateur ou le business. L’avantage est que pour chaque outcome, plusieurs solutions sont possibles, et c’est à force de tests qu’on va trouver la bonne.
Et non, il n’y a pas de miracle, ces boîtes génèrent elles aussi plus de 75% de “déchets”, mais la grande différence c’est qu’elles les valorisent. Chaque avancement, bon ou mauvais, est source d’apprentissage.
Les meilleures organisations génèrent non seulement des outcomes réels, mais aussi une connaissance commune, essentielle pour la croissance long terme.
Une fois la connaissance acquise, elles ne gardent pas les features qui les ralentissent.
L’apprentissage est intégré profondément et efficacement, à base de process de discovery, de product analytics puissants, de “smoke tests” ou autres “concierge MVP”…
Dans ces organisations, les Product Managers ont un rôle central, bien plus proactif que réactif.
On change de paradigme en se répétant que notre rôle n’est pas de sortir le plus de features possible mais d’augmenter considérablement le taux de “génération de valeur” de notre produit et son écosystème.
Il y a donc un passage obligé, définir un objectif commun, souvent appelé North Star Metric.
À quoi ça sert de bosser tous les jours sur un produit si on ne sait même pas quel impact notre travail a sur les utilisateurs et le business ?
Comment le dit Noah Kagan, “If you don’t measure it, it didn’t happen”.
C’est d’autant plus important que ça remet le produit au centre et ça aligne toutes les équipes derrière le même objectif.
Le rôle de chacun est d’améliorer directement cette North Star Metric, ou plutôt les “input KPI” qui vont améliorer la North Star Metric.
Les outcomes gérés par le Product Manager vont découler de cet objectif.
Une première grosse étape est donc franchie : le Product Manager sait pour quoi il travaille dur tous les jours grâce à la direction que lui donne la North Star Metric.
Repartons de ce constat, qui devrait même être collé au dessus de notre ordi : tout ce qui n’a pas d’impact positif sur notre North Star Metric, a un impact négatif sur notre business et nos utilisateurs.
Il faut donc mesurer l’efficacité de notre organisation Produit par son taux de “value generators”.
C’est quoi ?
À partir de là, on peut déjà faire un grand ménage dans ce qui est déjà live. Analysez tout ce qui est déjà en ligne, partagez et consignez ces apprentissages qui vont vous apporter plein d’idées et surtout… N’hésitez pas à débrancher ce qui n’a pas d’impact avéré voire un impact négatif.
Passons à notre process produit.
Il faut savoir arrêter notre travail sur une feature si on se rend compte que son impact positif est trop incertain. Mais sans oublier de documenter ce qu’on a appris en chemin.
Avant même de se lancer dans la construction de la feature, il faut savoir prioriser les outcomes qui ont le meilleur potentiel d’amélioration de nos objectifs.
Et peut-être le plus dur, mais le plus libérateur : savoir dire “non” (sans qu’il soit forcément définitif) à des idées dont le potentiel de génération de valeur est beaucoup trop incertain.
C’est si facilement résumé dans ce petit paragraphe, mais a l’air de demander une telle force de changement…
Il est d’abord temps d’enterrer définitivement notre backlog sans fin et le remplacer par un véritable flow de génération de valeur.
Avec une Inbox qui recueille toutes les idées et qui les dispatch efficacement : en discovery quand on a besoin d’améliorer son potentiel, dans le backlog quand ce n’est pas encore son jour, dans la shortlist quand au contraire c’est son heure de briller !
Un autre gros changement qu’apporte ce flow, c’est de dire que ce n’est pas parce que la feature est live que notre travail est fini, il est encore temps de l’analyser, de l’améliorer si besoin pour qu’elle apporte plus de valeur ou au contraire de la débrancher si elle n’en produit pas assez…
Ce flow s’inscrit dans un processus circulaire de création de valeur : on génère des idées d’outcomes, on les priorise pour ne travailler que sur ce qui a le meilleur potentiel, on apprend de tout ce qu’on entreprend et on ne sort que les idées qui vont avoir un impact avéré.
Tout en générant de meilleures idées grâce à nos apprentissages en chemin.
C’est reparti pour un tour.
Pour en savoir plus, ne pas hésiter à lire mon article sur la Product Flywheel.
Rapidement, on augmente notre taux de “value generators”, ce qui naturellement améliore la croissance de notre produit.
On passe d’un cercle vertueux infernal à une boucle ultra vertueuse.
Et on se lève à nouveau tous les matins avec une motivation sans limites.
.png){kind=small}