Prenons une scale-up qui vend un logiciel de paie aux PME et qui supprime l’étape d’import des salariés de son onboarding. L’activation à sept jours passe de 38 % à 46 %, l’équipe Growth présente le chiffre en revue du vendredi, et personne ne le conteste. Trois mois plus tard, les chargés de compte constatent que les clients arrivés sans import résilient bien plus souvent : sans leurs salariés dans l’outil, ils n’ont jamais lancé de vraie paie.
Personne n’a mal travaillé. Growth a atteint son objectif, Product n’a pas été consulté parce que rien ne l’exigeait, et la North Star de l’entreprise, le nombre de fiches de paie émises chaque mois, ne figurait dans aucun critère du test. Le problème est structurel : qui décide de l’onboarding, quelle métrique arbitre, à quel moment Product intervient.
Tant que ces trois réponses ne sont pas écrites, la friction entre les deux équipes devient le fonctionnement normal de l’entreprise. Et plus un produit dépend des données, de l’IA et d’itérations rapides, plus cette interface pèse sur le résultat.
Le conflit naît d’un chevauchement que personne ne gouverne
On entend souvent que Product crée la valeur et que Growth se contente de la diffuser. Dans un produit numérique, c’est faux. Growth travaille au cœur de l’expérience : premiers pas dans l’outil, écrans de paiement, relances, offres. Product ne peut pas non plus ignorer l’entonnoir. L’image du produit dépend aussi du temps qu’il faut à l’utilisateur pour en tirer quelque chose et comprendre l’offre. Les deux rôles se recouvrent. C’est pour cela qu’il faut organiser leur frontière.
Les deux métiers n’ont pas la même origine. Le Product Management vient de la stratégie, des besoins des utilisateurs et du travail avec les développeurs. Growth vient du marketing à la performance : on mesure, on teste, on va vite. Ces façons de penser ne s’opposent pas. Mais elles ne s’accordent pas toutes seules, et quand l’entreprise grandit, quatre tensions reviennent.
La première : qui est responsable de l’activation, de l’onboarding, des tests de rétention ? Dans une entreprise peu structurée, la réponse change selon la personne à qui l’on pose la question. La deuxième tient au rythme. Product pense en années et aux dégâts que l’on paiera plus tard, Growth pense en semaines. La troisième oppose la vitesse des tests à la stabilité technique et à la qualité de l’expérience.
La quatrième, la plus coûteuse, concerne les métriques : Growth suit le CAC, l’activation et les gains incrémentaux des tests, Product la North Star, l’adoption des fonctionnalités et la réussite des tâches. Sans cadre commun, chaque équipe produit sa propre lecture de la réalité. L’éditeur de paie en a eu deux pendant trois mois.
Product porte la promesse, Growth en accélère la découverte
Supprimer le recouvrement serait illusoire. Une organisation saine le rend gouvernable, et le modèle le plus robuste pour y parvenir reste souvent un fonctionnement en double piste (dual-track) Product-Growth : deux types de responsabilité, une coordination très serrée.
L’équipe Produit garde le cœur de l’expérience, les choix de fonctionnalités et la vision à long terme. Elle répond de ce qui donne envie d’utiliser le produit, de le garder et de le recommander. L’équipe Growth s’occupe de l’entonnoir. Elle teste vite pour attirer, activer, garder et faire payer plus d’utilisateurs. Elle amplifie la stratégie produit sans la remplacer.
Ce modèle évite de tout fusionner comme de tout séparer. Il protège de deux dérives. Dans la première, Growth reste en marge : on le consulte trop tard et il ne peut rien changer aux parcours importants. Dans la seconde, Growth agit seul et améliore ses propres chiffres sans se soucier du produit, de la dette technique ou de la cohérence de l’expérience. La suppression de l’import relève de la seconde : une décision sur le cœur de la promesse, traitée comme un simple test de conversion.
Le calcul d’une activation gagnée trop vite
Le calcul est illustratif et se fait en euros HT, puisque les clients sont des entreprises qui récupèrent la TVA. L’abonnement vaut 49 € HT par mois (58,80 € TTC avec la TVA à 20 %). Avec une marge brute de 80 %, chaque client rapporte 39,20 € de contribution mensuelle. Le coût d’acquisition d’un client payant s’élève à 450 € HT, et le délai de récupération de ce coût vaut 450 / 39,20, soit environ 11,5 mois. Presque un an d’abonnement sert donc seulement à rembourser l’acquisition : tout ce qui raccourcit la vie du client frappe directement la rentabilité.
Sur 1 000 inscriptions par mois, 380 clients s’activaient avant le test, tous après avoir importé leurs salariés. Avec la nouvelle version, 460 s’activent, mais la moitié a sauté l’import. Supposons une résiliation mensuelle de 2 % pour les clients avec import, soit une durée de vie moyenne de 50 mois, et de 8 % pour les autres, soit 12,5 mois. La valeur de la cohorte se calcule alors ainsi :
- avant : 380 × 39,20 × 50 = 744 800 € de contribution ;
- après : 230 × 39,20 × 50 + 230 × 39,20 × 12,5 = 450 800 + 112 700 = 563 500 €.
L’activation a progressé de 21 %, la valeur de la cohorte a reculé d’environ 24 %. Les clients sans import vivent à peine plus longtemps que le délai de récupération de leur CAC : ils remboursent leur acquisition et disparaissent. Le test n’avait pourtant rien de faux. Il mesurait la bonne chose au mauvais étage.
La règle qui en découle tient en une phrase. Un test qui touche une étape de la promesse (import, configuration, première paie) se juge sur un indicateur de valeur réalisée, ici la première paie émise, et sur la résiliation à 90 jours d’une cohorte témoin, pas sur l’activation à J7.
Une hiérarchie de métriques tranche avant que le conflit n’éclate
Encore faut-il que les deux équipes mesurent le succès avec la même règle. Beaucoup d’entreprises pensent qu’un tableau de bord commun suffit. Sans cadre de lecture hiérarchisé, chacun continue pourtant à défendre sa propre version du succès devant les mêmes courbes.
Au sommet de la hiérarchie se trouve la North Star Metric, la meilleure approximation de la valeur réellement créée pour l’utilisateur : pour un logiciel de paie, des fiches émises, pas des connexions. En dessous viennent les grands leviers de croissance : acquisition, activation, rétention et monétisation. Puis les métriques produit plus locales : adoption des fonctionnalités, friction sur certaines étapes, réussite des tâches, satisfaction, profondeur d’usage. À la base, les métriques expérimentales : gain incrémental, taux de clic, taux de complétion, variations de conversion.
Cette hiérarchie a deux effets. Elle empêche Growth d’optimiser un signal local qui détériore la valeur globale, et elle empêche Product d’ignorer un levier de croissance sous prétexte qu’il paraît tactique. Elle donne aussi une règle de lecture : une victoire au dernier étage ne compte que si aucun étage supérieur ne recule dans la fenêtre convenue. Les conflits baissent nettement, parce qu’on discute de la contribution de chaque levier au lieu d’opposer deux récits.
Les objectifs trimestriels en sont la traduction la plus simple, à condition que Growth et Product partagent un même objectif au lieu d’en juxtaposer deux. Ici, l’objectif commun porte sur les paies émises, et les résultats clés de Growth (activation avec import) comme ceux de Product (délai de première paie) en découlent. Un test qui fait progresser l’un en dégradant l’autre se voit dès la revue trimestrielle.
Un seul système d’expérimentation, sinon deux vérités
Chaque équipe ne peut pas tester dans son coin. Il faut des règles communes : une même façon d’écrire une hypothèse, de choisir les tests, de lire les statistiques, de vérifier et de déployer. Il faut aussi un registre des décisions et une base où l’on garde ce que l’on a appris. Pour la priorisation, beaucoup d’équipes partent de RICE, une grille née chez Intercom qui note la portée, l’impact, la confiance et l’effort de chaque idée. La grille compte moins que le fait que Growth et Product notent avec la même. Sans ce socle, les équipes lancent beaucoup de tests et apprennent mal.
Growth porte naturellement le rythme. Product doit pourtant rester co-garant du système, pour trois raisons. De nombreux tests touchent directement l’expérience centrale. Un test en apparence cosmétique engage une décision sur la manière d’exposer la valeur ou de structurer un parcours. Et beaucoup d’expériences ont des effets techniques et d’expérience qui dépassent leur objectif immédiat, comme l’import l’a montré.
Ce socle sert aussi à lire les échecs, qui sont la majorité. La plupart des idées testées, même bien argumentées, ne déplacent pas la métrique visée ou la font reculer. Une équipe qui lance vingt tests par trimestre recevra donc surtout des résultats neutres ou négatifs, et c’est leur lecture qui fait la qualité du programme.
Si personne n’a fixé à l’avance ce qu’un résultat neutre signifie, chaque équipe l’interprète à sa façon. Un outil d’analyse expérimentale commun homogénéise la lecture des tests A/B : le jugement reste humain, mais il s’exerce dans un cadre partagé.
Écrire qui tranche coûte moins cher qu’un test bloqué
Une large part des tensions entre PM et Growth tient moins à des désaccords de fond qu’à une incertitude : qui tranche en dernier ressort ? Qui décide de l’expérience d’onboarding, qui peut lancer un test d’activation, qui arbitre un paywall, qui fixe la logique de prix et qui se contente de la valider ? Quand ces questions restent implicites, chaque interaction devient une négociation politique, et un test bloqué faute d’arbitre coûte souvent plus cher que le désaccord qu’il cache.
D’où l’intérêt d’une matrice des droits de décision. Même sous une forme simple, elle oblige à expliciter qui décide, qui est consulté et qui exécute sur les domaines critiques. Dans bien des cas, l’expérience principale d’onboarding relève d’une décision produit, Growth étant consulté et chargé de certaines variantes. Les expériences d’activation peuvent être pilotées par Growth, avec une validation produit sur les effets systémiques : c’est la case qui manquait dans le cas de l’import.
Le paywall et l’abonnement relèvent souvent d’une responsabilité partagée. Le prix demande un pilotage plus stratégique par Product, avec validation Growth et alignement commercial.
La matrice ne doit pas ajouter une validation à chaque test. Elle évite au contraire de renégocier en permanence les mêmes frontières, et elle protège les deux fonctions : Growth garde sa capacité à expérimenter sans être bloqué, Product sa responsabilité sur la cohérence du système sans être court-circuité. Pour les cas qu’elle ne couvre pas, une règle d’escalade suffit : le désaccord monte au responsable commun lors de la revue hebdomadaire suivante, jamais plus haut.
Les rôles se dessinent alors plus nettement. Le Product Manager porte la stratégie, la proposition de valeur et l’architecture de l’expérience ; il travaille avec l’ingénierie sur la cohérence et la qualité, et reste le gardien de la logique produit quand une optimisation locale menace l’ensemble.
Le Growth Product Manager porte le rendement de l’entonnoir et le backlog expérimental, avec le design, la data, l’ingénierie et le marketing. Exécuter des tests ne lui suffit pas : il doit raisonner en délai de récupération du CAC, en CLV et en effets de cohorte, exactement le calcul qui aurait arrêté la suppression de l’import.
Autour de ce binôme, les Growth Engineers construisent les variantes, le suivi des événements et les interrupteurs de fonctionnalités (feature flags). Les data scientists et analystes découpent les publics et vérifient que le gain vient bien du test. Le design garde l’expérience cohérente malgré le rythme. Le marketing et l’équipe relation client relient acquisition, CRM et rétention.
Quatre structures, quatre prix à payer
Le bon design dépend du stade de maturité, et un organigramme copié sur une entreprise admirée vieillit mal sans son contexte. Dans une organisation intermédiaire, intégrer la compétence Growth dans les squads Produit fonctionne souvent : chaque squad acquiert une sensibilité growth, et cette logique ne devient pas un service externe. Le prix à payer est la duplication et l’hétérogénéité des pratiques, d’où la nécessité d’une coordination centrale forte.
Dans une structure plus avancée, une équipe Growth centrale et complète (full-stack) peut industrialiser l’expérimentation, porter les standards et opérer des boucles de croissance à l’échelle. Elle exige en revanche des interfaces beaucoup plus claires avec Product, faute de quoi elle est vécue comme une structure parallèle.
Le modèle Product-Led Growth hybride reste souvent le plus robuste en SaaS self-serve : des spécialistes Growth embarqués dans les squads, et une fonction centrale qui fixe les standards, partage les apprentissages et tient la discipline expérimentale. Enfin, certaines entreprises organisent des squads de mission autour de l’activation, de la rétention ou de la monétisation. Ce choix crée une responsabilité partagée par résultat, mais il demande des métriques stables et une gouvernance mûre.
Quelle structure choisir : arbre de décision
- Si l’entreprise est en phase d’amorçage et se concentre sur l’activation et les premières boucles : rôle hybride PM/Growth, métriques simples, pas encore de fonction Growth séparée.
- Sinon, si le produit est un SaaS self-serve et que l’expérimentation doit rester proche de l’expérience : PLG hybride, avec des spécialistes Growth embarqués dans les squads et une fonction centrale qui fixe les standards.
- Sinon, si le besoin dominant est d’industrialiser l’expérimentation et de porter des standards communs : Growth central full-stack, à condition d’écrire des interfaces claires avec Product.
- Sinon, si l’organisation est mûre en gouvernance et pilote des objectifs stables (activation, rétention, monétisation) : squads de mission en responsabilité partagée Product-Growth.
Règle transverse : plus la structure éloigne Growth des squads produit, plus les droits de décision et les métriques de garde doivent être écrits.
Reste une question de fond : faut-il seulement une équipe Growth ? Si chaque PM porte les métriques de croissance de son périmètre, la frontière disparaît et le conflit avec elle. Avec deux ou trois squads, c’est souvent la meilleure option, car coordonner une fonction de plus coûte plus qu’elle ne rapporte. Le calcul change quand plusieurs squads touchent le même entonnoir (inscription, onboarding, paiement) sans que personne ne le voie en entier. L’éditeur de paie est dans ce cas : l’équipe qui a supprimé l’import ne voyait pas la résiliation, et l’équipe qui voyait la résiliation n’avait pas été consultée.
Les rituels font exister l’organigramme
Tout ce design reste théorique tant qu’il n’entre pas dans l’agenda. Les équipes qui coopèrent bien ont presque toujours les mêmes rendez-vous. Une revue de l’entonnoir d’une demi-heure chaque semaine. Une planification commune des tests toutes les deux semaines. Un point stratégique chaque mois, un recalage des métriques chaque trimestre, et un bilan après chaque test qui a changé une décision. La revue hebdomadaire montre les signaux tant qu’ils sont frais. Le bilan transforme un résultat en leçon, au lieu d’une ligne de plus dans un rapport.
Voici comment se déroule une expérience. Un PM repère un point de blocage dans l’onboarding. Le Growth PM en tire des hypothèses à tester. Le Growth Engineer construit les variantes. L’équipe data prépare la mesure et fixe, avant le lancement, la façon de lire le résultat. Le PM vérifie l’impact sur l’expérience, la conformité et la technique. Puis le test est lancé, suivi et tranché ensemble.
Cette séquence réduit la friction parce qu’elle transforme la collaboration en procédure standard. Pour l’import, l’avant-dernière étape aurait suffi : un PM qui valide les contraintes d’expérience aurait demandé ce que devient un client sans salariés dans l’outil.
Dans une boucle de croissance, l’optimisation voyage loin
Dans une boucle de croissance, ce qui sort d’une étape alimente la suivante. L’utilisateur bien activé revient plus souvent, celui qui revient en recommande d’autres, et ces nouveaux venus arrivent avec une promesse que l’onboarding doit tenir. C’est là qu’une optimisation locale voyage le plus loin.
Dans une boucle d’acquisition, Product définit la proposition de valeur que Growth aide à distribuer. Dans une boucle d’activation, Growth réduit la friction et Product garantit que le chemin mène bien à la valeur réelle. Dans une boucle de rétention, Product construit les raisons de revenir, Growth optimise les déclencheurs, le moment et les messages. Dans une boucle de monétisation, Product travaille le prix et l’offre, Growth valide la disposition à payer et l’effet sur l’ARPU.
Les deux fonctions interviennent donc à des moments différents sur une même mécanique, sans relais linéaire de l’une à l’autre. Le design organisationnel doit dire, pour chaque boucle, qui conçoit et qui optimise. Le cas le plus courant reste le paywall plus insistant qui fait monter la conversion du mois et laisse la facture à l’étape de rétention, là où aucune métrique de garde ne regardait.
Pour un logiciel de paie, la boucle passe aussi par les cabinets d’expertise comptable qui recommandent l’outil à leurs clients : un client qui n’a jamais lancé de paie ne sera jamais cité en exemple. D’où une règle simple : chaque expérience menée sur une étape de la boucle porte au moins une métrique de garde sur l’étape suivante.
Les symptômes disent quoi corriger en premier
Quand la responsabilité partagée est mal pensée, les symptômes se ressemblent d’une entreprise à l’autre, et chacun se vérifie en quelques minutes. Des KPI contradictoires sans hiérarchie commune se repèrent quand deux équipes présentent le même trimestre, l’une comme un succès, l’autre comme un échec. Un Growth qui expérimente à côté de la stratégie produit se repère à des gains de conversion absents de la rétention à 90 jours.
À l’inverse, certaines équipes Produit ralentissent l’expérimentation au nom de la qualité, faute de métriques de garde claires. La mauvaise volonté y est rarement pour quelque chose : si les risques acceptables, les zones de test et les conditions de déploiement ne sont pas définis, chaque expérience devient un débat de principe, et le délai entre hypothèse et lancement s’allonge de semaines en mois.
Le chevauchement des responsabilités se lit dans deux tests lancés en même temps sur le même écran. La faible gouvernance des tests, enfin, a le symptôme le plus facile à vérifier : personne ne sait dire ce qu’a appris le dernier test perdant.
On ne corrige pas tout en même temps, et l’ordre suit le stade de l’entreprise décrit dans l’arbre de décision. En phase d’amorçage, seuls les symptômes qui touchent l’onboarding et l’activation méritent une règle écrite. Au passage à l’échelle viennent les règles des tests et une séparation plus nette entre la recherche de ce qu’il faut construire (côté Produit) et l’exécution des tests (côté Growth).
Un signal indique que ce moment est venu : deux équipes ou plus lancent des tests sur le même entonnoir au cours du même mois. Des outils d’évaluation aident alors à cartographier les compétences disponibles et à repérer où se trouvent les écarts de maturité.
Dans une grande entreprise, le sujet change. Il faut écrire les droits de décision et créer des comités Growth communs à plusieurs équipes. Ce que l’on apprend sur la croissance doit nourrir les choix entre produits, sur six à huit trimestres. C’est aussi à ce stade que des outils de modélisation de scénarios soutiennent la planification de la croissance sur plusieurs années.
Une ligne de matrice suffit pour commencer
Tout se ramène à une règle d’arbitrage : Product décide de ce qui constitue la valeur, Growth décide de la manière la plus rapide de la faire découvrir, activer et étendre, et la North Star tranche quand les deux lectures divergent. Une entreprise qui n’arrive pas à appliquer cette règle à un cas récent, son dernier test d’onboarding ou de paywall, vient de trouver par où commencer. Si la réponse dépend de la personne interrogée, ce sont les droits de décision qu’il faut écrire ; si tout le monde s’accorde sur le décideur mais pas sur le résultat, c’est la hiérarchie de métriques qui manque.
Deux documents suffisent souvent à enclencher le mouvement : une hiérarchie de métriques partagée et une matrice de droits de décision que les deux équipes acceptent d’appliquer. Le signe que cela fonctionne est concret. Au trimestre suivant, les revues d’entonnoir portent sur ce que les expériences ont appris, et la question de savoir qui avait le droit de les lancer a disparu de l’ordre du jour. Les arbitrages qui remontaient jusqu’à la direction se règlent entre responsables, et la direction récupère du temps pour ce que la matrice ne couvre pas, comme l’entrée sur un nouveau marché.
Dans le cas de l’import, ce premier geste aurait tenu en une ligne de la matrice : l’import des salariés appartient à Product, et Growth ne le retire pas sans regarder la première paie émise.