Dans cet épisode, nous plongeons dans le phénomène de la « feature factory » (usine à fonctionnalités), où les entreprises privilégient la rapidité de sortie des produits et des fonctionnalités au détriment de la qualité ou des besoins utilisateurs. John Cutler a inventé ce terme, qui traduit parfaitement le ressenti de nombreuses équipes : lancer des fonctionnalités sans savoir clairement à qui elles s’adressent ni quel impact elles ont sur l’entreprise. Si cela vous parle, continuez à écouter pendant que nous explorons comment sortir de ce cercle vicieux.
Lors de notre table ronde, trois leaders produit — Aakash Gupta, Andrea Saez et Paweł Huryn — partagent leurs réflexions sur la transition d’un développement produit axé sur la production vers un développement orienté résultats. Ils proposent des méthodes concrètes pour rester stratégiques, répondre aux pressions du marché intermédiaire et cultiver une culture qui valorise les résultats significatifs plus que la quantité de fonctionnalités. Que vous cherchiez à faire grandir votre entreprise ou à relancer la créativité de votre équipe, cette conversation apporte des conseils pratiques pour sortir de la mentalité de feature factory.
Moments forts de l'entretien
- Section 1 : Pourquoi les feature factories sont-elles si courantes ? [02:21]
- Il n’y a pas un chemin unique menant au problème de « feature factory » — de nombreux facteurs entrent en jeu.
- Les causes incluent la pression pour conclure des ventes, un leadership produit faible, l’influence du « hippo » (avis de la personne la mieux payée), ou la poursuite des nouveautés clinquantes.
- Le problème principal est souvent le manque d’influence stratégique d’un responsable produit solide.
- Les leaders produit doivent guider la stratégie, gérer les compromis et négocier les priorités.
- Parfois, des concessions sont nécessaires (par exemple, développer des fonctionnalités pour le chiffre d'affaires), mais il est crucial de se réaligner sur la stratégie produit par la suite.
- Éviter une feature factory n’est pas tout blanc ou tout noir : il s’agit de préserver l’orientation stratégique sur le long terme malgré quelques compromis.
- On a souvent tendance à idéaliser les grandes entreprises tech (par exemple, Google, Meta) comme des modèles parfaits de gestion produit.
- En réalité, dans ces entreprises, les fonctionnalités marquantes sont généralement initiées par les dirigeants, et non découvertes par les chefs de produit.
- La recherche produit continue menée par les PM est rare dans ces environnements.
- Beaucoup des plus grandes entreprises fonctionnent davantage comme des feature factories que l’on ne le pense.
- Même des sociétés comme Apple ou Snapchat pratiquent un développement de fonctionnalités de façon descendante.
- Les PM doivent apprendre à naviguer et à agir efficacement dans les situations de « feature factory », qui sont fréquentes, au moins temporairement.
- Les grandes entreprises technologiques peuvent se permettre de prendre des risques et de « sortir pour apprendre » grâce à leurs gros budgets.
- La plupart des entreprises n’ont pas ce luxe et ne peuvent pas supporter le même niveau de risque.
- Imiter la mentalité « avancer vite et casser des choses » peut être néfaste pour les entreprises plus petites ou avec moins de ressources.
- Tenter de fonctionner comme Google ou Facebook sans leurs moyens n’est pas réaliste.
- Les entreprises plus petites doivent aborder les décisions produit avec plus de prudence et de stratégie.
Il y a des négociations et des concessions à faire, mais le plus important est d’avoir un responsable produit capable de dire : « D’accord, nous l’avons fait. Maintenant, recentrons-nous sur notre stratégie, sur ce que nous essayons vraiment de faire et de résoudre. »
Andrea Saez
- Être une feature factory est-ce toujours mauvais ? [07:21]
- Être une feature factory n’est pas fondamentalement mauvais — cela peut être viable selon le modèle économique.
- Toutes les demandes de fonctionnalités ne nécessitent pas une découverte approfondie ; certaines sont évidentes (par exemple, l’intégration Stripe).
- Les parties prenantes ont souvent des idées précieuses que les PM ne doivent pas ignorer.
- C’est du gaspillage de négliger la connaissance organisationnelle existante lorsque de nouveaux PM arrivent.
- Dans certains modèles (par exemple, client-fournisseur), créer des fonctionnalités demandées permet réellement de générer des revenus.
- Si le modèle d’une entreprise repose sur cela, il vaut mieux l’accepter ou partir plutôt que de chercher à le changer.
- Section 2 : Les voies pour sortir de la feature factory [09:15]
- Les indices d’un désalignement produit-marché incluent des retours négatifs, un fort taux de résiliation et des cycles de vente qui s’allongent.
- Ces pressions mènent souvent à des décisions de fonctionnalités précipitées pour sauver des ventes ou des clients.
- Cette posture réactive peut entraîner une perte de cohérence du produit.
- Les fonctionnalités peuvent devenir déconnectées, et l’UX en pâtit — Andrea critique avec humour des outils comme Jira à ce sujet.
- La vraie cause est souvent un affaiblissement de l’adéquation produit-marché qui mène à un développement paniqué.
Si les équipes ne sont pas alignées sur la manière dont nous créons de la valeur, sur les clients que nous voulons servir, sur les problèmes que nous souhaitons aborder et sur ce qui différencie ce que nous construisons, alors il pourrait être extrêmement difficile de délivrer de la valeur dans différentes équipes.
Paweł Huryn
- Intervention précoce en gestion de produit [10:35]
- Commencez par un alignement stratégique clair au sein de l’organisation : définissez la façon dont la valeur est créée, qui sont les clients cibles et quels problèmes sont à résoudre.
- Assurez-vous que chacun comprend l’approche unique et le contexte stratégique de l’entreprise (« contexte, pas contrôle » comme chez Netflix).
- Alignez les objectifs d’équipe et de département sur les priorités clés de l’organisation.
- Donnez aux équipes des problèmes significatifs et des résultats attendus, plutôt que de prescrire des solutions.
- Fournissez du coaching si nécessaire pour aider les équipes à adopter des pratiques de découverte produit en continu.
- « Usine à fonctionnalités » est un terme négatif, mais il est important d’identifier et de traiter ses éléments destructeurs.
- Faites se concentrer les dirigeants sur les bons domaines d’activité, métriques et problèmes utilisateurs afin de créer un maximum de levier.
- Apportez des informations aux dirigeants, incluant des retours d’utilisateurs (p.ex. replays de sessions, analytics) et des données issues de l’analyse (p.ex. opportunités de croissance).
- Ces informations aident à orienter le focus sur les métriques et problèmes importants, en cohérence avec la stratégie globale.
- Laissez les équipes (designers, PM) itérer et ajuster sur la base des retours utilisateurs, plutôt que de suivre à la lettre les plans des dirigeants.
- Mettez en place des points de contrôle et des revues produits pour garder les dirigeants impliqués et éviter le problème du « relais » où leur conception est mal reçue par la suite.
- L’alignement de l’équipe est crucial : veillez à ce que l’alignement soit réel et non de façade.
- L’alignement exécutif est essentiel : tout le monde doit être sur la même longueur d’onde quant à ce qui est fait, pourquoi, comment et pour qui.
- Le désalignement intervient souvent autour du client cible (ICP), car les équipes essaient parfois de vendre à différents publics.
- Ce manque d’alignement peut mener à l’ajout de fonctionnalités qui ne sont pas adaptées au produit central ou à l’audience cible.
La chose la plus importante qu’on peut faire dans une entreprise n’est pas nécessairement de se concentrer sur le bon compartiment du business. Il s’agit d’amener son équipe dirigeante à se concentrer sur les domaines, les métriques et les problèmes utilisateurs qui comptent réellement. Il s’agit d’apporter des informations qui établissent votre crédibilité tout au long du chemin.
Aakash Gupta
- Sortie de fonctionnalités imparfaites [17:02]
- Parfois, les entreprises lancent des fonctionnalités imparfaites avec l’intention de les améliorer plus tard, mais elles finissent par rester coincées dans ce cycle d’« usine à fonctionnalités », sans jamais revenir les améliorer.
- Paweł pense que lancer des fonctionnalités imparfaites (par exemple, résoudre 70-80 % du problème) est souvent la bonne approche.
- Lancer tôt permet d’obtenir des retours précieux des utilisateurs et la possibilité d’améliorer sur la base de données réelles, plutôt que d’hypothèses.
- Même après avoir testé les designs, l’usage réel peut révéler d’autres enseignements, ce qui rend importantes les sorties itératives.
- Lancer avec intention est essentiel : tout ne doit pas être parfait.
- Un problème courant est de publier des fonctionnalités « inabouties » et de ne jamais revenir les améliorer, ce qui conduit à ce piège de la fonctionnalité.
- Les équipes peuvent se focaliser sur les nouvelles fonctionnalités sans traiter la facilité d’usage élémentaire ni améliorer l’existant.
- Il y a une tendance à croire que les utilisateurs vont comprendre les fonctionnalités incomplètes plutôt que de les affiner.
- Le problème de l’« usine à fonctionnalités » consiste à sortir des fonctionnalités inabouties et à ne jamais s’en occuper à nouveau à cause du syndrome de l’objet brillant.
- Pour sortir de ce cycle, apportez des retours utilisateurs (p.ex. faible rétention, faible adoption) et des données factuelles (p.ex. replays de sessions, taux de rétention) aux dirigeants.
- Mettre en lumière des problèmes comme une adoption faible peut aider à obtenir un soutien pour itérer sur des fonctionnalités ou traiter les problèmes de rétention.
- Dans certains cas, il vaut mieux supprimer des fonctionnalités qui n’apportent pas de réponse aux besoins fondamentaux des utilisateurs.
- Surtout en B2B, se concentrer sur le produit central est souvent plus impactant que de tenter de se diversifier trop tôt dans plusieurs produits.
- Section 3 : Nous sommes en mode usine, et maintenant ? [21:31]
- En tant que leader produit (par exemple, VP Produit ou CPO), le rôle consiste à identifier et traiter les défaillances organisationnelles, pas seulement à célébrer les réussites.
- Le travail consiste à évaluer les performances passées, analyser les fonctionnalités lancées, et déterminer si elles ont réussi ou échoué.
- Si 75 % des fonctionnalités échouent, il est essentiel de repenser l'approche et d'ajuster la stratégie pour l'avenir.
- Les grands leaders produit maîtrisent le langage des parties prenantes et influencent les décisions par la donnée et les insights, pas seulement par la théorie.
- L'absence de leadership produit fort peut contribuer au problème d'usine à fonctionnalités.
- Dans les situations difficiles avec des fondateurs ou PDG peu coopératifs, il peut être nécessaire d’envisager un changement de poste pour progresser dans sa carrière.
- Un CPO ou VP Produit a besoin du soutien et de l’alignement du PDG et de la direction pour être efficace.
- Sans alignement au niveau de la direction, il est difficile d’avancer, et un développement piloté par les ventes peut saper le leadership produit.
- Il est crucial de se concentrer sur les comportements utilisateurs mesurables ; les fonctionnalités doivent encourager des actions répétables, évolutives et utiles pour les utilisateurs.
- Beaucoup de fonctionnalités sont lancées juste pour sortir du code, sans se demander si elles résolvent vraiment les problèmes des utilisateurs ou apportent de la valeur.
- Il existe également une dimension éthique quant à l’impact des nouvelles fonctionnalités sur la vie et les usages des utilisateurs.
- Les chefs de produit ayant une influence limitée peuvent tout de même initier le changement au sein de leurs équipes, même s’ils ne peuvent transformer toute l’organisation.
- Dans un poste précédent, Paweł a mené une initiative qui a rompu avec le cadre Agile rigide (qu’il considère proche du modèle en cascade) en mettant en lumière les problèmes du modèle existant.
- Ils ont proposé des expérimentations et travaillé avec une équipe cœur et des collaborateurs selon une approche plus Agile, ce qui a suscité le succès de leur initiative.
- Même si l’ensemble de l’organisation n’a pas changé, l’approche a très bien fonctionné pour leur objectif.
- Andrea reconnaît le travail difficile qu’implique la conduite du changement au sein d’une organisation, comme l’a souligné Paweł.
- Elle exprime son admiration pour l’effort nécessaire à la mise en place de transformations et l’impact émotionnel que cela peut avoir sur la santé et le bien-être.
- Malgré les difficultés, Andrea estime que la transformation réussie offre de réelles opportunités d’apprentissage une fois qu’elle est accomplie.
- Session de questions-réponses [28:28]
- Passer de l'usine à fonctionnalités à la création continue de valeur [28:36]
- La transition d’une usine à fonctionnalités à une création continue de valeur client nécessite de se concentrer sur la valeur client parallèlement à la stratégie produit.
- Andrea insiste sur l’importance d’identifier, de suivre et de se concentrer sur la valeur client, en collaborant avec les principaux métiers comme les ventes, le service client et le support.
- Le modèle de plan de création de valeur produit (VCP) aide à aligner les équipes et à garantir une compréhension commune de la valeur.
- Les décisions relatives au produit ne doivent pas être prises en vase clos ; la collaboration inter-équipes est essentielle pour délivrer de la valeur.
- Favoriser les discussions stratégiques et l’alignement [29:53]
- Pour favoriser l’alignement autour d’un objectif produit, commencez par se demander si l’objectif est le bon et mettez en place un processus collaboratif.
- Travaillez avec un analyste ou un tiers pour réunir données et insights, afin que tous puissent apprendre et échanger ensemble.
- Utilisez des outils comme Miro pour animer des ateliers de remue-méninges en ligne, évaluer différents indicateurs et objectifs, et discuter des avantages et inconvénients de chacun.
- Documentez les options et les retours pendant les discussions, en impliquant les équipes clés telles que data science, PM, design et ingénierie.
- Terminez par une réunion finale pour décider de l’objectif, en s’assurant que chacun puisse contribuer et s’engager, même si cela prend plus de temps.
- Résoudre la déconnexion entre insights et fonctionnalités [32:02]
- La situation concerne des insights partagés et un chef de produit qui pousse des fonctionnalités trop vite sans validation adéquate.
- Paweł propose de remonter à la source du problème que doivent résoudre les fonctionnalités et de valider ces hypothèses.
- Il recommande de vérifier que le problème est aligné avec les objectifs et la stratégie globale de l’organisation.
- Un membre de l’équipe, autre que le chef de produit, devrait examiner les incohérences entre les données analytiques et les fonctionnalités en cours de développement.
- Andrea approuve Paweł, soulignant deux questions fondamentales : « Quel problème cherchons-nous à résoudre et pourquoi ? » et « Pour qui le résolvons-nous ? »
- Elle partage son expérience avec une équipe produit qui privilégiait la livraison rapide au détriment d’une réflexion claire.
- Andrea suggère de demander à l’équipe d’expliquer le problème et le processus de décision pour mieux comprendre la valeur apportée.
- À l’aide d’un cadrage du problème produit, elle encourage les équipes à prendre en compte l’impact business, la valeur client et la finalité de leur travail.
- L’usine à fonctionnalités à travers les différentes phases de l’entreprise [34:47]
- Aakash souligne que les usines à fonctionnalités peuvent exister à toutes les phases d’une entreprise, même dans de grands groupes prospères.
- Les jeunes entreprises peuvent ressentir le besoin de copier des produits à succès, entraînant des comportements d’usine à fonctionnalités.
- La vraie question : l’usine à fonctionnalités bloque-t-elle le ROI ? Les PM doivent s’assurer que leur travail génère suffisamment de valeur pour l’entreprise.
- Ce travers peut être présent aussi bien chez les jeunes startups que dans les grands groupes comme Meta ou OpenAI.
- Valeur du profil hybride business et technique chez les chefs de produit [37:23]
- Andrea pense que les chefs de produit ayant une double compétence business et technique comprennent mieux le ROI et l’impact sur les ventes.
- Les PM purement techniques risquent de se concentrer uniquement sur l’aspect technique, en négligeant la façon dont une fonctionnalité sera vendue ou son impact sur la rentabilité.
- Un exemple-clé est de se demander à qui s’adresse une fonctionnalité et comment elle sera vendue (entreprise VS particulier), question parfois négligée par les PM techniques.
- Les PM orientés business intègrent généralement aussi la perspective technique et commerciale dès le départ.
- Aakash suggère d’exploiter un profil business en se concentrant sur les modèles d’impact et de croissance.
- Les PM avec un profil business doivent valoriser leurs points forts, comme la rédaction de spécifications de fonctionnalités ou l’analyse des impacts.
- Les PM techniques peuvent acquérir des compétences business au fil du temps, il vaut mieux jouer sur ses forces que se comparer aux autres.
- Le poste de PM permet de s’adapter et de mettre en avant ses atouts, comme utiliser Excel pour l’analyse de données si c’est une force.
- Transformer les insights en éléments de backlog [40:10]
- Paweł insiste sur l’importance de tirer parti des insights issus de différentes sources comme les interviews utilisateurs, les parties prenantes, la veille marché et la data analyse.
- Il évite d’ajouter trop tôt des user stories ou des fonctionnalités au backlog, préférant d’abord finir la phase de discovery et tester les hypothèses.
- Les insights sont rangés dans un backlog ou outil séparé (comme Miro), et reliés à des besoins utilisateurs avant de devenir des user stories.
- Les éléments du backlog de plus de 12 mois sont archivés pour garder une backlog gérable ; les points importants réapparaîtront si nécessaire.
- Passer de l'usine à fonctionnalités à la création continue de valeur [28:36]
Rencontrez nos invités
Aakash Gupta est un leader produit chevronné avec plus de 15 ans d'expérience, ayant occupé des postes clés comme VP of Product chez Apollo.io, où il a contribué à la croissance de l'entreprise jusqu'à une valorisation de 1,2 milliard de dollars. Il a également dirigé les fonctions de croissance produit dans des entreprises telles que thredUP, Affirm et Epic Games. Aakash est l'auteur de la newsletter « Product Growth », l'une des plus importantes au monde dans son domaine, offrant des analyses approfondies sur le management produit, le leadership et l'évolution de carrière à plus de 160 000 abonnés. Il est également l'auteur de « The Ultimate Guide to Getting a PM Job », fournissant des stratégies complètes pour les futurs chefs de produit. Aakash s'engage activement auprès de la communauté du management produit à travers des conférences, des podcasts et des cours en ligne, partageant son vaste savoir pour aider les autres à réussir dans le domaine.
Si vous êtes VP of Product, Chief Product Officer ou peu importe le titre, et que vous êtes la personne au sommet, fondamentalement, si vous faites bien votre travail, vous êtes toujours en train de signaler toutes les insuffisances de votre organisation et tous les problèmes qui doivent être résolus. C'est en fait cela, le travail.
Aakash Gupta
Paweł Huryn est le fondateur et auteur de The Product Compass, une newsletter largement reconnue offrant des analyses concrètes et des ressources à plus de 105 000 chefs de produit dans le monde entier. Avec plus de 15 ans dans le secteur technologique, dont cinq ans en tant que Chief Product Officer et plus d'une décennie en gestion de produit, Paweł s'est imposé comme une référence dans le domaine. Son expertise englobe la découverte produit, la stratégie et l'intégration de l'IA dans la gestion produit. Au-delà de ses écrits, Paweł s'investit auprès de la communauté du management produit lors de conférences, à travers des cours en ligne et via sa présence active sur des plateformes telles que LinkedIn et YouTube. Son engagement à simplifier les sujets complexes et à fournir des conseils pratiques fait de lui un mentor de confiance pour les chefs de produit débutants comme confirmés.
Vous pouvez aussi influencer beaucoup de choses au sein de votre équipe. Alors, ne vous contentez pas de demander la permission — commencez à collaborer avec vos designers et invitez vos ingénieurs à réfléchir aux solutions, plutôt que de tout préparer à l'avance et de dialoguer seul·e avec les clients.
Paweł Huryn
Andrea Saez est une professionnelle expérimentée du marketing produit avec plus de dix ans d'expérience à faire le lien entre le développement produit et l'engagement client. Elle a occupé des postes influents au sein de startups et scale-ups telles que ProdPad, airfocus et Trint, où elle s'est concentrée sur la stratégie, le positionnement et la collaboration inter-équipes. Andrea est co-autrice de « The Product Momentum Gap », un livre qui explore l'alignement de la stratégie produit avec la valeur client. Elle intervient aussi régulièrement comme conférencière et autrice au sein de la communauté du management produit.
Vous pouvez être le meilleur CPO, le meilleur VP of Product, vous pouvez essayer de tout faire correctement, mais si vous n'avez pas le soutien de votre CEO et du reste des dirigeants, vous n'arriverez à rien.
Andrea Saez
Ressources issues de cet épisode :
- Abonnez-vous à la newsletter The CPO Club
- Connectez-vous avec Aakash, Paweł et Andrea sur LinkedIn
- Découvrez la Product Growth Newsletter, la Product Compass Newsletter et The Product Momentum Gap
Articles et podcasts associés :
Lisez la transcription :
Nous testons la transcription de nos podcasts à l’aide d’un programme informatique. Pardonnez-nous pour d’éventuelles fautes, le robot n’est pas fiable à 100%.
Hannah Clark : Feature factory — nom féminin ; une entreprise qui lance constamment des produits, fonctionnalités et améliorations, mais qui privilégie majoritairement la quantité à la qualité. Origine : John Cutler. Utilisé dans une phrase : « Nous avons lancé trois nouvelles fonctionnalités ce trimestre, et je ne sais pas pour qui elles sont. On commence à ressembler à une feature factory. » Si cette définition vous semble familière, restez à l’écoute.
Lors de notre récent événement panel « Est-ce que toutes les routes mènent à la Feature Factory ? », nous avons réuni trois responsables produit ayant observé ce phénomène sous différents angles. Aakash Gupta — ex-VP Produit d’une licorne et auteur actuel de la ‘Product Growth Newsletter’, Andrea Saez — leader marketing produit et autrice de ‘The Product Momentum Gap’, et Paweł Huryn — auteur de la ‘Product Compass Newsletter’.
Ils partagent la réalité dérangeante de reconnaître la pensée axée sur le rendement (output) plutôt que sur l’impact (outcome), des cadres pratiques pour garder un cap stratégique malgré les pressions du mid market, ainsi que des outils concrets pour transformer votre équipe de développeurs de fonctionnalités en générateurs de valeur.
Que vous tentiez de dépasser 100 millions d’ARR ou de retrouver l’esprit innovant de votre équipe, considérez cette conversation comme votre passeport de sortie du modèle feature factory. Allons-y.
Au fait, nous organisons ce type d’échanges chaque semaine, alors si cela vous intéresse, pourquoi ne pas vous abonner ? Très bien, on y va !
Nous allons donc démarrer notre discussion en jetant un œil aux premiers sondages. Il semble que nous ayons une répartition assez égale entre ceux qui considèrent que leur organisation est une feature factory et ceux pour qui ce n’est pas clair. Nous allons donc commencer par définir ce terme.
Je pense que cela aidera tout le monde à bien comprendre ce que nous voulons dire par feature factory. La définition que nous utilisons vient, je crois, de John Cutler, qui l’a inventée. Une feature factory est une entreprise qui livre de manière continue produits, fonctionnalités, améliorations, etc., et se concentre principalement sur la quantité plutôt que la qualité.
L’accent est donc mis sur le livrable au détriment du résultat. Ce que nous pointons ici, c’est la situation où l’on expédie bon nombre de fonctionnalités, sans forcément savoir si elles apportent une réelle valeur business, ou si elles résonnent vraiment auprès des utilisateurs.
Évidemment, cela soulève des problématiques. Nous structurerons le débat en trois parties. La première sera : pourquoi la feature factory est-elle si répandue ? Ensuite, les chemins pour en sortir. Enfin, que faire quand on est en mode usine à fonctionnalités ?
Démarrons avec la première section. Première question pour Andrea : comment des organisations bien intentionnées deviennent-elles des feature factories ? Comment ce phénomène se développe-t-il ?
Andrea Saez : Pour être honnête, il n’y a pas de chemin unique. On me demande souvent : « Comment l’éviter ? » Mais il y a plusieurs voies qui y mènent.
Cela va de la nécessité de conclure des ventes sans bon leader produit, à l’effet « HIPPO » (Highest Paid Person’s Opinion) ou le syndrome de l’objet brillant. De nombreux facteurs peuvent mener à cela, mais le problème de fond reste le manque d’influence du leader produit, incapable de définir une stratégie claire et d’expliquer ce que l’on fait, pourquoi on le fait.
Il s’agit aussi de savoir mener les négociations : parfois, il faut livrer une fonctionnalité pour des raisons précises, mais ensuite ramener l’équipe sur le cap stratégique. En réalité, aussi idéal que cela paraisse de dire « on ne fera jamais ça », il y a toujours des concessions à faire au fil des carrières et des aventures entrepreneuriales. Il faut parfois construire ces fonctionnalités pour des questions de revenus.
Ce n’est donc pas noir ou blanc ; il y a des compromis nécessaires. Ce qui compte, c’est de disposer d’un leader produit capable de ramener la feuille de route vers la stratégie, vers la finalité qu’on essaie d’atteindre et de résoudre.
Hannah Clark : Aakash, as-tu quelque chose à ajouter ? Il me semble que tu m’as fait part d’une perspective qui a inspiré cette discussion : il semble que toutes les routes mènent à la feature factory. Quel est ton ressenti ?
Aakash Gupta : Oui, je pense qu’on a tendance à idéaliser certains géants de la tech de la Silicon Valley (Google, Netflix, Meta…) en se disant que si on fait comme eux, nos problèmes seront résolus et notre business décolle. Beaucoup suivent ce conseil, puis réalisent rapidement que ce n’est pas si simple.
Le plus grand écart que j’ai constaté, c’est que lorsqu’on parle à des PMs de ces boîtes et qu’on leur demande quelle fonctionnalité majeure ils ont expédiée récemment, ils répondent mais, la genèse de ces fonctionnalités — qui les a décidées ? — provient quasi toujours de l’équipe de direction, débattues pendant des mois. Il n’y a pas ce processus de découverte continue où le PM échange avec les utilisateurs tous les quinze jours et propose LA solution à laquelle personne n’avait pensé.
Ça, ça n’arrive jamais. Il y a une survalorisation de ces entreprises. Prenez Apple ou Snapchat : Evan Spiegel (Snapchat) expliquait récemment que quasiment tout était dicté par quelques designers et le CEO. C’est une usine à fonctionnalités à l’état pur. Les gens idéalisent donc ce modèle alors que, souvent, beaucoup d’entreprises reproduisent ce fonctionnement au moins partiellement : parfois à cause d’exigences commerciales ou de demandes clients.
Nous devons donc tous apprendre à évoluer dans cet environnement feature factory.
Andrea Saez : Je vais me permettre un brin de controverse, puisque cela m’a été demandé ! Je suis à 100% d’accord avec Aakash, mais il faut aussi bien comprendre que les entreprises qu’il cite ont le budget pour agir ainsi.
Ils peuvent se permettre de livrer pour apprendre, ou de prendre des risques, car ils peuvent les absorber. La majorité des autres entreprises n’ont pas ce budget ! Donc tenter d’opérer comme Google ou Apple et « shipper pour shipper » est très risqué – souvenez-vous du fameux mantras de Facebook : Move fast and break things (avancer vite et casser des choses), la pire chose à faire si vous n’êtes pas Facebook. En réalité, peu de gens travaillent chez les géants du numérique, et même là, ce qu’ils font est permis par leurs moyens. Moi je ne peux pas me le permettre, je dois être plus intelligente dans mes choix.
Hannah Clark : Je pense qu’on a désormais une idée de la façon dont cela se développe, qui peut se le permettre ou non.
En termes de spectre entre bon et mauvais, être une feature factory est-il forcément négatif, ou cela peut-il fonctionner selon le modèle économique ? Avez-vous une alternative viable ?
Paweł Huryn : Je ne suis pas totalement d’accord avec l’idée qu’il faille toujours faire des concessions en discutant fonctionnalités avec les parties prenantes ou à la demande utilisateur. Certains besoins sont évidents (ex : intégration Stripe). On pourrait tenter de les transformer en « problèmes à résoudre », mais parfois, explorer le champ du problème n’est pas nécessaire. Les parties prenantes peuvent avoir des idées ou des retours que le PM ne trouve pas.
Il ne faut donc pas écarter totalement ces insights. J’ai vu des PMs arriver dans de nouvelles organisations et ne s’appuyer que sur les utilisateurs, alors que des parties prenantes échangeaient des centaines d’heures avec les clients. Ce serait du gâchis de les ignorer.
Enfin, les entreprises ont besoin de générer des revenus ; pour certaines, répondre aux demandes clients directement, même si cela ne plaît pas à l’équipe produit, c’est un modèle viable. Dans ces cas, soit on l’accepte, soit on part ailleurs.
Hannah Clark : C’est vrai, si cela fonctionne et maintient l’activité, parfois il faut accepter les faits.
On retourne vers Andrea pour la suite : les chemins pour sortir de la feature factory. Oublions le débat moral : comment évaluer si une entreprise surinvestit dans le court terme au détriment de la valeur long terme ? Où placer le curseur ?
Andrea Saez : Les premiers signaux, ce sont les retours négatifs, le churn, des cycles de vente qui s’allongent : cela indique sûrement que le produit n’est plus en adéquation avec son marché (product-market fit). C’est souvent à ce moment-là qu’on commence à vouloir sortir des nouveautés pour sauver des comptes ou conclure des deals, et alors la situation dérape.
Vous voyez alors défiler des features dans Jira, etc. Est-ce qu’elles font sens ? Pour votre cible ? L’UX est-elle cohérente ? Pour l’amour de Dieu, Jira, à quoi joues-tu ? Si le produit n’est plus en phase avec sa cible, cela se remarque vite.
Hannah Clark : Parlons de l’intervention précoce. Si on commence à s’éloigner, quels garde-fous peut-on mettre en place, notamment si l’on a de l’influence dans l’organisation ? Paweł, tu veux répondre ?
Paweł Huryn : Le point de départ, c’est l’alignement stratégique pour toute l’entreprise : sur la création de valeur, les clients visés, les problèmes traités… Si tout le monde n’est pas aligné, difficile de contribuer à la valeur. C’est ce que Netflix résume par du « contexte, pas du contrôle ».
Ensuite, il faut aligner les équipes sur les objectifs majeurs (trimestriels, annuels). Il s’agit enfin de donner aux équipes l’autonomie nécessaire pour mener la découverte produit continue (avec accompagnement si besoin), en leur assignant des problèmes concrets à résoudre et des résultats clairs attendus pour maximiser la valeur client et business.
En résumé : alignement stratégique, puis autonomisation pour découvrir et innover.
Hannah Clark : Pour compléter, j’ai récemment discuté avec Cem Kansu (CPO de Duolingo), qui m’expliquait leur système de « vaches sacrées » : des choses intouchables, fondamentales à la vision de l’entreprise, servant de boussole pour les décisions stratégiques.
Paweł Huryn : Oui, fixer explicitement ce qu’on NE fait pas ou qui n’est pas notre cible est aussi crucial que ce sur quoi on se concentre, pour éviter la dispersion.
Hannah Clark : Avant d’aborder la 3e partie, vouliez-vous ajouter un point sur les gardes-fous à mettre en place pour sortir du mode usine à fonctionnalités ?
Aakash Gupta : Oui, « feature factory » est un terme péjoratif. Le plus destructeur, c’est de ne pas se concentrer sur ce qui compte réellement pour l’organisation. L’effet de levier numéro un, c’est d’amener la direction à se concentrer sur les métriques et problèmes utilisateurs importants — en s’appuyant sur des insights utilisateurs et sur la donnée (interviews, analytics, replays de sessions, etc.), puis sur des insights business (ex : « saviez-vous que 16% de nos clients ne font pas telle action, si on convertit la moitié, cela rapporte X millions… »). Cela permet d’orienter les discussions sur les bons métriques.
Ensuite, il faut laisser les équipes terrain (designers, PMs) expérimenter et itérer sur les solutions, tout en maintenant des checkpoints avec les décideurs pour qu’ils restent impliqués, et éviter l’effet tunnel.
Hannah Clark : Merci pour ces précisions. Autre chose à ajouter ?
Andrea Saez : Je ne dirais rien de différent, je suis totalement d’accord. J’ajouterais juste : assurez-vous de l’alignement réel. J’observe beaucoup d’échecs d’équipes parce qu’elles disent « oui », puis une semaine après tout le monde part dans sa direction. L’alignement doit partir du sommet, sur le quoi, le pourquoi, le comment et surtout le pour qui, car c’est souvent là que naît la confusion ; si chacun vise une clientèle différente, on multiplie les fonctionnalités hors-sujet.
Hannah Clark : Sur la question du développement court-termiste, il arrive que des entreprises lancent des features déconnectées de la vision, avec l’intention d’y revenir plus tard. Mais une fois dans la spirale feature factory, on ne le fait jamais, générant ainsi une dette de fonctionnalités. Qu’en pensez-vous ?
Paweł Huryn : L’idée de sortir des fonctionnalités imparfaites, c’est exactement ce qu’il faut faire ! Livrer pour le plus grand nombre de cas d’usage, obtenir des retours, itérer. Même si les tests utilisateurs donnent un aperçu, rien ne remplace les retours réels en production. Donc oui, pour des sorties imparfaites mais intentionnelles.
Hannah Clark : Andrea, comment cela s’intègre-t-il dans la stratégie, sachant que tu n’as pas le budget pour livrer à ce rythme ?
Andrea Saez : Je suis d’accord avec Paweł : il faut lancer avec intention — tout ne doit pas être parfait. Le danger, c’est de livrer puis de ne jamais revenir pour corriger ou améliorer, ce qui nous piège dans une spirale de features à moitié terminées.
Aakash Gupta : Exactement. Le grand danger de la feature factory, c’est cette course à la nouveauté, la livraison de fonctionnalités bâclées qu’on ne vient jamais corriger, alors qu’on sait ce qu’il faudrait faire. Pour en sortir, il faut ramener ces insights utilisateurs et ces données probantes devant les décideurs (« 7% seulement utilisent telle feature… ») : cela parle leur langage. On peut alors soit améliorer la rétention/adoption, soit simplement tuer les fonctionnalités inutiles — celles qui entravent la proposition de valeur centrale (notamment en B2B, où l’on veut vite devenir une “plateforme”… alors qu’il vaudrait mieux renforcer le cœur).
Andrea Saez : Je crois que Pendo a révélé dans une étude que 80% des fonctionnalités ne sont pas utilisées.
Hannah Clark : Incroyable.
Belle transition vers notre dernière partie : « On est en mode usine, que faire ? » Beaucoup nous écoutent car ils pensent être dans une feature factory, ou qu’ils s’en approchent. Si changer ce modèle semble impossible à court terme, quelles actions concrètes un leader peut-il mettre en place pour revenir vers une approche plus axée sur la valeur ?
Aakash Gupta : Si vous êtes le leader (VP produit, CPO…), il vous incombe de relever et pointer tous les problèmes de l’organisation — c’est votre job. Dont celui de la feature factory, qui est un problème assez évident et accepté. Il faut faire le point : quelle stratégie l’an passé ? Combien de fonctionnalités promises, combien ont réellement réussi ? Souvent, 75% échouent. Veut-on continuer ainsi ? Sinon, quelles actions mettre en place pour changer ? Parlez le langage des parties prenantes, montrez comment vos constats s’alignent sur leurs intérêts.
Parfois, cependant, ce sont les fondateurs/direction générale qui imposent leur volonté. Il faut alors envisager de « jouer aux échecs avec sa carrière » et partir.
Andrea Saez : J’allais dire la même chose : vous pouvez être le meilleur CPO ou VP produit si vous n’avez pas le soutien du CEO et du C-level, vous n’irez nulle part. L’alignement doit venir d’en haut. Beaucoup de fonctionnalités sont créées sans se baser sur des comportements utilisateurs scalables et récurrents, pourtant essentiels. Il faut penser à la valeur pour l’utilisateur, à la résolution de leurs vrais problèmes… et aussi se poser la question de l’éthique (comment cela impacte-t-il leurs flux de travail ?).
Paweł Huryn : Je confirme. Mais même sans l’influence d’un VP, un PM ou une équipe produit peut agir à son échelle. Je l’ai vécu au sein de BC (centre de ressources de 30+ banques danoises) : notre initiative a su sortir du framework SAFE en démontrant, chiffres à l’appui, les échecs précédents, puis en menant une « expérience » agile hors du process lourd imposé. On a prouvé la valeur par les résultats, même si l’organisation dans son ensemble n’a pas bougé.
Hannah Clark : Merci Paweł, le point de vue de ceux qui ont moins de poids dans l’orga est précieux, beaucoup d’auditeurs doivent se reconnaitre.
Paweł Huryn : On peut aussi, au sein de son équipe, prendre des initiatives : ne pas tout attendre d’en haut, mais collaborer avec les designers, brainstormer avec les devs, aller parler aux clients ensemble…
Andrea Saez : Je veux souligner la difficulté de ce type de transformation, comme Paweł l’a mentionné. C’est un travail difficile, éreintant pour la santé mentale, mais ceux qui y parviennent en tirent beaucoup d’enseignements.
Hannah Clark : Oui, c’est une trajectoire qui forge l’expérience, quelle que soit la suite.
Si vous voulez suivre nos intervenants, sachez qu’ils sont de formidables penseurs du produit. Le livre d’Andrea, « The Product Momentum Gap », est dispo sur Amazon, la newsletter d’Aakash « Product Growth Newsletter » est un must. Et la newsletter de Paweł, Product Compass. Abonnez-vous : il y a du contenu tout le temps !
Passons donc à la session Q&R, les questions du public.
Première question d’Aqueda : comment passer de la feature factory à la création continue de valeur utilisateur et business ? Apparemment, la valeur client s’efface souvent au profit du profit rapide. Andrea, un résumé de ton livre ?
Andrea Saez : C’est littéralement ça. Il s’agit de rassembler stratégie produit et valeur client : comment l’identifier, la suivre, l’intégrer à l’équipe. On a un template, « product VCP » (plan de création de valeur produit), qui doit impérativement impliquer toutes les parties prenantes (sales, customer success, support) en atelier de co-construction pour s’entendre sur ce que « valeur » veut dire — avant de la délivrer.
Hannah Clark : Pour un avant-goût, le podcast d’il y a un an (Product Manager Podcast) abordait justement le sujet de la façon dont les leaders produit freinent involontairement la croissance.
Question suivante de Parker : quels outils/méthodes utilisez-vous pour susciter des discussions stratégiques et l’alignement autour d’un objectif commun de produit ? Qu’est-ce qui fonctionne le mieux ?
Aakash Gupta : Pour obtenir de l’alignement autour d’un objectif, il ne faut pas plaquer une solution toute faite, mais engager l’équipe dans une démarche collective : faire appel à un analyste externe reconnu, approfondir ensemble l’analyse, brainstormer sur les métriques à viser, peser les pour et contre de chaque option avec toutes les parties (PMs, designers, ingénieurs). Cela prend plus de temps, mais permet un meilleur engagement collectif.
Hannah Clark : Merci pour ce process très concret, Aakash.
Question suivante : Mikayla. Nous avons une refonte demandée à la fois par le business et l’UX. On veut bien comprendre les parcours, mais “feature factory” oblige — c’est décousu ; le PM veut aller vite. Comment s’en sortir ?
Paweł Huryn : Ici, le PM pousse des fonctions sans validation. J’essaierai de remonter au problème visé — et de vérifier qu’il s’aligne avec la stratégie et la vision de l’entreprise. D’autres membres de l’équipe peuvent chercher des incohérences entre les données, les analyses et ce qu’on construit. Il y a forcément des hypothèses sous-jacentes à challenger.
Andrea Saez : Je suis d’accord. Deux questions magiques : quel problème essayons-nous de résoudre, et pourquoi ? Et pour qui ? Un simple « peux-tu m’expliquer la logique et le processus décisionnel ? » peut aider à guider l’équipe vers plus de réflexion.
Hannah Clark : Prendre l’équipe à témoin, c’est une bonne tactique.
Question de Brent : en théorie, une entreprise devrait-elle devenir moins feature factory avec la maturité, ou ce modèle sévit-il à toutes les étapes ?
Andrea Saez : Hannah, ton point de vue ?
Hannah Clark : En dehors du secteur, mais j’aurais tendance à penser qu’au début une entreprise devrait être le moins feature factory possible, avec une mission claire et une cible. La dérive vers l’usine vient souvent avec le temps, quand il faut survivre. Mais c’est peut-être naïf ? Fact-check ?
Aakash Gupta : À mon avis, la répartition est similaire à chaque étape : parfois, quand on démarre, il s’agit juste de copier un concurrent — c’est déjà un feature factory. Chez les grands comme Meta, certains PM sont autonomes. Mais dans toutes les entreprises, de la série A au géant, le problème existe à toutes les tailles… Ce qui compte, c’est d’identifier ce qui nuit concrètement à la valeur (notamment si le rapport salaire/création de valeur n’est pas là).
Hannah Clark : Sahi demande : quels atouts un PM disposant d’une double expertise business/tech apporte-t-il, versus un PM seulement technique, dans la conception produit ?
Andrea Saez : Pour moi, une PM purement technique manque souvent de sens business. Or, à la fin, on construit pour vendre. Avoir cette conscience de l’impact business et de la cible façonne directement les décisions. Par exemple : « comment allons-nous vendre cette fonctionnalité ? » devrait être la première question. Si on est business/tech, on a cette logique ; sinon, parfois, ce n’est pas réfléchi.
Hannah Clark : Quelqu’un souhaite compléter ?
Aakash Gupta : Pour moi, il s’agit de jouer sur ses forces. Si on a une sensibilité business, on impacte le modèle de croissance, on mesure les résultats, on conçoit les features en ce sens — inutile de s’inquiéter des profils techniques, c’est à eux d’apprendre la partie business !
Andrea Saez : 100% d’accord.
Hannah Clark : Todd : Paweł, quand transformer les insights en backlog ? Notre backlog ressemble à l’entrepôt d’une feature factory. Faut-il archiver les éléments de plus de 12 mois ?
Paweł Huryn : Je n’ai jamais dit d’accumuler tous les insights, mais de les diversifier (clients, analystiques, parties prenantes, études, etc.). Dans l’organisation du backlog, j’évite d’y placer prématurément des user stories ou features. Je préfère finir la phase de discovery, tester les hypothèses, puis seulement intégrer au backlog de livraison. On peut avoir deux backlogs (un, typiquement sur Miro ou équivalent, pour les besoins et idées ; l’autre, pour le dev). Quant à l’archivage : mieux vaut régulièrement nettoyer, car un backlog de 800 éléments, ça n’est pas gérable. Ce qui est important refera surface.
Hannah Clark : Merci à tous de votre participation et surtout, un immense merci à nos intervenants — Aakash, Andrea, Paweł. C’était une session très enrichissante et instructive !
Pour plus de conseils, guides pratiques et revues d’outils, abonnez-vous à notre newsletter sur theproductmanager.com/subscribe. Retrouvez toutes nos conversations en podcast sur la plateforme de votre choix.
