Chers CTOs et tech leaders,
Vous le savez, le but de toute entreprise est de dégager des profits ; et pour un éditeur de logiciel, la génération de profit est intimement liée à sa capacité à délivrer plus de valeur aux utilisateurs. À mesure qu’une entreprise se développe, la création de cette valeur se complexifie : les pôles product et engineering deviennent des entités distinctes, chacune poursuivant ses propres objectifs. Le premier privilégie l’exécution de la roadmap, tandis que le second se concentre sur la vélocité et la qualité de livraison des fonctionnalités.
Résultat : quand la croissance cale, il devient difficile pour un·e CEO d’évaluer la performance réelle de la machine « product-engineering » et sa capacité à délivrer, avec rapidité et fiabilité, une valeur perçue comme élevée par les utilisateurs. Les métriques existent par centaines, mais elles mesurent presque toujours un seul côté de la pièce, soit le produit, soit l’engineering, jamais la symbiose des deux.
Faute d’un indicateur unifié, estimer l’impact réel de cette synergie reste quasi impossible. Après des années à accompagner des CTO et CPO, j’ai créé une métrique perso : le Time to Positive User Feedback (TPUF). Une “North Star” qui reconnecte tout le monde autour du même objectif : plus de valeur pour les utilisateurs.
Présentation du TPUF
Le TPUF s’enracine dans la pensée systémique telle que popularisée par Donella Meadows : un produit ou une organisation doit être considéré comme un ensemble cohérent de composants interdépendants plutôt que comme une juxtaposition de parties. Dans le contexte d’une start-up software, il s’agit d’observer comment les différents éléments du système product-engineering transforment une idée destinée à résoudre un problème utilisateur en une fonctionnalité complète, utilisée et appréciée.
Le système est décomposé en trois sous-systèmes :
Le premier sous-système, Product Management 1, constitue la « machine à idées » : les product managers y formulent des solutions potentielles et transforment celles qui sont jugées pertinentes en spécifications détaillées destinées au développement logiciel. Le sous-système Software Engineering prend ensuite le relais et convertit ces spécifications en fonctionnalités prêtes pour la production, de haute qualité. Le témoin passe enfin au sous-système Product Management 2, où product managers et développeurs analysent l’engagement utilisateur afin de vérifier que la fonctionnalité est employée comme prévu ; si l’usage réel diverge des attentes, ce sous-système déclenche le processus d’itération.
Grâce au TPUF, les décideurs appliquent la pensée systémique pour évaluer l’efficacité et l’interaction de ces sous-systèmes. Un TPUF faible indique une transition rapide et fluide de l’idée à la satisfaction utilisateur, signe d’un système produit-ingénierie sain et réactif. À l’inverse, un TPUF élevé peut mettre en évidence des inefficacités ou des désalignements nécessitant des ajustements itératifs afin d’aligner le produit final sur les besoins des utilisateurs. En définitive, le TPUF sert de prisme d’analyse du parcours produit complet, garantissant que les équipes produit et engineering atteignent leur objectif commun : la satisfaction utilisateur, obtenue avec une efficience systémique.
Sous-système Product Management 1
Point d’entrée du cycle : l’idéation et la validation initiale. Les responsables produit identifient les problèmes utilisateurs, proposent des solutions potentielles puis sélectionnent celles qui méritent d’être formalisées.
L'enjeu principal est d'éviter l’“idea flooding”. Quand les idées affluent sans contrainte, le risque est la constitution d’un backlog surdimensionné, entraînant un sentiment d’inachèvement permanent. Une gouvernance rigoureuse du pipeline est indispensable : plus de 90 % des idées doivent être refusées, quel que soit leur auteur.
Si le feu vert est accordé, les product managers transforment les idées en spécifications détaillées, idéalement en collaboration étroite avec l'engineering. Cet effort conjoint garantit que les concepts abstraits deviennent des plans d’action partagés, limitant les allers-retours qui surviennent lorsque les développeurs découvrent des contraintes de faisabilité inattendues ou posent des questions. Il s’agit d’une phase critique où analyse de marché, recherche utilisateur et planification stratégique convergent pour définir la fonctionnalité, le périmètre et les objectifs d’un volet produit, préparant ainsi son développement et, à terme, son adoption par les utilisateurs.
Sous-système Software Engineering
Le sous-système Software Engineering constitue la salle des machines : les développeurs y transforment les spécifications produit en fonctionnalités concrètes. Cette étape englobe le développement, les tests et la mise en production finale. Les ingénieurs doivent interpréter et exécuter les spécifications avec précision, en produisant un code robuste et fiable.
Le principal défi des tech leaders consiste à faire passer une spécification approuvée en code en prod le plus rapidement possible et avec le plus haut niveau de qualité. Les obstacles sont nombreux : accumulation de dette technique, qui alourdit les développements futurs en raison des coûts de maintenance, et problèmes d’intégration lorsque le nouveau code entre en conflit avec la base existante.
Les pratiques d’intégration et de déploiement continus sont essentielles pour surmonter ces difficultés. Les métriques DORA (DevOps Research and Assessment) sont déterminantes pour améliorer la performance du sous-système Software Engineering. Ces métriques (Deployment Frequency, Lead Time for Changes, Mean Time to Recovery et Change Failure Rate) offrent un moyen quantifiable d’évaluer l’efficacité et l’efficience des processus de développement et de mise en production.
Des fusions fréquentes de code dans un dépôt central rendent les tests automatisés et cohérents, réduisant les problèmes d’intégration. Le remboursement prioritaire de la dette technique est tout aussi crucial : il faut réserver du temps à la refactorisation et à l’amélioration de la base de code en parallèle du développement de nouvelles fonctionnalités. De plus, instaurer une culture de revue de code renforce la qualité logicielle et le partage de connaissances, limitant la formation de silos sources de retards et de bogues.
En définitive, le sous-système Software Engineering se juge à sa capacité à livrer efficacement des fonctionnalités de haute qualité en production, condition préalable au feedback utilisateur et au cycle d’amélioration continue.
Sous-système Product Management 2
Le sous-système Product Management 2 constitue le bras évaluatif et itératif du processus product-engineering, intervenant après la mise en production. Sa mission fondamentale est d’analyser l’interaction des utilisateurs avec les fonctionnalités fraîchement déployées ; il s’agit de vérifier qu’elles sont employées comme prévu et qu’elles résolvent effectivement les problèmes visés.
Le “usage gap”, l’écart entre la disponibilité d’une fonctionnalité et son adoption effective, constitue le risque principal. Pour le réduire, il faut instaurer une instrumentation complète, collecter des données d’usage fiables et maintenir une boucle de rétroaction rapide. Des revues transverses régulières permettent de décider des itérations nécessaires : ajustement mineur, refonte partielle ou abandon.
Ainsi, une fonctionnalité ne peut être comptabilisée comme “délivrée” par l’engineering tant que le seuil d’adoption défini n’est pas atteint. Les tableaux de bord d’avancement doivent donc intégrer cette métrique d’usage au même titre que la vélocité ou la qualité : un bloc de code poussé en production mais ignoré des utilisateurs n’ajoute aucune valeur. Autrement dit, la definition of done doit inclure la preuve d’usage, obligeant la tech à se responsabiliser sur l’impact réel, pas seulement sur la livraison rapide et fiable.
La réussite de ce sous-système repose ainsi sur son agilité et sa capacité d’adaptation. Tant qu’une fonctionnalité n’a pas atteint son usage cible, le cycle de perfectionnement doit se poursuivre.
Conclusion
Le TPUF offre aux éditeurs de logiciel un indicateur pertinent pour synchroniser produit et ingénierie sur les attentes du marché. Toutefois, selon la loi de Goodhart, « lorsqu’une mesure devient un objectif, elle cesse d’être une bonne mesure ». Chercher à tout prix à abaisser le TPUF peut inciter à négliger la qualité ou à imposer un rythme de travail insoutenable.
Le TPUF doit être utilisé comme outil de diagnostic, non comme finalité. Employé avec discernement, il oriente l’organisation vers une meilleure efficacité et une satisfaction utilisateur accrue, tout en laissant l’espace nécessaire à l’innovation et à la résilience, facteurs essentiels d’une croissance durable.
À tester dès lundi 9h
- Mesurer le TPUF dans votre organisation ;
- Réduire l’“idea flooding” dans Product Management 1 et mettre en place des mesures de barrage si le stock d'idées est trop important ;
- Ajouter des métriques de feedback utilisateur aux objectifs Engineering et intégrer cet indicateur dans les OKR et les revues de performance des équipes engineering.
Formation Unicorn CTO – Cohorte de septembre (places très limitées)
Si vous ne connaissez pas encore ma formation Unicorn CTO, c'est un programme dédié aux CTOs et aux tech leaders souhaitant scaler leur organisation et booster les performances de l'équipe. Le programme est basé sur 5 piliers :
1. Contenus premium : 50h+ de vidéos originales, replays d’ateliers et une bibliothèque de 100+ ressources pour creuser chaque sujet.
2. Sessions live ultra-pragmatiques : 10 ateliers en ligne de 1h30 (un thème concret chaque semaine) pour appliquer immédiatement cadres et outils.
3. Parcours personnalisé : plan d’apprentissage sur-mesure pour répondre à vos objectifs et défis spécifiques.
4. One-on-one entre pairs : échanges ciblés avec d’autres CTO & tech leaders pour accélérer la montée en compétence.
La cohorte de mai s’est remplie en quelques semaines et il ne reste que quelques places pour celle de septembre ! Cliquez ici pour découvrir le programme et candidater à la prochaine session.