19 conversations
Le PM qui code : partout dans les discussions, presque nulle part en prod
C'est le sujet dont on m'a le plus parlé. Mais quand on regarde ce qui part vraiment en prod, ça se limite aux micro-sujets : un wording, une typo, un petit bug. En session, le consensus était net : oui pour les petits changements bien cadrés, non pour les vraies features.
Ce qui coince, c'est rarement la technique. Ce sont les devs, qui refusent l'accès au code ou ne veulent pas relire le travail d'un PM. C'est le temps, quand tout le monde est déjà surchargé. Et c'est la qualité : des protos qui grossissent jusqu'à devenir impossibles à reprendre par les devs, des PR trop grosses qui finissent par faire restreindre l'usage du code aux changements d'interface. Ce qui marche en revanche, c'est le PM qui interroge le code ou la base de données pour comprendre, pas pour livrer.
Tout le monde n'est pas d'accord. Certains Head of ont livré seuls des features de bout en bout en prod, et croient à un seul métier qui mélange design, produit et dev. D'autres préfèrent des devs avec une vraie sensibilité produit plutôt que des PM qui codent.
« Des PM qui passent la moitié de leur journée à pousser du code ? Honnêtement, je n'y crois pas du tout. »
« Les devs m'ont dit : de toute façon, ton code, on ne l'intégrera jamais en prod. »
14 conversations
Les orgas se resserrent, et les ratios bougent dans tous les sens
Deux mouvements en même temps. D'un côté, des équipes plus petites : des squads de 8 qu'on redécoupe en 4 ou 5, et parfois moins à terme. Des équipes produit et design qui se réduisent nettement.
De l'autre, c'est souvent le produit qu'on coupe en premier, pas les devs. Le rôle de PO disparaît dans certaines boîtes, au profit de PM seniors qui font la discovery, les specs et le lien avec la tech. Il apparaît aussi dans des listes de métiers exposés à l'IA. On voit aussi passer des projets de réorg à trois rôles : le PM qui build, l'ingénieur qui relit, le responsable data.
Personne n'a de modèle cible, et certains rappellent que le fameux ratio d'un PM pour 4 ou 5 devs n'a jamais vraiment existé.
« Aujourd'hui, c'est le produit qui est touché avant les devs. »
« Ma vraie théorie, c'est qu'il n'y aura aucun modèle standard commun à toutes les boîtes. »
12 conversations
Chacun va plus vite, l'orga non
Quand on mesure ce qui sort vraiment, plusieurs ne voient aucun impact sur le volume livré, alors que les équipes sont équipées. Le découpage des équipes n'a pas changé, chaque métier avance dans son coin, et la chaîne de déploiement n'est pas faite pour un flux accéléré.
Trois mécanismes reviennent. Les outils restent personnels : chacun a son assistant pour ses specs ou sa discovery, et personne ne m'a cité d'outil partagé à l'échelle d'une boîte. Chacun a son propre transcript de réunion, donc il n'y a plus de compte rendu commun, et chacun repart avec sa version. Et les vrais goulots sont ailleurs : la validation, la relecture, la décision.
Il y a des gains, mais ponctuels : des chantiers bouclés en une fraction du temps prévu, des phases de test fortement raccourcies. Ça marche aussi très bien sur un produit neuf ou un refacto.
« Je ne vois aucun impact. »
« Chaque individu s'améliore, donc la vélocité aussi. Mais le total, lui, ne bouge pas. »
12 conversations
Pour faire monter les équipes sur l'IA, l'injonction ne marche pas
Ce qui échoue se ressemble partout. Un objectif du type « utiliser l'IA », auquel tout le monde répond oui. Le discours « utilisez l'IA », qui braque les gens. Les formations génériques sur un outil. Les licences distribuées sans accompagnement.
Ce qui marche part du concret : les irritants de l'équipe, un objectif précis, un accompagnement en tête-à-tête par le manager, des champions ou un petit groupe de pairs qui vient te chercher. Au final, seule une petite minorité l'utilise vraiment à fond.
Les avis divergent sur la formation. Pour l'un, aucune formation n'a jamais changé l'approche de quelqu'un. Pour d'autres, certains PM ont eu un vrai déclic en s'y mettant.
« Au début, l'objectif c'était d'utiliser l'IA. Ça ne marche pas. »
10 conversations
Le produit devient le goulot : on n'arrive plus à nourrir les devs
Les devs ont adopté l'IA plus vite que le produit, et le produit ne fournit plus assez de sujets prêts à développer. Des PM passent trop de temps en recette, et certaines équipes en ont fait une règle : le PM ne code pas, il nourrit les devs. Certains envisagent même de retirer des devs, faute de pouvoir les alimenter.
Le goulot n'est pas que la spec : c'est aussi la validation interne, les décisions, la recette. Et il n'est pas au même endroit partout. Certains vivent l'inverse : leur équipe prototype si vite qu'elle sature les devs. Ailleurs, c'est la relecture du code qui coince.
« Les devs bossent plus vite avec l'IA, donc il faut leur donner du travail. »
10 conversations
La vitesse fait sauter l'étape du problème
Le même récit revient. Avec Claude Design, toute l'équipe projet, devs compris, propose son proto. On itère sur ce que propose l'outil, le périmètre gonfle, et on perd le problème de départ. Le prototypage devient presque addictif, et des PM font le proto avant la spec, puis écrivent la spec à partir du proto.
Le mécanisme, tel qu'on me l'a résumé : le temps rare forçait à réfléchir, et sans lui on risque de tout accepter. Une fois qu'on livre plus vite, on empile aussi les features. Certains commencent d'ailleurs par une roadmap de ce qu'on va supprimer.
« Ton scope ne fait qu'augmenter, augmenter, augmenter. »
« La prochaine vraie qualité, c'est de savoir dire non. »
