Product sense : pourquoi coder ne suffit plus

On recrute un développeur sur sa technique. On le garde sur sa capacité à livrer vite, propre, sans bug. Et pourtant, après quinze ans à construire des produits et à diriger des équipes techniques en startup, j'ai vu la même chose se confirmer mission après mission : le développeur qui crée le plus de valeur est rarement celui qui code le mieux. C'est celui qui comprend pourquoi il code. Cette différence, vous la payez tous les mois sans la voir passer.

Ce contraste, je l'ai vu se rejouer sur la plupart de mes missions. Deux développeurs du même niveau technique, interchangeables sur le papier, qui produisent des résultats qui n'ont rien à voir. L'un fait avancer le produit, l'autre fait avancer le backlog. Ce n'est pas la même chose, et c'est tout l'objet de cet article.

Ce qui sépare un développeur coûteux d'un développeur rentable

La compétence dont je parle porte un nom : le product sense. C'est la capacité à comprendre le problème réel derrière une demande, et pas seulement à exécuter la demande telle qu'elle est formulée.

Prenez un cas que j'ai vu se reproduire plusieurs fois. Une équipe se lance dans un chantier ambitieux : un système complet de filtres, de tags et de catégories pour que les utilisateurs retrouvent leurs informations. Plusieurs semaines de travail prévues. Le développeur sans product sense ouvre son éditeur et commence à construire. Celui qui en a commence par aller parler à quelques utilisateurs. Et souvent, ce qu'il remonte change la donne : le problème ne vient pas d'un manque de filtres, mais d'une recherche lente et imprécise. On remplace alors des semaines de chantier par une refonte ciblée de la recherche, livrée en une fraction du temps, qui règle la plus grande partie des frustrations.

Les deux développeurs auraient passé le même temps à travailler. Un seul aurait résolu le problème. L'autre aurait livré un système qu'il aurait fallu maintenir pendant des années pour un bénéfice marginal. Voilà la différence concrète entre construire correctement une fonctionnalité et construire la bonne fonctionnalité.

Ce profil porte aujourd'hui un nom dans les meilleures équipes tech : le Product Engineer. Un développeur capable de comprendre les utilisateurs, le produit et le business, pas seulement la technique. C'est devenu l'un des profils les plus recherchés du marché, et ce n'est pas un hasard. La compétence est rare, et c'est elle qui sépare un coût d'un investissement.

Pourquoi cette différence pèse sur votre burn rate

Tant que votre produit est petit, l'écart reste invisible. Peu de fonctionnalités, peu d'utilisateurs, peu de dette. Une fonctionnalité de trop ne se remarque pas. Le problème, c'est que cet écart grossit avec votre produit, et qu'il grossit plus vite que votre chiffre d'affaires.

Chaque fonctionnalité que vous expédiez a un coût qui ne s'arrête pas le jour de la livraison. Elle se maintient, elle génère du support, elle ajoute de la complexité à toutes les fonctionnalités qui viendront après elle, et elle alourdit la base de code que chaque nouveau développeur devra comprendre. Construire la mauvaise fonctionnalité ne coûte pas une semaine de développement. Ça coûte une semaine de développement, plus des mois de maintenance, plus l'opportunité que vous n'avez pas saisie pendant ce temps. Dans une startup qui brûle du cash, c'est souvent l'erreur la plus chère que personne ne facture.

C'est d'ailleurs un point que je développe ailleurs : coder ne représente que 20 % du travail réel. Le reste, c'est comprendre ce qu'il faut construire, et surtout ce qu'il ne faut pas construire.

Le développeur qui reformule la demande ne vous fait pas gagner du temps parce qu'il code plus vite. Il vous le fait gagner parce qu'il remplace un mauvais chantier par la bonne réponse. C'est ça, un développeur rentable : quelqu'un qui réduit la quantité de code que votre entreprise doit porter, pas quelqu'un qui l'augmente proprement.

Comment repérer ce profil dans votre équipe et à l'embauche

La bonne nouvelle, c'est que vous n'avez pas besoin d'être technique pour le repérer. Vous avez même un meilleur angle que la plupart des recruteurs techniques, parce que vous regardez le résultat business, pas l'élégance du code.

Le signal tient en une réaction. Face à une demande, le développeur sans product sense cherche d'abord comment construire la fonctionnalité. Celui qui en a cherche d'abord pourquoi elle doit exister. En entretien, décrivez-lui une demande volontairement floue, comme un vrai fondateur la formulerait, et observez par quoi il commence. Vous n'avez pas besoin de comprendre son code pour entendre la différence.

Dans votre équipe actuelle, le signal est tout aussi lisible. Repérez qui revient vers vous pour comprendre l'intention avant de coder, et qui vous propose parfois de ne pas construire ce que vous avez demandé. Ce développeur-là n'est pas difficile, il vous protège. Méfiez-vous de l'inverse : celui qui dit toujours oui, qui livre tout sans jamais challenger, est souvent celui qui vous coûte le plus cher, parce qu'il transforme chaque mauvaise idée en dette.

Reste un point que vous contrôlez directement : les conditions. Le product sense ne s'exprime que si vous laissez vos développeurs parler aux utilisateurs et accéder à l'intention derrière les décisions. Un développeur enfermé dans un tunnel de tickets n'a aucune chance de le développer, même s'il en a le potentiel. Si vous coupez vos équipes du contexte business, vous fabriquez vous-même des exécutants.

La décision que ça implique pour vous

La vraie bascule n'est pas dans votre recrutement, elle est dans votre façon de mesurer la valeur d'un développeur. Tant que vous évaluez vos équipes au volume de code livré, aux tickets fermés ou à la vélocité, vous récompensez exactement le mauvais comportement : produire plus, sans se demander si c'est utile. C'est d'ailleurs pour ça que mesurer la productivité de vos développeurs au volume mène presque toujours au mauvais endroit.

Le jour où vous mesurez un développeur aux problèmes qu'il résout plutôt qu'aux fonctionnalités qu'il livre, tout change. Vous valorisez ceux qui vous font gagner du temps en construisant moins. Vous payez plus cher les profils rares qui le méritent, et vous arrêtez de surpayer la vitesse d'exécution, qui est aujourd'hui la compétence la plus facilement remplaçable de toute la chaîne. C'est une décision de dirigeant, pas une décision technique. Et c'est l'une des rares qui améliore à la fois votre produit et votre trésorerie.

Ce qu'il faut retenir

• Votre développeur le plus précieux n'est pas celui qui écrit le meilleur code, c'est celui qui comprend le problème derrière chaque demande.
• Cette compétence est invisible quand votre produit est petit et décisive quand il grandit, parce que chaque mauvaise fonctionnalité se paie en maintenance et en dette pendant des années.
• Le vrai levier est entre vos mains : arrêtez de mesurer vos développeurs au volume livré, mesurez-les aux problèmes résolus.

Questions fréquentes

Comment savoir si un développeur a du product sense sans être technique soi-même ?

Donnez-lui une demande volontairement floue et regardez par quoi il commence. S'il enchaîne directement sur la construction, il exécute. S'il s'arrête sur l'usage et l'utilisateur visé, il réfléchit produit. Vous n'avez pas besoin de comprendre son code pour entendre la différence.

Faut-il recruter un développeur senior ou un Product Engineer ?

Ce ne sont pas les mêmes axes. La séniorité mesure la maîtrise technique, le product sense mesure le jugement. Un senior sans product sense construira très bien la mauvaise chose. Pour une startup early-stage, où chaque semaine compte, le jugement produit prime souvent sur la pure expertise technique.

Le product sense peut-il s'apprendre ?

Il se développe, mais seulement dans les bonnes conditions. Un développeur qui parle aux utilisateurs, lit les retours clients et comprend les décisions business le muscle avec le temps. Enfermé dans un tunnel de tickets, il ne le développera jamais, quel que soit son potentiel.

Conclusion

La valeur d'écrire du code est déjà en train de s'effondrer. L'IA en produit de plus en plus, de mieux en mieux, et cette tendance ne fera que s'accélérer. Ce qui prend de la valeur, à l'inverse, c'est de savoir quel problème mérite d'être résolu. Cette compétence-là ne s'automatise pas.

Pour vous, dirigeant, la conséquence est concrète : l'avantage ne se jouera plus sur la quantité de code que votre équipe produit, mais sur sa capacité à construire les bonnes choses. Le développeur qui comprend cette différence est déjà le profil le plus rentable de votre équipe. Savoir le repérer, c'est votre prochaine décision.

Vous structurez votre équipe technique en ce moment et vous voulez savoir qui, chez vous, crée vraiment de la valeur ? Parlons-en directement, un échange de 30 minutes suffit souvent à y voir clair.