CTO: Comment dire Stop à tes cofondateurs

Ton Cofondateur à une nouvelle idée en se brossant les dents ce matin ? Je t'explique comment gérer cette situation

CTO: Comment dire Stop à tes cofondateurs

Tu es le seul cofondateur à savoir coder ?
Tu as signé pour builder. Pour aller vite. Pour faire sortir des idées de terre.Mais parfois, tu sens que tu es devenu aussi le centre de tri des idées folles, le décodeur d’intuitions floues, et parfois… le traducteur universel de “j’ai eu une idée en me brossant les dents ce matin”.

Bienvenue.

Voici un petit guide de survie pour CTO lucide mais enthousiaste, qui veut continuer à livrer, sans finir sous une avalanche de features ni casser l’énergie de ses cofondateurs.


1. Phase MVP : Le moment de cadrer, pas de freiner

Au début, c’est l’euphorie. L’idée est fraîche, les promesses sont sexy, les premières conversations avec le marché sont prometteuses. Et puis vient la phrase magique :

“Tu penses qu’on peut faire une première version, genre en deux semaines ?”

Dans leur tête, c’est un MVP.Dans la tienne, c’est déjà trois produits, deux back-offices et une intégration Stripe.

C’est ici que tu joues ton rôle : ramener au sol sans éteindre la flamme.

Tu ne dis pas non. Tu dis :

  • “OK, ce qu’on veut montrer et tester, c’est quoi exactement ?”
  • “Est-ce qu’on peut avoir une valeur livrable sans back ?”

👉 Ton superpouvoir ici, c’est de proposer moins, mais mieux. L’idée est de répondre à l’urgence, sans avoir un truc éclaté à montrer.Un MVP doit déjà apporter une solution au problème. 

C’est imparfait certes, mais si ça ne résout rien, autant faire une maquette sur Figma.Par contre, ça doit être réalisable le plus vite possible.

2. Phase POC : Prioriser sans tuer l’élan

Le MVP tourne. Il est moche, pas scalable mais il vit. Et là, l’équipe revient de ses premiers appels clients avec 12 idées neuves, 5 pivot potentiels et un enthousiasme débordant.

D’un point de vue technique, ça fait peur mais même très encourageant au final. C’est comme ça qu’on avance.

Néanmoins tu canalises. Tu guides. Tu cadres, sans casser.

  • “OK, sur ces idées, laquelle est la plus demandée ?”
  • “Qu’est ce que le POC doit valider ?”

👉 Ta valeur ici, c’est de créer un cadre de discussion. Tu ne coupes pas l’envie : tu lui donnes une forme. Tu évites le syndrome de la "todo infinie", en aidant l’équipe à séparer ce qui brille de ce qui est vraiment utile.


3. Phase Feedback Client : Filtrer avec finesse

Maintenant il y a des utilisateurs. Des vrais. Et leurs retours tombent comme la pluie: constants, flous, imprévisibles.

Tu entends :

  • “On devrait tout refaire en mobile-first !”
  • “Les gens veulent quelque chose de plus beau, plus rapide!”
  • Il y a des bugs

Tu te sens un peu perdu mais encore une fois, c’est normal, pense au chemin parcouru. Tu build pour des vrais gens. Ça donne le vertige mais l’idée n’est pas de tout faire pour demain, il faut filtrer.

Alors tu poses les bonnes questions :

  • “On priorise quels bugs d’abord ?”
  • “Qu’est-ce qu’on garde et qu’est ce qu’on enlève?”
  • “Quelle fonctionnalité les gens veulent vraiment acheter ?”

👉 Mon conseil:Apporte le recul et le calme pour que tes cofondateurs puissent prioriser.Ce qu’ils cherchent avant tout est d’estimer la difficulté et le temps nécessaire de chaque requête clients.Si tu leur apporte ces insights, ils vont naturellement filtrer les demandes.


Conclusion : Ne soit pas un mur, soit un pont

Le rôle de développeur dans une start-up (surtout early) et de trouver l’équilibre entre builder rapidement sans exécuter aveuglément non plus.

Ton rôle est avant tout d’apporter des réponses claires : ce qui est faisable, dans combien de temps, avec quels impacts.

  • Si tu dis non à tout, tu vas casser l’énergie de tout le monde avant que ta start-up décolle. Le rôle d’un founder est d’alimenter ce feu sacré.
  • En revanche, ne fais pas tout ce que l’on te demande sans filtrer sinon ça va partir dans 1000 directions.

Un des principaux conflits entre cofondateurs surgit souvent d’une guerre entre "le produit" et "le business"..

Chacun doit s’éduquer les uns les autres sur sa partie pour construire une roadmap solide et crédible. C’est un dialogue continu :

  • Le business apporte la direction, les signaux du terrain, l’élan.
  • Le CTO apporte la faisabilité, la temporalité, les arbitrages nécessaires pour que tout ça tienne debout.

Et quand ce dialogue est sain, tout change :

👉 Le business prend de meilleures décisions, car il connaît les contraintes réelles. 👉 Le produit avance plus vite, car il ne se disperse pas.
👉 Le client est mieux servi, car on lui promet ce qu’on peut vraiment tenir.