PM technique : ce que ça veut vraiment dire
On lit souvent « cherchons PM technique » dans les offres d'emploi. Mais qu'est-ce que ça signifie vraiment ? Parler JSON en réunion ? Savoir écrire du SQL ? Avoir fait de l'informatique à l'école ?
La réponse courte : non. Ou du moins, pas que.
Ce que le background technique change vraiment
1. La lecture des specs techniques
Un PM non-technique reçoit une estimation de l'équipe engineering et doit faire confiance. Un PM technique peut poser les bonnes questions :
- « Cette estimation de 3 semaines inclut-elle les tests d'intégration ? »
- « Est-ce qu'on réutilise le service existant ou on en crée un nouveau ? »
- « Quel est le risque si on skip la migration de schema maintenant ? »
Ce n'est pas une question de méfiance — c'est une question de profondeur de dialogue.
2. La définition du périmètre
Quand tu comprends l'architecture, tu sais ce qui est cher et ce qui est gratuit. Une feature qui semble simple côté UX peut représenter une refonte de la couche de données. À l'inverse, une feature qui semble complexe peut n'être qu'un changement de configuration.
Cette lecture du coût technique t'aide à prioriser avec honnêteté, pas avec des intuitions mal calibrées.
3. La crédibilité dans la room
Je ne dis pas que les PM non-tech ne sont pas crédibles. Mais il y a une différence entre être respecté et être entendu. Quand tu peux t'asseoir dans un design doc review et contribuer sur le fond, tu changes de statut aux yeux des ingénieurs.
Tu passes de « le PM qui apporte les specs » à « quelqu'un qui comprend les contraintes ».
Ce que ça ne veut PAS dire
Être PM technique ne veut pas dire :
- Réécrire les specs en pseudo-code
- Remettre en question chaque décision d'architecture
- Se positionner comme backup tech lead
- Coder pendant son temps libre pour « rester à jour »
Le rôle du PM reste de définir le quoi et le pourquoi. Le comment reste le territoire de l'engineering.
La vraie valeur
La vraie valeur d'un PM technique, c'est la réduction du coût de traduction. Chaque fois qu'un PM doit passer par un intermédiaire pour comprendre une contrainte technique, il y a une perte d'information, un délai, et un risque d'erreur.
Un PM qui peut lire le code, comprendre un diagramme d'architecture, ou discuter de tradeoffs techniques réduit ce coût — et accélère l'équipe.
Ce billet est le premier d'une série sur ce que signifie être PM avec un background d'ingénieur. Les suivants aborderont la gestion de la dette technique et la collaboration avec les leads engineering.