Ce que fait vraiment un chef de produit technique (et ce qu'il ne fait pas)

Chaque entreprise semble définir « chef de produit technique » à sa façon. Pour certaines, c'est un PM senior avec un diplôme en informatique; pour d'autres, un chef de projet qui parle API. Les deux passent à côté. Après 16 ans dans le rôle, voici la définition que j'utilise.

Ce qu'un TPM porte

• Le « pourquoi » et le « quoi » des décisions au niveau plateforme
• Les compromis entre portée, délai, coût et dette technique
• Les dépendances inter-équipes (API, contrats de données, infra)
• L'arbitrage de la feuille de route quand deux équipes visent la même semaine

Ce qu'un TPM ne porte pas

• Comment le code est écrit — c'est le travail de l'ingénierie
• Les décisions de design au pixel près — c'est le travail du design
• La mécanique des sprints — c'est le travail de l'équipe
• Être la personne la plus brillante dans la pièce — ce n'est le travail de personne

Là où le TPM crée du levier

Un excellent TPM lève l'ambiguïté plus vite que quiconque dans l'organisation. Il transforme une demande vague en une spécification d'une page que les ingénieurs peuvent chiffrer, puis en un plan de mise en production que la finance, le marketing et le support peuvent préparer. Le livrable, c'est l'alignement — pas des documents.

Comment reconnaître un excellent TPM

Ses ingénieurs lui font confiance sur les compromis techniques. Ses designers se sentent entendus. Ses dirigeants obtiennent les chiffres dont ils ont besoin sans avoir à demander deux fois. Et la feuille de route livre vraiment — trimestre après trimestre.

Les bons TPM sont des traducteurs. Les meilleurs sont aussi des éditeurs — ils coupent ce qui n'est pas essentiel.