Structurer une équipe produit en scale-up : par où commencer quand tout est urgent
Par Julien Brionne — Senior PM Freelance
Ownership flou, process bricolés, outils internes en ruine. Tout est urgent. Rien n'avance. Voici la séquence qui fonctionne pour poser une structure produit en 90 jours.
Pour comprendre la posture d'intervention, voir Mon approche.
Tu viens d’être nommé Head of Product. Ou tu es founder et tu portes encore la casquette produit à 80 personnes. Ou tu es CPO et tu as hérité d’une équipe qui a grandi sans toi.
Le constat est le même partout. L’ownership est flou. Les outils internes tiennent avec du scotch. Les PMs passent plus de temps en réunions qu’à réfléchir. L’engineering livre, mais personne ne sait mesurer l’impact. Tout semble urgent. Rien n’avance vraiment.
La tentation : tout attaquer en même temps. Refondre les rituels. Redessiner l’organigramme. Lancer un chantier backoffice. Recruter trois PMs. C’est la pire erreur possible.
Structurer une équipe produit, c'est une séquence. Pas un big bang.
Chaque scale-up qui grandit plus vite que son organisation produit finit avec les mêmes symptômes : ownership flou, coordination excessive, outils bricolés. La réponse n’est pas de tout refondre. C’est de poser les choses dans le bon ordre. D’abord comprendre ce qui casse. Ensuite poser qui décide quoi. Enfin installer les mécanismes de décision. 90 jours. Trois phases. Le reste vient après.
Vouloir tout fixer en même temps.
J’ai traversé 4 scale-ups (Heetch, Back Market, Waalaxy, Wizville). Le pattern est identique. Le nouveau Head of arrive, voit le chaos, et lance 5 chantiers en parallèle. Nouveaux rituels. Nouvelle roadmap. Nouveau framework de priorisation. Nouveau Notion. Nouveau tout.
En 3 mois, rien n’a bougé. L’équipe est fatiguée du changement. Les anciens process n’ont pas été remplacés, ils se sont empilés. Les PMs ont un rituel de plus, un template de plus, un canal Slack de plus. Et le problème de fond est intact.
Le problème de fond, c’est que personne ne sait quel problème résoudre en premier. Faute de diagnostic, on traite les symptômes visibles (trop de réunions, backlog chaotique, engineering frustrée) au lieu de la cause. La cause, c’est presque toujours la même : l’organisation a grandi plus vite que sa capacité à décider.
C’est l’illusion du mouvement : l’effort masque l’absence de décision. Et structurer sans avoir compris ce qui casse revient à construire un cadre autour du vide.
Structurer, c’est décider dans quel ordre on règle les problèmes. Pas les régler tous en même temps.
Écouter. Observer. Nommer.
Les trois premières semaines ne servent pas à changer quoi que ce soit. Elles servent à comprendre ce qui casse réellement. Pas ce que les gens disent qui casse. Ce qui casse.
La différence est importante. En one-on-one, le PM te dira “on a trop de réunions”. C’est un symptôme. La cause, c’est que personne ne tranche entre les réunions. Le Head of Ops te dira “le backoffice est nul”. C’est un symptôme. La cause, c’est que personne n’est owner du backoffice.
One-on-ones, pas réunions d'équipe. Rencontre chaque PM, chaque lead engineering, chaque stakeholder clé (ops, support, sales). Pose deux questions. La première : “quel sujet revient en boucle sans jamais être tranché ?”. La deuxième : “si tu pouvais changer une seule chose dans l’orga produit, ce serait quoi ?”. Les réponses se recoupent toujours. C’est là que se cache le vrai problème.
Shadow, pas audit. Assiste aux rituels existants sans les juger. Weekly produit, grooming, rétro, synchro cross-squad. Note ce qui se passe réellement. Qui parle. Qui décide. Qui attend. Combien de sujets sont “discutés” sans jamais être fermés. C’est le diagnostic le plus fiable qui existe.
Cartographie des zones mortes. Identifie les sujets sans owner. Pas les sujets assignés dans un Notion que personne ne lit. Les sujets réels que personne ne porte. Dans chaque scale-up où je suis intervenu, la liste est la même : outils internes, backoffice, care, intégrations, documentation. Ce sont les zones où la dette s’accumule en silence.
Chez Waalaxy, les 3 premières semaines m’ont permis d’identifier que le problème n’était pas la roadmap (qui était correcte sur le papier) mais le mode de fonctionnement. L’équipe livrait des features sans mesurer si elles changeaient quoi que ce soit. Le shift output vers outcome est parti de là. ARR de 7M à 8.5M.
Poser l'ownership. Point.
La phase 2 ne porte que sur un seul sujet : qui décide quoi.
Pas les rituels. Pas les outils. Pas la roadmap. L’ownership. Parce que tout le reste en découle. Si l’ownership est clair, les rituels se simplifient naturellement (plus besoin de se synchroniser quand tu sais qui tranche). Si l’ownership est flou, aucun rituel ne compensera.
J’ai détaillé la méthode complète dans l’article sur l’ownership produit. Voici ce qui compte dans le contexte d’une structuration globale.
Redécouper par outcome, pas par feature. Les périmètres “PM Search”, “PM Checkout”, “PM Dashboard” sont des découpages par composant technique. Ils créent des zones grises à chaque intersection. Découpe par parcours utilisateur ou par objectif business. “PM Discovery to Purchase”, “PM Post-Purchase Experience”, “PM Internal Operations”. Chaque zone grise disparait parce qu’elle appartient à un parcours.
Nommer les angles morts. Les sujets identifiés en phase 1 (outils internes, care, backoffice) reçoivent un owner explicite. Si tu n’as pas assez de PMs, un ownership partagé avec du temps alloué fonctionne temporairement. Mais un sujet sans owner reste un sujet sans décision. Le care chez Heetch n’avait pas de PM. J’ai créé le Care Product Team from scratch. C’est ce qui a produit les résultats les plus tangibles de ma carrière (+8% efficacité, NPS de 3.5 à 4.1).
Rendre l'ownership visible à toute l'entreprise. Un tableau. Trois colonnes. Périmètre, PM owner, stakeholders principaux. Partagé à l’engineering, aux ops, au support. Le test : n’importe qui dans l’entreprise sait qui contacter en 30 secondes pour un sujet produit donné. Si ce n’est pas le cas, l’ownership n’est pas posé. Il est écrit dans un doc que personne ne consulte.
Installer les mécanismes de décision.
L’ownership est posé. Chaque PM sait ce qu’il porte. Les stakeholders savent qui appeler. C’est maintenant que tu installes les mécanismes qui font que les décisions se prennent, tiennent, et ne reviennent pas en boucle.
Pas 15 rituels. Trois mécanismes.
Async par défaut, synchrone pour trancher.
Toute discussion qui relève de l’information ou de la proposition passe en écrit. Le synchrone est réservé à un seul usage : trancher quand il y a un désaccord. Si tout le monde est d’accord, pas besoin de réunion. On valide en async et on avance.
Le format d’écrit qui fonctionne : un one-pager par initiative. Le problème. L’hypothèse. Les métriques de succès. Les dépendances. Pas un PRD de 15 pages. Un document court qui force la clarté.
Résultat concret sur une mission récente : 6 rituels hebdomadaires supprimés sur 11 en 2 semaines. Les PMs ont récupéré 7 heures par semaine en moyenne.
Chaque réunion produit une décision écrite.
Pas de compte-rendu narratif. Trois colonnes : décision, owner, deadline. Si la réunion ne produit aucune décision, c’est qu’elle n’aurait pas dû avoir lieu.
Ce format change la culture en quelques semaines. Les gens viennent préparés. Les réunions durent 20 minutes au lieu de 45. Les décisions tiennent parce qu’elles sont écrites, assignées, et visibles.
Un rituel de friction, pas de synchronisation. Une fois par semaine. 30 minutes. Trois questions : “quel sujet est bloqué entre deux équipes ?”, “quel arbitrage attend une décision ?”, “qu’est-ce que les ops contournent cette semaine que le produit devrait résoudre ?”. Ce rituel expose les tensions au lieu de les masquer. C’est le mécanisme qui fait le lien entre Product, Ops et Engineering. Sans lui, le triptyque se casse en silence.
Chez Heetch (4 ans), j’ai structuré l’équipe produit care from scratch avec ces trois mécanismes. Chez Wizville (CPO), j’ai monté la fonction Product de zéro : hiring, rituels, discovery, delivery. Dans les deux cas, le séquençage était le même : comprendre, poser l’ownership, installer les mécanismes. Pas l’inverse.
Les 90 jours ne résolvent pas tout.
En 90 jours, tu poses le socle. L’ownership est clair. Les mécanismes de décision fonctionnent. L’équipe sait qui tranche quoi et comment.
Ce que tu n’as pas encore résolu :
Le backoffice legacy. Il tient encore avec du scotch. Mais maintenant il a un owner. La décision patcher vs refondre viendra dans le trimestre suivant. Tu as les éléments pour trancher.
La stratégie produit à 12 mois. Les 90 premiers jours ne sont pas le moment de réécrire la vision. C’est le moment de poser les conditions pour que la vision se traduise en décisions. Une fois le cadre posé, tu as l’espace pour penser stratégie.
Le recrutement. Tu sais maintenant quels périmètres sont sous-staffés. Tu sais quel profil il te faut : mid-level pour dépiler un backlog clair, ou senior pour porter un scope structurant. Le recrutement devient une décision informée, pas un réflexe.
Quatre erreurs que je vois dans chaque scale-up.
Commencer par les rituels. “On va mettre en place un Product Review bi-mensuel.” Sans ownership clair, le Product Review devient une énième réunion où personne ne tranche. Les rituels sont les derniers à poser, pas les premiers.
Importer un framework sans adapter. Scrum, Shape Up, dual-track, OKRs. Chacun a sa valeur. Aucun ne fonctionne en copier-coller. Le framework est un outil de lecture, pas une recette. Si tu plaques Shape Up sur une équipe qui n’a pas d’ownership clair, tu auras du Shape Up avec un ownership flou.
Restructurer l'organigramme. Nouvelles squads, nouveaux noms, nouveau Notion. L’organigramme dit qui reporte à qui. Il ne dit pas qui décide quoi. Changer l’organigramme sans poser l’ownership crée un chaos neuf. Pas de la clarté.
Attendre le cadre parfait pour agir. La V1 est toujours imparfaite. Un ownership posé en une semaine avec des zones grises identifiées vaut mieux qu’un ownership parfait jamais finalisé. Le cadre se revoit chaque trimestre. C’est un document vivant, pas une constitution.
Tu vis ça ? Voir ce que je fais concrètement. Ou les missions passées.
Un scope produit qui coince ? On en parle.
La séquence avant la structure.
Structurer une équipe produit en scale-up ne commence pas par un framework, un organigramme ou un nouveau rituel. Ça commence par comprendre ce qui casse. Puis poser qui décide quoi. Puis installer les mécanismes qui font que les décisions tiennent. 90 jours. Trois phases. Le bon ordre compte plus que la bonne méthode.