Le problème du "PM qui code"
Dans un post interne Meta devenu viral, un Product Manager senior partage son avis tranché sur une tendance qui agite la tech : les PM qui codent et pushent en production.
L'argument contre le code en prod
Le raisonnement est brutal mais logique :
- Si la feature est importante, corrigez le système de priorisation plutôt que de le contourner
- Vous codez comme un E3 lent mais coûtez le salaire d'un IC7
- La dette technique s'accumule avec les "pet features" de PM
- Vos amis TL seniors reviewent votre code, mais c'est du temps mal utilisé
Le verdict : les PM qui landent des diffs en prod font du "snacking" — ils confondent mouvement et progrès.
Alors pourquoi les PM devraient coder ?
L'auteur ne dit pas que les PM ne devraient jamais coder. Il précise les cas où c'est utile :
- Mieux communiquer une idée : montrer vaut mieux que décrire
- Comprendre les systèmes : prioriser et communiquer avec les ingénieurs est plus facile quand on comprend comment c'est construit
- Expériences réalistes : les mocks et études UXR avec prototypes statiques sont morts
- Exploiter un talent unique : par exemple, une connaissance approfondie d'une API de votre ancienne boîte
- Le fun : coder peut être agréable, et c'est ok
Le contexte du "vibe coding"
Le terme "vibe coding" décrit cette tendance où des non-développeurs utilisent l'IA pour générer du code et le pusher en production. Avec Claude Code, Cursor, et autres outils, la barrière d'entrée n'a jamais été aussi basse.
Mais basse barrière d'entrée ne signifie pas absence de risques. Le code généré peut fonctionner localement et casser en production. Les edge cases ne sont pas gérés. La maintenabilité n'existe pas.
La vraie compétence PM
Le post conclut sur ce que les PM devraient vraiment faire avec l'IA : construire des EVALS. Comprendre comment mesurer la qualité des outputs IA est bien plus valuable que de générer du code soi-même.
C'est une position nuancée qui mérite réflexion : l'IA change le jeu, mais le rôle du PM reste la stratégie et la priorisation, pas l'implémentation.