1/3
des founders
non-tech ne challengent
jamais leur équipe prod
Pas parce qu'ils font confiance aveuglément. Parce qu'ils ne savent pas comment faire sans paraître incompétents. Alors ils approuvent, ils acquiescent, ils repoussent les questions au prochain sprint review — et pendant ce temps, des décisions coûteuses se prennent sans eux.
J'ai été dans cette situation. Et j'ai coaché des dizaines de founders qui y étaient aussi. Ce que j'ai appris : challenger une équipe produit ne demande aucune compétence technique. Ça demande les bonnes questions — et de savoir lire les réponses.
Ce que cet article n'est pas
Un guide pour devenir tech lead. C'est un guide pour rester décisionnaire dans votre propre produit — sans que la complexité technique devienne un écran de fumée.
Pourquoi c'est difficile — et pourquoi c'est normal
La dynamique est classique. Vous recrutez un développeur senior, un designer expérimenté, un product manager. Ils parlent couramment une langue que vous ne maîtrisez pas. Très vite, les discussions produit deviennent des monologues techniques auxquels vous hochez la tête.
Ce n'est pas de la mauvaise volonté de leur part. C'est simplement que personne ne les a challengés autrement — et que dans le vide, les équipes techniques ont tendance à optimiser ce qu'elles savent mesurer : la complexité technique, pas la valeur utilisateur.
Situation réelle — Sprint review, semaine 8
Dev Lead
"On a refactorisé le module d'authentification, migré vers une architecture microservices et optimisé les requêtes SQL. La dette technique est maintenant sous contrôle."
Founder
"…Super. Et côté utilisateurs, qu'est-ce qui a changé pour eux cette semaine ?"
Dev Lead
"Rien de visible pour l'instant, mais la base est solide pour la suite."
Ce que le founder aurait dû répondre — et ne savait pas comment dire : "Si rien n'a changé pour les utilisateurs en 2 semaines de sprint, qu'est-ce qu'on a livré au sens produit ?"
Ce silence-là coûte des mois. Des sprints entiers passés sur de la plomberie technique pendant que les utilisateurs attendent des fonctionnalités. Et le founder qui n'ose pas poser la question parce qu'il a peur de "ne pas comprendre".
Le piège principal
La complexité technique n'est pas un signe de bon travail. C'est parfois le signe que l'équipe résout le mauvais problème — de façon très sophistiquée.
Les 7 questions qui changent tout
Ces questions ne demandent aucune compétence technique. Elles demandent une chose : ne pas accepter une réponse vague. Chaque question a une réponse attendue — et si vous ne l'obtenez pas, c'est un signal.
Q1
"Si vous deviez expliquer ce sprint à un utilisateur — pas à un développeur — qu'est-ce que vous lui diriez ?"
Cette question force l'équipe à traduire le travail technique en valeur réelle. Si elle n'y arrive pas en 2 phrases, le sprint n'avait peut-être pas d'objectif utilisateur clair.
✓ Bonne réponse : "L'utilisateur peut maintenant faire X en moins de 3 clics au lieu de 7."
⚠ Signal d'alarme : "C'est difficile à expliquer sans rentrer dans les détails techniques."
Q2
"Quelle décision on aurait pu prendre différemment cette semaine — et pourquoi on a fait ce choix ?"
Une équipe qui ne mentionne jamais les arbitrages n'en fait pas — ou ne vous les soumet pas. Les bonnes décisions techniques impliquent toujours des compromis. S'il n'y en a pas, quelqu'un les prend sans vous.
✓ Bonne réponse : "On a choisi X plutôt que Y parce que ça nous donne 3 mois de scalabilité en plus, au prix d'une semaine supplémentaire."
⚠ Signal d'alarme : "On a fait comme d'habitude, c'était la solution évidente."
Q3
"Quel est le scénario où ce qu'on construit ne fonctionne pas — et on fait quoi dans ce cas ?"
Cette question teste si l'équipe pense en risques. Une équipe solide a déjà anticipé les points de rupture. Une équipe fragile répond "ça va fonctionner" — et découvre les problèmes en prod.
✓ Bonne réponse : "Si la charge dépasse 10k utilisateurs simultanés, on a un plan B sur le cache."
⚠ Signal d'alarme : "On n'a pas prévu ça, mais on verra si ça arrive."
Q4
"Qu'est-ce qu'on a appris sur nos utilisateurs depuis la dernière fois ?"
Si l'équipe ne mentionne jamais les utilisateurs dans ses retours de sprint, elle ne construit pas un produit — elle construit de la technologie. La différence compte.
✓ Bonne réponse : "3 utilisateurs ont abandonné sur l'étape 4 de l'onboarding — on a une hypothèse sur pourquoi."
⚠ Signal d'alarme : "On n'a pas eu de remontées particulières cette semaine."
Q5
"Si on supprimait cette fonctionnalité demain, combien d'utilisateurs s'en apercevraient ?"
La question la plus redoutée — et la plus utile. Elle force à quantifier l'impact réel de ce qui est construit. Personne n'aime la réponse "personne", mais c'est parfois la réalité.
✓ Bonne réponse : "Les 40% d'utilisateurs actifs qui s'en servent chaque semaine — c'est notre feature la plus utilisée."
⚠ Signal d'alarme : "On n'a pas encore les données pour le savoir."
Q6
"Qu'est-ce qu'on ne devrait pas construire maintenant — et pourquoi on ne l'a pas encore retiré du backlog ?"
Un backlog non priorisé est une liste de bonnes intentions. Forcer l'équipe à justifier les suppressions révèle la vraie priorité — et les sujets que personne n'ose toucher.
✓ Bonne réponse : "Le module de reporting — il est là depuis 4 sprints mais aucun utilisateur ne nous l'a demandé directement. On le met en veille."
⚠ Signal d'alarme : "On va y arriver, c'est juste une question de timing."
Q7
"Qu'est-ce dont vous auriez besoin que je fasse — que je ne fais pas — pour que l'équipe avance mieux ?"
La question inverse. Elle montre que vous jouez collectif, pas superviseur. Et elle révèle les blocages organisationnels que l'équipe n'ose pas soulever d'elle-même.
✓ Bonne réponse : "Des décisions plus rapides sur les arbitrages design — on attend parfois 3 jours pour un choix qui prend 10 minutes."
⚠ Signal d'alarme : "Non, tout va bien." (après 2 secondes de silence)
"Challenger une équipe ne veut pas dire tout remettre en question. Ça veut dire ne jamais accepter une réponse qui rend impossible votre propre jugement."
Les signaux à surveiller — sans lire une ligne de code
Il n'est pas nécessaire de comprendre le code pour détecter si quelque chose va mal. Certains comportements sont lisibles à l'œil nu.
🚨 Signaux d'alarme
Les estimations glissent systématiquement de +50%
L'équipe parle de technique mais jamais d'utilisateurs
Chaque question reçoit une réponse qui nécessite une autre réunion
La démo de sprint montre du travail invisible pour l'utilisateur
"C'est compliqué à expliquer" revient souvent
Le backlog grossit plus vite qu'il ne se vide
Les métriques produit ne sont jamais mentionnées en réunion
✓ Signaux positifs
L'équipe mentionne des comportements utilisateurs concrets
Les décisions sont documentées avec leur raisonnement
On vous soumet des arbitrages, pas seulement des conclusions
La démo montre un avant/après utilisateur mesurable
L'équipe propose de supprimer des choses, pas seulement d'en ajouter
Les estimations ont une fourchette d'incertitude explicite
Le "non" est argumenté, pas défensif
Trois situations concrètes — et comment les gérer
Situation 1 — L'équipe vous dit que "c'est complexe"
C'est la réponse réflexe quand une équipe ne veut pas (ou ne sait pas) simplifier son raisonnement. "C'est complexe" est rarement faux — mais c'est presque toujours incomplet.
Échange type — Architecture technique
Founder
"Pourquoi on ne peut pas ajouter cette fonctionnalité avant la levée ?"
Dev
"C'est complexe — l'architecture actuelle ne le permet pas facilement. Il faudrait revoir plusieurs modules."
Founder — bonne réponse
"Ok. En supposant qu'on décide quand même de le faire : quel est le risque principal, et quel est l'ordre de grandeur en temps ?"
Dev — forcé à préciser
"Le risque c'est la stabilité du module de paiement. Et ça prendrait entre 2 et 4 semaines selon comment on l'aborde."
La deuxième réponse est la vraie information. La première était un refus déguisé. En posant la question "en supposant qu'on le fait quand même", vous forcez l'équipe à chiffrer plutôt que bloquer.
Situation 2 — Les délais glissent, l'équipe n'explique pas pourquoi
Le glissement de délai est normal dans le développement produit. Ce qui n'est pas normal, c'est quand il n'est pas expliqué — ou quand l'explication arrive après les faits.
Échange type — Retard non anticipé
PM
"On ne livrera pas le module cette semaine, il y a eu des complications."
Founder
"Quand est-ce que tu as su que le délai allait glisser ?"
PM
"En milieu de semaine, quand on a découvert le problème."
Founder
"Donc il y a 3 jours. Qu'est-ce qui t'a empêché de m'en parler à ce moment-là ?"
Ce n'est pas une accusation — c'est une calibration. L'objectif est d'instaurer une norme : les mauvaises nouvelles remontent immédiatement, pas au moment de la livraison ratée.
Situation 3 — L'équipe vous présente une solution sans vous avoir présenté le problème
C'est le pattern le plus courant et le plus dangereux. L'équipe arrive avec une proposition technique détaillée — et vous réalisez en milieu de présentation que vous ne savez pas exactement quel problème elle résout.
Échange type — Proposition technique
Dev Lead
"On propose de migrer vers une architecture event-driven. Ça nous donnera plus de flexibilité et de scalabilité pour la suite."
Founder
"Avant qu'on parle de la solution : quel est le problème précis qu'on a aujourd'hui, et comment tu saurais que ce problème est résolu ?"
Dev Lead — après réflexion
"Le problème concret : quand 500 utilisateurs se connectent en même temps, les notifications arrivent avec 8 secondes de retard. Ce serait résolu si ce délai passe sous 1 seconde."
Founder
"Est-ce que la migration event-driven est la seule façon de résoudre ça, ou la plus rapide ?"
Cette question seule peut économiser 3 semaines de développement. La réponse honnête est souvent "non, ce n'est pas la seule façon — mais c'est celle qu'on préfère techniquement."
Construire le bon cadre de collaboration
Au-delà des questions ponctuelles, ce qui compte c'est de créer des rituels qui rendent le challenge naturel — pas exceptionnel.
4 rituels concrets à instaurer dès maintenant
1
Le "Why before What" en début de sprint
Avant chaque sprint, l'équipe répond à une question : "Quel problème utilisateur on résout cette semaine ?" Pas "quelles features on livre". Si la réponse ne mentionne pas un utilisateur, le sprint n'est pas prêt à démarrer.
2
La règle des "mauvaises nouvelles en 24h"
Tout retard, tout blocage, tout risque identifié remonte dans les 24h. Pas à la prochaine réunion. Pas quand c'est confirmé. Dès que c'est probable. Cette règle change la culture plus que n'importe quelle réunion de bilan.
3
La démo "utilisateur réel" — pas la démo feature
En sprint review, la démo se fait toujours avec un scénario utilisateur réel — pas un parcours idéal préparé. "Montrez-moi comment un nouveau utilisateur ferait X pour la première fois." Les problèmes apparaissent immédiatement.
4
Le "kill review" mensuel
Une fois par mois, l'équipe présente ce qu'on devrait arrêter ou supprimer — pas ce qu'on va construire. Ce rituel crée une permission culturelle de supprimer. Sans ça, le backlog grossit et la complexité s'accumule silencieusement.
Ce que ça donne en pratique — avant / après
3×
plus de décisions documentées quand le founder pose des questions structurées
-40%
de sprints sans livrable visible pour l'utilisateur après 6 semaines de ces rituels
J+14
délai moyen pour voir les premiers effets sur la dynamique d'équipe
Ce qu'on observe sur le terrain
Les équipes qui subissent ces questions au départ finissent par les intégrer dans leur propre façon de travailler. Le challenge devient une norme collective — pas une surveillance.
Ce que vous ne devez jamais faire
Il y a une ligne à ne pas franchir. Challenger n'est pas micromanager. Voici les erreurs que font les founders non-tech quand ils commencent à poser des questions — et qui créent l'effet inverse.
✕
Remettre en question les choix techniques sans alternative
"Je ne suis pas sûr que React soit le bon choix" sans proposer d'alternative ni de critère d'évaluation. Ça déstabilise sans apporter de valeur.
✕
Exiger des certitudes sur des sujets incertains
"Dis-moi exactement combien de temps ça prend." Le développement produit est incertain par nature. Forcer des certitudes produit des mensonges.
✕
Changer les priorités en milieu de sprint
Challenger le plan en amont, oui. Le modifier en cours d'exécution parce qu'une idée vient de surgir, non. Le coût est invisible mais réel.
✕
Traiter les questions techniques comme des fautes
Quand un bug arrive ou qu'une estimation est ratée, la question n'est pas "pourquoi ça s'est passé" en mode tribunal — c'est "qu'est-ce qu'on change au process".
La limite
Votre rôle est de challenger la direction et les arbitrages — pas d'arbitrer les choix d'implémentation. Dès que vous êtes dans le "comment", vous avez franchi la ligne.
"Le meilleur signe qu'un founder non-tech travaille bien avec son équipe : l'équipe lui pose des questions stratégiques — pas seulement techniques."