De Product Owner à builder

Pendant longtemps, mon métier consistait à décrire des produits que je ne construisais pas. Product Owner, c'est ça : tu cadres le besoin, tu écris les specs, tu priorises, tu coordonnes — et tu confies la réalisation à une équipe technique. J'ai fait ce métier chez Givemefive à Bruxelles, puis chez CELINE, dans le groupe LVMH, sur une application de clienteling utilisée par des milliers de vendeurs à travers le monde.

J'ai aimé ce rôle. Penser un produit, comprendre les utilisateurs, arbitrer entre des contraintes contradictoires — c'est un travail exigeant et utile. Mais il y avait une frustration récurrente, et elle revenait à chaque sprint : entre ce que j'avais en tête et ce qui finissait par exister, il y avait toujours une couche de traduction. Une spec, aussi précise soit-elle, n'est jamais le produit. C'est une carte. Et entre la carte et le territoire, beaucoup se perd.

La traduction qui coûte cher

Chaque idée passait par plusieurs mains avant de devenir réelle. Je l'écrivais, un développeur l'interprétait, un détail technique la déformait, un délai la rabotait. Au bout de la chaîne, le produit fonctionnait — mais il avait dérivé. Pas par incompétence : simplement parce que personne ne tenait toute la chaîne, du problème jusqu'au pixel. Je voyais les compromis être pris sans pouvoir vraiment peser dans la balance, faute de comprendre ce qui était cher ou bon marché à construire.

C'est là que j'ai décidé d'apprendre à construire. Pas pour remplacer les ingénieurs, mais pour arrêter de raisonner à l'aveugle. Mon double cursus — ingénieur à CPE Lyon, management et stratégie à emlyon — m'avait donné les deux moitiés du cerveau. Il me manquait de les faire travailler ensemble sur le même clavier.

Ce que ça change vraiment

Quand tu sais construire, tu cesses de penser le produit comme une liste de fonctionnalités. Tu le penses comme un système : des contraintes, des coûts, des dépendances. Tu sais qu'une idée qui paraît anodine peut coûter trois semaines, et qu'une autre, plus ambitieuse en apparence, est presque gratuite. Cette intuition-là ne s'écrit pas dans une spec. Elle se gagne en mettant les mains dedans.

Le vrai changement n'est pas technique, il est dans la boucle de décision. Avant, je décidais puis je déléguais. Maintenant, je décide en construisant : je teste une hypothèse en une journée plutôt que de la défendre en réunion pendant une semaine. Le produit avance par l'expérience, pas par le débat.

Je ne crois pas qu'il faille opposer le profil produit et le profil ingénieur. La combinaison rare, ce n'est pas l'un ou l'autre — c'est la même personne qui sait cadrer un problème et le livrer. C'est ce que j'essaie d'être aujourd'hui, en co-fondant mes propres produits et en accompagnant ceux des autres. Un builder qui pense produit, et un PO qui sait coder. Les deux à la fois, sans traduction.