Product thinking : pourquoi les PM doivent coder (un peu)

Le mythe du PM non-technique

Il est courant d'entendre que le product manager n'a pas besoin de savoir coder. Qu'il suffit de comprendre les besoins utilisateurs, de prioriser, et de laisser les ingénieurs faire leur travail.

C'est partiellement vrai — et largement insuffisant.

Ce que la technique apporte au PM

Après plusieurs années à alterner entre des rôles de PM et de développeur, voici ce que j'ai observé :

1. Estimer sans se faire avoir

Un PM qui n'a jamais écrit de code accepte facilement des estimations à la louche. Quand un développeur dit "c'est simple, deux jours", il faut savoir lire entre les lignes. Savoir ce qu'implique une migration de base de données ou une refonte d'API change radicalement la conversation.

2. Écrire des specs exploitables

Les specs vagues génèrent du rework. Comprendre les contraintes techniques permet d'écrire des user stories avec les bons critères d'acceptance, d'anticiper les edge cases, et de réduire le nombre d'aller-retours.

3. Avoir de la crédibilité en standup

Rien de pire que le PM qui pose des questions déconnectées de la réalité en daily. La technique ne remplace pas l'empathie utilisateur, mais elle permet de participer à la conversation technique plutôt que de la subir.

Ce que ça ne remplace pas

Savoir coder ne remplace pas :

• La capacité à interviewer des utilisateurs
• La rigueur dans la priorisation
• La gestion des parties prenantes
• Le sens du produit et du marché

La technique est un amplificateur, pas une finalité.

Mon approche pratique

Je maintiens mes compétences techniques en construisant mes propres outils — comme cette application de budget. Cela me force à rester à jour sur les patterns modernes, à comprendre les arbitrages techniques, et à tester les produits que j'utilise avec un regard différent.

C'est aussi pour ça que ce portfolio existe : montrer que product et engineering ne sont pas deux mondes séparés.