On parle souvent d’onboarder un premier PM comme si le plus compliqué était de recruter la bonne personne.
Mais je crois que le vrai sujet il arrive juste après.
Quand il faut réussir à rassurer quelqu’un sur un rôle… alors même que l’organisation autour n’existe pas encore vraiment.
Parce qu’il y a un truc assez particulier dans les transformations.
Sur les slides, tout paraît toujours assez clair :
- les rôles,
- la gouvernance,
- les responsabilités,
- les rituels,
- les interactions.
Mais je sais ce que la réalité va apporter.
Beaucoup de choses ne se construiront qu'en avançant, certaines convictions tiendront et d'autres vont s'effondrer au premier contact avec le terrain. Parce qu’entre “imaginer une organisation produit” et “la faire vivre”, il y a un monde.
En ce moment, c’est exactement ce qu’on est en train de vivre. On déploie un pôle produit.…enfin “on construit” est probablement plus juste que “on déploie”.
Parce qu’il n’y a pas un modèle déjà prêt qu’on serait simplement en train d’appliquer. On propose des choses, qu'on devra ajuster. On doute parfois, voir souvent, et on avance quand même.On ne construit pas ce pôle produit dans le vide.
On essaye de faire émerger une nouvelle organisation… à l’intérieur d’une organisation qui existe déjà.Avec sa gouvernance, ses habitudes, ses rôles historiques, ses équilibres, ses façons de décider. Et surtout avec une organisation IT qui continue elle aussi d’avoir sa propre structure et sa propre logique de fonctionnement.
Du coup, le sujet n’est pas simplement “créer un pôle produit”. Le vrai sujet devient : comment faire coexister une nouvelle dynamique sans créer immédiatement une rupture impossible à absorber ?
Et je crois que c’est là qu’une transformation devient réellement intéressante.Parce qu’on ne peut pas toujours tout reconstruire.
Alors il faut parfois :
- adapter certains rôles,
- faire évoluer progressivement certaines responsabilités,
- créer des ponts plutôt que des silos,
- et accepter des zones hybrides pendant un temps.
Finalement, construire une organisation produit dans une entreprise existante, ce n’est pas juste ajouter une nouvelle équipe.
C’est réussir à faire évoluer tout un écosystème… sans casser ce qui permet déjà à l’entreprise de fonctionner.
Et au milieu de tout ça, il faut onboarder un premier PM. Pas juste lui expliquer un périmètre.
Mais lui demander de croire à quelque chose qui est encore en train de prendre forme.
Je trouve ça à la fois hyper intéressant… et très inconfortable.
Parce que je ne crois pas qu’on rassure quelqu’un en lui faisant croire que tout est déjà stabilisé.
Surtout quand ce n’est pas vrai. Je pense qu’on doit rassurer plutôt par la transparence, par le fait d’assumer les zones grises. Car on a besoin de personnes qui vont accepter ces zones grises avec nous.
Dans notre cas, on mise beaucoup sur un duo.
Quelqu’un avec une vraie expertise produits, les méthodes, le recul, la structuration, la capacité à challenger les fonctionnements existants.
Et en parallèle quelqu’un qui connaît déjà l’entreprise, le métier, l’écosystème, les contraintes, les sensibilités, les équilibres invisibles que tu ne comprends jamais vraiment en lisant un organigramme.
Et plus j’y réfléchis, plus je trouve ce modèle extrêmement fort.
Parce qu’une expertise produit seule peut parfois créer quelque chose de très propre… mais impossible à faire vivre dans l’organisation. Et à l’inverse, rester uniquement dans l’existant finit souvent par reproduire les mêmes fonctionnements avec un nouveau vocabulaire.. On connait tous le cdp devenu PO, le cycle de livraison transformé en sprint.
Le vrai sujet finalement, c’est probablement moins de choisir entre “transformation” et “adaptation”.
Et plus de trouver jusqu’où tu peux pousser le changement sans créer un modèle impossible à déployer.
Et ça me fait énormément penser aux POC.
Un POC qui fonctionne, c’est souvent assez simple.
- Petit collectif.
- Peu de dépendances.
- Beaucoup d’énergie.
- Des gens très alignés.
- Dans ce contexte, énormément de choses marchent.
Mais industrialiser… c’est une autre histoire.
Et on n’industrialise pas une organisation comme on industrialise du code, car l'humain vient ajouter une complexité énorme :
- les habitudes,
- les peurs,
- les egos,
- les niveaux de maturité,
- les histoires déjà vécues,
- les manières de communiquer,
- le savoir-faire,
- mais surtout le savoir-être.
Une méthode qui fonctionne parfaitement à 5 peut devenir ingérable à 50.
Un fonctionnement ultra fluide dans une petite équipe peut devenir impossible à maintenir dès que les dépendances augmentent.
Quelque chose qui fonctionne ailleurs peut virer à la catastrophe chez nous.
Et je crois que le mieux c'est d'accepter qu’au début, personne n’ait totalement la réponse. Même pas les gens qui construisent le cadre.
Au fond, onboarder le premier PM d’une organisation en construction, ce n’est pas intégrer quelqu’un dans un système déjà prêt.
C’est de réussir à lui dire :
“voilà ce qu’on essaye de construire,
voilà ce qu’on croit juste aujourd’hui,
voilà ce qui reste encore flou,
et voilà la place qu’on te laisse pour participer à construire la suite avec nous.”