Idée principale

Entre l'intention et la production, il existe une échelle de marches identifiables : rester au niveau de la maquette, produire un prototype manipulable, construire un outil interne ou un tableau de bord réellement utilisé, ouvrir une pull request encadrée, porter un livrable jusqu'en production, comprendre assez les risques pour faire valider correctement ce qu'on produit. Chacune de ces marches demande quelque chose de plus que la précédente.

Un Product Manager équipé peut en gravir plusieurs ; un développeur qui monte vers le produit gravit les mêmes dans l'autre sens. Le Product Engineer, en particulier, se rejoint par deux trajectoires opposées — un développeur qui remonte vers le problème, ou un profil produit assez technique qui descend vers la production — et rien dans le résultat ne dit par où la personne est passée.

Le métier d'origine cesse donc d'être le bon prédicteur. Ce qui situe quelqu'un est la marche qu'il atteint, et la question « jusqu'où vas-tu ? » remplace la question « qu'est-ce que tu es ? ».

Pourquoi c'est important

Cela fournit une échelle commune pour discuter ce qu'une personne peut prendre en charge, indépendamment de l'intitulé qu'elle porte et du service auquel elle est rattachée.

Et cela évite deux erreurs symétriques de recrutement : refuser une contribution parce qu'elle vient du mauvais métier, et l'accepter parce qu'elle vient du bon.

Nuances et limites

L'échelle n'est pas linéaire : quelqu'un peut porter un livrable en production sur un périmètre simple et rester incapable de produire une maquette utilisable sur un parcours complexe. La marche atteinte dépend autant de la zone que de la personne.

Et un continuum ne dit rien du droit d'y avancer : savoir ouvrir une pull request n'autorise pas à le faire sur n'importe quel périmètre.

Questions ouvertes

• Comment une équipe constate-t-elle la marche réellement atteinte par quelqu'un, autrement qu'en lui confiant un périmètre et en regardant ce qui se passe ?