Produit
Founder non-tech : comment challenger votre équipe produit sans être développeur
Vous ne savez pas coder. Ça ne vous empêche pas de savoir si votre équipe fait du bon travail — ou si elle vous noie sous la complexité pour éviter les questions qui dérangent
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.
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
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”.
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)
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
✓ Signaux positifs
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
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é
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
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
- 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.
- 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.
- 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.
- 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
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".
Voir l’offre produit d’Octofact →