Ownership produit : pourquoi personne ne sait qui décide quoi dans ton équipe
Par Julien Brionne — Senior PM Freelance
Le flou d'ownership est le symptôme n°1 des scale-ups en croissance. Comment le diagnostiquer, pourquoi il s'installe, et comment poser un cadre qui tient.
Pour comprendre la posture d'intervention, voir Mon approche.
Ton équipe produit livre. Les sprints tournent. Les features sortent.
Pourtant, chaque décision prend trois fois trop de temps. Une question simple — “qui est responsable du Help Center ?” — génère un thread Slack de 47 messages. Un bug critique en prod attend 4 heures parce que deux équipes pensent que c’est l’autre qui gère.
Le problème n’est pas la compétence de tes PMs. Le problème, c’est que personne ne sait qui est owner de quoi.
Le flou d'ownership, c'est le vrai frein.
Le flou d’ownership est le symptôme n°1 des équipes produit qui grandissent plus vite que leur organisation. Il ralentit chaque décision, génère du travail en double et transforme les PMs seniors en dispatchers. La solution n’est pas un nouvel organigramme. C’est une matrice de décision explicite, visible par toute l’entreprise, qui se pose en une semaine et se revoit chaque trimestre.
Le flou d'ownership ne se voit pas. Il se ressent.
Dans une startup de 15 personnes, l’ownership est implicite. Le fondateur tranche. Les PMs couvrent tout. Pas besoin de matrice de responsabilités : tout le monde sait qui fait quoi parce que tout le monde est dans la même pièce.
À 80 personnes, ça ne fonctionne plus.
L’ownership flou s’installe progressivement. Il s’infiltre quand l’entreprise grandit plus vite que son organisation. Et il se manifeste toujours de la même façon.
La décision fantôme. Un sujet important — refonte du backoffice, migration d’outil, changement de process — traine depuis des mois. Tout le monde en parle en réunion. Personne ne prend la décision. Parce que personne ne sait si c’est à lui de la prendre.
Le chevauchement silencieux. Deux PMs travaillent sur des périmètres qui se recoupent sans le savoir. L’un construit un workflow de ticketing dans l’admin. L’autre fait la même chose côté support. Quand ils s’en rendent compte, il y a 3 semaines de travail en double.
Le PM pompier. Un PM senior passe 60% de son temps à répondre à des questions qui ne devraient pas atterrir chez lui. Il est devenu le point de passage par défaut parce que personne d’autre n’a la réponse. Il ne fait plus de produit. Il fait du dispatching.
Pourquoi l'ownership disparait en croissance.
L’explication est structurelle. Pas humaine.
Quand une équipe produit passe de 2 à 8 PMs en 18 mois, les périmètres sont découpés à la hâte. Un PM arrive, on lui donne “le search”. Un autre prend “le checkout”. Un troisième hérite “des outils internes”.
Ces périmètres ont trois défauts récurrents.
Définis par feature, pas par outcome. “Le search” n’est pas un périmètre. C’est une fonctionnalité. Qui est owner de l’expérience de découverte produit ? Du taux de conversion entre la recherche et l’achat ? Personne. Parce que le périmètre s’arrête à la barre de recherche.
Les zones grises ne sont assignées à personne. Le backoffice, les outils ops, le care, la facturation, l’admin. Ces sujets n’ont pas de PM dédié. Ils vivent entre les équipes. Tout le monde y touche. Personne n’en est responsable. C’est un pattern que j’ai observé dans chacune des 4 scale-ups où je suis intervenu (Heetch, Back Market, Waalaxy, Wizville) : les outils internes et le care sont systématiquement les derniers sujets à recevoir un owner produit dédié.
Le découpage n'évolue pas avec la croissance. Le périmètre défini quand l’équipe comptait 3 PMs est le même à 8. Les responsabilités n’ont jamais été redistribuées. Les nouveaux arrivants ont hérité des morceaux restants, pas d’un périmètre pensé.
L’ownership n’est pas un organigramme. C’est une matrice de décision.
L'ownership se pose sur quatre dimensions.
La première erreur que font les Head of Product face au flou, c’est de redessiner l’organigramme. Nouvelle structure. Nouvelles squads. Nouveau Notion. Ça ne résout rien. Parce que l’organigramme dit qui reporte à qui. Il ne dit pas qui décide quoi.
Vision. Qui définit où on va sur 6 mois, quels problèmes on résout et dans quel ordre ?
Priorisation. Quand un sujet entre en conflit avec un autre, qui arbitre au quotidien ?
Point de contact stakeholders. Quand le Head of Ops a une question sur le workflow de remboursement, il appelle qui ?
Accountability du résultat. Si le taux de résolution first contact stagne, c’est dans l’assiette de qui ?
Comment poser l'ownership en pratique.
Le process que j’ai appliqué sur plusieurs missions repose sur trois étapes. Pas besoin de framework sophistiqué. Besoin de clarté.
Cartographier ce qui existe.
Prends une heure avec ton équipe. Pose deux questions.
La première : “si tu devais expliquer ton périmètre à un PM qui arrive lundi, tu dirais quoi ?”
La deuxième : “quel sujet produit n’est dans le périmètre de personne ?”
La première question révèle les chevauchements. Deux PMs vont décrire le même territoire avec des mots différents.
La deuxième question révèle les angles morts. Les sujets que personne ne porte. C’est là que les problèmes s’accumulent en silence : les outils internes, le care, le backoffice, les intégrations, la documentation.
Poser les périmètres par outcome, pas par feature.
Au lieu de “PM Search” et “PM Checkout”, pose “PM Discovery to Purchase” et “PM Post-Purchase Experience”. Le périmètre couvre un parcours utilisateur, pas un composant technique.
Ce recadrage force à répondre aux zones grises. Si un PM est owner du parcours post-achat, il est owner du remboursement, du retour, du contact support. Plus de flou.
Pour les sujets transverses (admin, backoffice, outils internes), deux options. Soit un PM dédié. Soit un ownership explicite attribué à un PM existant avec du temps alloué. La deuxième option fonctionne si le sujet est petit. Dès qu’il prend de l’ampleur, il faut un PM à temps plein.
Le care n’avait pas de PM. J’ai créé le Care Product Team from scratch. En 6 mois, l’efficacité Care a progressé de 8% et le NPS drivers est passé de 3.5 à 4.1.
Rendre l'ownership visible.
L’ownership qui vit dans la tête du Head of Product ne sert à rien. Il doit être accessible à toute l’entreprise.
Un document simple suffit. Pas un Notion de 40 pages. Un tableau avec trois colonnes : périmètre, PM owner, stakeholders principaux. Partagé à l’engineering, aux ops, au support, au management.
Le critère de succès : quand quelqu’un dans l’entreprise a une question produit, il sait qui contacter en moins de 30 secondes. Si ce n’est pas le cas, l’ownership n’est pas posé.
Ce que ça change concrètement.
Sur une mission que j’ai menée en 2023 dans une marketplace de 120 personnes, le résultat a été visible en 3 semaines.
Le temps moyen de décision sur les sujets transverses est passé de 5 jours à 2. Les PMs ont arrêté de se marcher dessus sur les sujets ops. L’engineering a arrêté de poser les mêmes questions à trois personnes différentes.
Le gain n’est pas spectaculaire sur le papier. Mais il est cumulatif. Chaque semaine, l’équipe récupère des heures de coordination inutile. Ces heures vont dans le produit. Dans la discovery. Dans l’exécution.
Trois erreurs à éviter.
Vouloir un cadre parfait du premier coup. L’ownership est un document vivant. Il évolue chaque trimestre. Poser une V1 imparfaite vaut mieux que chercher la V1 parfaite pendant 3 mois.
Confondre ownership et hiérarchie. Être owner d’un périmètre ne veut pas dire manager les gens qui y travaillent. Un PM IC est owner d’un périmètre stratégique sans avoir de report direct. L’ownership est une responsabilité sur le résultat, pas sur les personnes.
Ne pas recouper avec l'engineering. L’ownership produit qui ne s’aligne pas avec l’organisation engineering crée plus de friction qu’il n’en résout. Si un PM est owner du parcours post-achat mais que trois squads engineering y travaillent sans coordination, le problème change de forme. Il ne disparait pas.
Tu vis ça ? Voir ce que je fais concrètement.
Ce qu'il faut retenir.
Le flou d’ownership est le symptôme le plus courant de la croissance produit mal structurée. Il n’est pas causé par des PMs incompétents. Il est causé par une organisation qui n’a pas rattrapé sa propre croissance. La solution n’est pas un organigramme. C’est une matrice de décision claire, visible, et actualisée. Ça prend une semaine à poser. Et ça change la vitesse d’exécution de l’équipe pour les mois qui suivent.