Un CTO ne remplace pas le Product Manager. En revanche, il ne peut pas prendre de bonnes décisions s'il ignore l'utilisateur, le modèle économique et la direction du produit. Sans ce contexte, l'équipe technique exécute des demandes au lieu d'aider l'entreprise à choisir ses compromis.
Je l'ai vécu sur Republike en 2023. J'ai construit le MVP web en moins de six mois, puis nous avons itéré pendant plus d'un an. Les idées du fondateur restaient parfois trop floues pour être exploitables, tandis que mes alertes techniques semblaient relever d'une prudence excessive. Après un an et demi, la fatigue a pris de la place et notre communication s'est dégradée, alors que nous voulions aller dans la même direction.
Le problème ne venait pas d'un manque de bonne volonté. Nous avions une vision partagée, mais pas le même langage pour la rendre concrète. C'est ce décalage que vous devez éviter avant que votre équipe ne transforme un flou produit en décisions difficiles à défaire.
Comprendre le produit ne veut pas dire le diriger
Le Product Manager, ou la personne qui porte le produit, reste responsable du problème à résoudre. Il clarifie pour qui la demande existe, pourquoi elle passe avant une autre et quelle valeur on attend. Le CTO n'a pas à récupérer ce mandat ni à devenir propriétaire de la roadmap. Il doit pouvoir interroger ce contexte quand il change la façon de construire.
Prenez une demande simple en apparence : permettre à un utilisateur d'inviter un collègue. Le Product Manager décide si cet usage répond à un besoin réel et ce qui rend l'invitation réussie. Le CTO regarde alors ce que cette promesse implique pour les droits d'accès, les notifications ou les données déjà présentes. S'il ne connaît que le ticket, il peut livrer un bouton qui fonctionne tout en créant une règle de permissions difficile à faire évoluer.
Cette frontière protège les deux rôles. Le Product Manager évite que la technique décide seule de ce qui mérite d'être construit. Le CTO évite que le leadership produit traite chaque demande comme un bloc isolé, sans voir ce qu'elle engage pour la suite. Leur discussion doit porter sur la décision, pas sur le contrôle de l'autre.
Vous n'avez pas besoin de transformer votre CTO en chercheur utilisateur. Vous devez lui donner accès à ce qui explique la demande : le cas d'usage, la contrainte commerciale et le comportement attendu. Un CTO à temps partiel a besoin de ce même accès, même s'il n'est pas présent chaque jour.
Le manque de contexte finit dans la codebase
Une équipe qui manque de contexte choisit souvent la réponse la plus prudente pour elle. Elle ajoute une configuration parce qu'elle ignore si le cas va se répéter, ou généralise une règle sans connaître les clients concernés. Parfois, elle construit des options que personne ne demandera, faute d'une limite produit claire.
Le résultat se voit rarement au moment de la démo. La fonctionnalité passe, puis la prochaine demande doit composer avec des cas particuliers, des permissions et des écrans devenus plus compliqués. La codebase, c'est le code que votre équipe doit comprendre et maintenir à chaque évolution. Quand elle absorbe des décisions floues, chaque changement demande plus de temps et augmente le risque de toucher une règle oubliée.
L'inverse existe aussi. Sans contexte, un CTO peut simplifier une zone qui devait rester fiable. Il peut repousser une contrainte parce qu'elle lui paraît secondaire, alors qu'elle conditionne une promesse faite aux utilisateurs ou une vente en cours. Ce n'est pas forcément une erreur de compétence. C'est une décision prise avec une partie du dossier manquante.
Le coût ne se limite donc pas au développement initial. Vous le retrouvez dans les retours en arrière, les échanges de clarification et les arbitrages qui arrivent trop tard. L'article sur le product sense montre le même mécanisme à l'échelle d'un développeur : comprendre le problème évite parfois de construire une réponse inutile.
Dans une startup, ce flou crée aussi une friction humaine. Le fondateur pense avoir exprimé une intention. Le CTO entend une demande incomplète et pose des réserves. Si personne ne traduit l'un pour l'autre, la discussion tourne vite à l'affrontement entre vitesse et prudence. Pourtant, le désaccord porte souvent sur ce que chacun suppose sans le dire.
Donner au CTO les informations qui changent ses décisions
Le bon réflexe consiste à partager le contexte avant la solution. Pour un chantier qui compte, votre CTO doit savoir quel utilisateur est concerné et ce qui le bloque aujourd'hui. Il doit aussi connaître la raison business qui rend le sujet prioritaire. Une échéance client, une promesse commerciale ou un usage qui échoue n'appellent pas les mêmes compromis.
Ajoutez une limite claire. Quel niveau de qualité attendez-vous pour cette première version ? Quel risque pouvez-vous accepter, et lequel serait trop coûteux ? Ces questions donnent au CTO une base pour proposer une solution proportionnée, au lieu de surconstruire par défaut ou de couper au mauvais endroit.
Un échange bref suffit avant de découper le travail. Le Product Manager explique pourquoi le sujet passe maintenant. Le CTO répond avec l'option qu'il privilégie et le coût de ce choix. Mettez à l'agenda les sujets qui modifient le parcours principal ou les données des utilisateurs. Le reste ne demande pas une réunion de gouvernance.
Demandez aussi au CTO de remonter les hypothèses qu'il fait. Par exemple, il peut dire que la première version ne concerne qu'un type d'utilisateur, ou qu'un délai de réponse reste acceptable pour cet usage. Ces hypothèses sont utiles parce qu'elles permettent à la personne qui porte le produit de les confirmer ou de les corriger avant que le code ne les fige.
Le partage de contexte ne consiste pas à envoyer toute la documentation existante. Une équipe noyée sous les documents devine encore. Donnez les éléments qui changent une décision, puis laissez le CTO demander ce qui manque. C'est aussi une façon de déléguer sans disparaître : vous gardez l'intention visible sans valider chaque détail technique.
Vérifier l'alignement avant le prochain chantier
Vous pouvez vérifier l'alignement sans lire une ligne de code. Commencez par demander au CTO de résumer le problème utilisateur avec ses mots. S'il ne peut parler que de la fonctionnalité, le contexte produit n'est sans doute pas assez partagé. S'il explique l'usage visé et la contrainte qui compte, vous avez déjà une base de discussion plus saine.
Posez ensuite une question plus concrète : quel compromis technique envisagez-vous, et qu'est-ce que nous perdons en le choisissant ? Une réponse utile nomme la conséquence pour le produit. Elle peut être un délai plus long, une limite pour certains utilisateurs ou un risque à surveiller après la livraison. Vous n'avez pas besoin de trancher la solution, mais vous devez comprendre ce que vous acceptez.
Demandez enfin ce qui ferait basculer la décision. Cette réponse révèle l'hypothèse qui mérite d'être suivie. Elle empêche qu'une condition ignorée ressurgisse après la livraison. Le désaccord devient alors une décision identifiable.
Installez un rituel court avant les chantiers qui touchent au cœur du produit. Gardez-le centré sur le problème, les contraintes connues et les décisions à éclairer. Puis revenez-y après la livraison si une hypothèse s'est révélée fausse. Cette boucle donne au CTO le contexte nécessaire sans lui confier la direction produit.
Ce qu'il faut retenir
Un CTO prend de meilleures décisions quand il connaît le problème auquel le chantier répond. Le Product Manager garde le choix de ce qui mérite d'être construit, tandis que le CTO peut nommer les compromis avant qu'ils ne se cachent dans le code.
Le prochain chantier est un bon test. Si votre CTO peut expliquer l'usage, la limite acceptée et le risque à surveiller, vous avez un dialogue utile. S'il doit deviner ces éléments à partir d'un ticket, vous lui demandez de décider dans le brouillard.
Questions fréquentes
Un CTO doit-il participer aux décisions produit ?
Oui, lorsqu'une décision produit change les compromis techniques à faire. Il apporte les conséquences en matière de capacité de livraison, de risque et de maintien du produit. La priorité et la valeur attendue restent du ressort du Product Manager ou du leadership produit.
Comment partager le contexte sans multiplier les réunions ?
Réservez un échange court avant les chantiers qui touchent aux usages importants, aux données ou aux droits d'accès. La personne qui porte le produit y précise le problème, la priorité et les limites. Le CTO y expose les hypothèses et les compromis qui demandent une décision.
Que faire si le CTO conteste souvent une demande produit ?
Demandez-lui d'exprimer la conséquence concrète qu'il anticipe, plutôt que de discuter sur un ressenti. Vérifiez ensuite si le leadership produit a donné assez de contexte pour juger cette conséquence. Un désaccord formulé de cette façon devient une décision à prendre, pas un bras de fer.