Un fondateur technologique et ex-VP Produit affirme que l’IA aggrave les équipes produit — au lieu de les améliorer

Adam Root a occupé des postes de VP Produit dans diverses entreprises technologiques. Il est actuellement le fondateur de Root Ventures, où il conçoit des produits SaaS axés sur les workflows.

Nous nous sommes entretenus avec Adam pour comprendre comment l’IA transforme le cycle de vie des produits — et comment elle rend en fait certaines équipes moins performantes. Voici ce qu’il nous a raconté.

L’IA rend les équipes produit moins efficaces

L’IA rend la plupart des équipes produit moins performantes, pas meilleures — car elle supprime la friction qui protégeait auparavant les équipes des mauvaises décisions.

Au cours des 17 dernières années, j’ai développé des plateformes SaaS, piloté des initiatives autour de l’IA et obtenu des résultats mesurables, notamment en passant de 20 k$ à 400 k$ de MRR et en générant un impact à l’échelle entreprise. Au début de ma carrière, je pensais que le plus difficile était de construire, livrer des fonctionnalités, faire croître les équipes et exécuter la roadmap. Ce que j’ai compris, surtout ces dernières années, c’est que le vrai défi est de transformer l’ambiguïté en conviction. L’IA a rendu cette distinction impossible à ignorer. 

Aujourd’hui, n’importe qui peut générer un prototype ou livrer rapidement en utilisant des outils d’IA, mais la plupart des équipes ont encore du mal à transformer cela en véritable traction. Je constate régulièrement que d’excellentes équipes techniques développent plus vite, mais sans une thèse produit claire. Elles ajoutent de l’IA à des workflows qui n’ont jamais été conçus pour réussir. Le résultat est plus de production, mais pas plus d’impact.

Cette prise de conscience a profondément changé mon approche du leadership produit. Je considère désormais chaque produit comme un système de vérité, et non comme un ensemble de fonctionnalités. Tout commence par une compréhension approfondie du problème, sa validation par des preuves, et l’enchaînement des décisions afin de créer du levier. Ce n’est qu’alors que l’IA devient un véritable multiplicateur. Sans cette base, elle ne fait qu’accélérer le bruit.

Aujourd’hui, je me concentre donc moins sur les outils et davantage sur la création de clarté, l’alignement des équipes autour de ce qui compte, pourquoi cela compte, et comment cela génère des résultats. Parce que quand le système est juste, l’exécution est exponentielle.

Construire un portefeuille natif IA

En ce moment, je développe un petit portefeuille de produits SaaS natifs IA et orientés workflow dans divers domaines, chacun conçu pour s’intégrer au cœur des comportements réels des utilisateurs, et pas seulement pour ajouter des fonctionnalités à l’existant.

Sotia est un système d’intelligence basé sur la donnée comportementale, à commencer par Slack, qui aide les dirigeants à comprendre la santé de l’exécution en temps réel. Il traduit les schémas de communication en signaux sur l’alignement, la vélocité des décisions et le risque, créant ainsi une nouvelle couche entre l’activité brute et la vision stratégique des dirigeants.

En parallèle, je construis VowVista, une plateforme marketplace dans le domaine des lieux de réception de mariage, qui vise à apporter de la confiance dans la prise de décision des acheteurs de la génération Z. Elle s’attaque à un achat fragmenté et chargé d’émotions en combinant transparence, données structurées et workflows guidés pour aider les utilisateurs à passer de l’exploration à l’engagement.

Parallèlement à tout cela, je continue à développer des plateformes natives IA pour le secteur du bâtiment et les opérations terrain, où nous captons des entrées multimodales (voix, photo, vidéo) directement sur le terrain pour les transformer en informations structurées et actionnables pour les opérateurs et dirigeants.

Sur l’ensemble de ces projets, le fil conducteur est de concevoir des produits qui fonctionnent comme des systèmes de référence et d’intelligence, pensés pour des workflows réels, avec un modèle de livraison associant itération rapide et fiabilité niveau production.

Pourquoi les leaders produit doivent se concentrer sur le système, pas l’IA

L’IA n’est pas le produit. Ce qui l’entoure, oui.

La plupart des équipes commencent par se concentrer sur le modèle, la fonctionnalité ou la capacité technique. Mais en pratique, le modèle est le moins différenciant et souvent la partie la plus facile. Le vrai travail est tout ce qui se trouve autour : la donnée, l’intégration du workflow, l’UX, le modèle de confiance, et la façon dont la sortie génère une vraie décision ou action.

Si vous ratez cette étape, l’IA rendra votre produit impressionnant mais pas utile. Vous livrerez des fonctionnalités qui font bonne impression en démo, mais ne seront pas adoptées, car elles ne sont pas intégrées dans le quotidien ou la prise de décision réelle des utilisateurs.

Si vous faites bien les choses, l’IA devient un multiplicateur. Elle transforme les entrées désorganisées en insights structurés, réduit la friction dans les workflows quotidiens, et crée du levier à tous les étages du système.

Si j’avais su cela plus tôt, j’aurais évité de surinvestir dans « l’intelligence » avant de valider le flux de travail. Dans certains cas, nous avions construit des fonctionnalités impressionnantes qui fonctionnaient techniquement mais qui ne changeaient pas les habitudes des utilisateurs car elles n’étaient pas intégrées à la manière réelle d’exécuter le travail. Nous avons dû revenir en arrière et tout repenser autour du flux de travail, et non du modèle.

Comment des systèmes fondés sur les preuves peuvent améliorer l’exécution

J’ai changé d’approche : je construis désormais des systèmes fondés sur les preuves avant même d’écrire la moindre ligne de code — en utilisant l’IA comme couche de synthèse et de validation dès le début du processus.

Auparavant, même les meilleures équipes passaient assez vite de la découverte à la rédaction des spécifications. Ce modèle ne fonctionne plus dans un monde dopé à l’IA, car le coût de la construction a énormément baissé. Vous pouvez générer et livrer des solutions plus vite que vous ne pouvez valider leur utilité. Cela crée un nouveau mode d’échec : des équipes mettent à l’échelle les mauvaises idées à une vitesse fulgurante.

La découverte doit désormais devenir une fonction continue et pilotée par le système, et non une simple phase. Cela implique :

• Agrégation de signaux réels à grande échelle : comportements utilisateurs, données de support, analyses win-loss, retours qualitatifs
• Utilisation de l’IA pour synthétiser les motifs à travers ces données, et pas seulement les résumer
• Cartographie explicite des problèmes avec les flux de travail et mesure de l’efficacité du produit à y répondre
• Revalidation continue des hypothèses à mesure que de nouvelles données arrivent

Par exemple, je lance des invites structurées sur plusieurs sources de données pour faire remonter les problématiques récurrentes, les relier à des flux de travail, et vérifier explicitement si le produit les résout réellement. Ce processus remet souvent en cause ou transforme radicalement les idées initiales avant même qu’elles n’atteignent le design ou l’ingénierie.

Ce qui a changé, c’est la qualité de nos convictions. Nous construisons moins de choses, mais ce que nous réalisons est bien mieux aligné sur de vrais problèmes. Cela transforme aussi la dynamique interne : au lieu de débattre d’opinions, nous réagissons à des preuves synthétisées. Pour moi, l’IA sert donc moins à accélérer l’exécution qu’à améliorer la justesse de nos décisions sur ce que l’on choisit d’exécuter.

Comment l’IA condense tout le flux de signaux jusqu’à la mise en production

Voici un flux de travail piloté par l’IA que j’utilise de bout en bout pour passer du signal utilisateur brut à une boucle produit livrée et validée.

Tout commence par l’agrégation des signaux. Je récolte des données qualitatives et comportementales, incluant des entretiens avec des couples, des discussions sur Reddit, des avis sur des lieux, des points d’abandon dans le tunnel, et des questions entrantes. Au lieu d’examiner ces sources une par une, j’utilise l’IA pour synthétiser l’ensemble, repérer les problèmes récurrents, leur fréquence, et localiser où les utilisateurs sont bloqués dans leur processus de décision.

Ensuite, je structure les problèmes. L’IA aide à regrouper ces signaux en énoncés de problème clairs, attachés à des moments spécifiques du flux de travail. J’évalue alors la pertinence de ces problèmes en me demandant : « Ce problème est-il fréquent, douloureux et le produit peut-il réellement le résoudre ? »

Vient ensuite la phase d’élaboration des solutions. J’utilise l’IA pour explorer rapidement différentes façons de résoudre le problème : pas seulement des fonctionnalités, mais aussi des changements sur les modes de travail. L’enjeu est de générer rapidement plusieurs approches, puis de retenir celle qui correspond le mieux aux comportements utilisateurs.

Puis, nous passons au développement et à l’instrumentation. À l’aide d’outils de développement assistés par l’IA, nous passons du concept à une version fonctionnelle rapidement, en intégrant le suivi dès le départ : nous observons si les utilisateurs adoptent le nouveau flux de travail, où ils décrochent, et si leur confiance ou leur progression s’améliore.

Après cela, le tout devient une boucle d’apprentissage. L’IA analyse les usages, les retours qualitatifs, les cas limites pour distinguer ce qui fonctionne ou non. Nous vérifions si le changement a réellement modifié les comportements, pas uniquement si les utilisateurs ont interagi avec la nouveauté.

Enfin, cette boucle alimente l’itération ou la suppression. Si le flux améliore les résultats, nous l’élargissons. Sinon, nous le modifions ou le retirons rapidement.

Claude, connecté à mes données produits et aux signaux utilisateurs, gère la majeure partie de ce flux de travail.

Comment l’IA peut donner un faux sentiment de confiance

Le meilleur résultat que je constate avec l’IA, c’est une accélération majeure vers la clarté. L’IA a comprimé en quelques heures un travail qui prenait autrefois des jours, en particulier pour la phase de découverte, de synthèse et de définition initiale du produit. Je peux passer en revue bien plus d’informations, repérer les tendances rapidement, et mettre à l’épreuve les idées avant que l’équipe n’y consacre des ressources. Cela a mené à un meilleur cadrage initial, à moins d’idées faibles qui se retrouvent dans les discussions de feuille de route, et à un alignement renforcé entre produit, design et ingénierie.

Le passage à la production de produit s’en trouve lui aussi accéléré. Cette dernière année, j’ai utilisé des workflows assistés par l’IA pour passer du concept au produit fonctionnel bien plus vite qu’avec les cycles classiques. Cela inclut le passage du cadrage des problèmes à l’architecture, aux PRDs, et à un logiciel utilisable en une fraction du temps. Et le bénéfice n’est pas qu’une question de rapidité : c’est la possibilité de tester plus tôt des flux de travail réels, ce qui accélère l’apprentissage.

Ce n'est pas que du positif, cependant. L’IA peut créer une fausse confiance. Les équipes peuvent confondre une présentation soignée avec la qualité du produit. Un prototype paraît convaincant, la spécification semble exhaustive, tout le monde a le sentiment que des progrès sont réalisés, même lorsque le flux de travail sous-jacent, le modèle de confiance ou le besoin utilisateur n’est toujours pas résolu. J’ai aussi constaté que l’IA pouvait augmenter le bruit lorsqu’elle est utilisée sans une forte thèse produit. Elle peut générer plus d’idées, plus de textes, plus de tickets et plus de documents que ce qu’une équipe peut raisonnablement évaluer, ce qui peut en réalité aggraver la priorisation.

Adam partage

Le meilleur résultat de l’IA que je constate est une nette augmentation de la rapidité vers la clarté. L’IA a comprimé des tâches qui prenaient auparavant des jours en quelques heures, surtout lors de la découverte, de la synthèse et de la définition initiale du produit.

Où l’IA montre ses limites dans le produit

Là où l’IA n’a clairement pas répondu à mes attentes, c’est dans l’amélioration radicale du discernement produit et de l’impact durable du produit.

Je pensais au départ que l’IA améliorerait de façon significative la priorisation et la qualité des feuilles de route en rendant les tendances évidentes. Elle aide effectivement à faire ressortir certains schémas, mais elle ne résout pas ce qui est réellement important. Le plus difficile reste d’interpréter les compromis, de comprendre les effets de second ordre et de s’engager dans une direction incertaine. L’IA apporte des informations dans ce processus, mais ne le remplace pas. Je n’ai pas encore vu l’IA produire systématiquement de meilleures décisions produits par elle-même.

Elle est également en retrait pour générer une adoption réelle. Les fonctionnalités d’IA se prêtent souvent à des démonstrations spectaculaires, mais cela ne se traduit pas par une utilisation récurrente à moins qu’elles ne soient profondément intégrées dans les flux de travail réels. J’ai vu des équipes lancer des capacités d’IA impressionnantes que les utilisateurs essaient une fois sans jamais revenir, simplement parce que le produit ne modifiait pas leurs habitudes ni ne s’intégrait à la façon dont ils travaillent.

Un autre point faible concerne la réduction de la complexité. Je pensais que l’IA simplifierait la manière dont les produits sont conçus et exploités, mais dans de nombreux cas, elle introduit de nouvelles couches telles que la logique des prompts, les cas limites, les défis d’évaluation et la confiance à établir. Au lieu de supprimer du travail, elle le déplace vers de nouveaux domaines qui nécessitent toujours une discipline rigoureuse en produit et en ingénierie.

Pourquoi la responsabilité doit rester humaine

J’utilise largement l’IA partout où l’échelle et la reconnaissance des schémas sont importantes, et je garde l’humain dans la boucle partout où le jugement, le risque ou le goût influencent le résultat.

Côté IA, je m’appuie surtout sur elle lors de la découverte et de la synthèse. Je vais fournir des transcriptions, des tickets de support, des données de gains-pertes et des signaux comportementaux pour identifier les problèmes récurrents, quantifier leur fréquence, et associer ces problèmes aux flux de travail. Elle est aussi utile pour une priorisation précoce, non pas pour prendre des décisions, mais pour mettre à l’épreuve les hypothèses en mettant en avant les compromis, les effets de second ordre et les alternatives auxquelles je n’aurais pas pensé. Lors des expérimentations, l’IA aide à générer des hypothèses, à rédiger des variantes et à analyser rapidement les résultats, surtout face à de gros volumes de retours qualitatifs.

Là où je garde les choses explicitement humaines, c’est au niveau de la conviction et de l’engagement. Les décisions de priorisation finales, la planification de la feuille de route, et ce que nous décidons de ne pas développer restent de la responsabilité de l’équipe dirigeante et moi-même. Il en va de même pour les choix UX qui exigent du goût, de la confiance et une sensibilité émotionnelle. Les arbitrages techniques restent également dirigés par l’humain, car ils nécessitent une vision à long terme des systèmes, une tolérance au risque et la prise en compte de contraintes organisationnelles qu’une IA ne peut pas totalement intégrer.

La raison est simple : l’IA excelle pour condenser l’information et élargir l’espace des solutions, mais elle n’assume pas les conséquences. Le leadership produit, en fin de compte, consiste à prendre des décisions irréversibles ou très coûteuses dans l’incertitude. Cette responsabilité doit impérativement rester humaine.

Pourquoi les leaders produit doivent se méfier d’une fausse confiance à grande échelle

Les leaders produit sous-estiment souvent le risque de fausse confiance à grande échelle.

Les systèmes d’IA sont très efficaces pour produire des résultats qui semblent corrects, même lorsqu’ils ne le sont pas. Le danger n’est pas l’échec évident. C’est l’exactitude plausible. Quelque chose qui paraît juste, semble confiant, mais est inexact de manière difficilement décelable.

À petite échelle, un utilisateur pourrait s’en apercevoir. À l’échelle d’un produit, cette même erreur se répète à travers des milliers d’interactions, influençant silencieusement les décisions, les processus et les résultats.

J'ai constaté cela dans des domaines tels que l'interprétation de documents, les recommandations et l'automatisation des workflows. Le système fonctionne suffisamment bien la plupart du temps pour que les utilisateurs commencent à s'y fier, mais les véritables risques se cachent dans les cas limites. Et ce sont souvent ces cas-là qui portent les conséquences les plus graves.

Ce qui rend cela particulièrement dangereux, c’est que les réflexes produits traditionnels ne le détectent pas. On ne constate ni abandon, ni plantage. On observe de l’engagement. Le produit "fonctionne". Jusqu’à ce qu’il ne fonctionne plus.

La solution n'est pas seulement de meilleurs modèles. Il s’agit de concevoir pour la confiance et la vérification :

• Montrer des preuves, pas seulement des réponses
• Exposer la confiance et l'incertitude
• Créer des points de contrôle humains clairement définis
• Instrumenter pour détecter quand le système se trompe, pas seulement quand il est utilisé

Le risque, c’est de supposer que la précision croît de manière linéaire avec l’utilisation. En réalité, le risque s’accumule plus vite que l’exactitude.

Comment le jugement de l’IA peut s’affaiblir

L’IA connaît ses plus grandes difficultés lorsque le produit doit comprendre les enjeux humains, l’ambiguïté, et le risque d’erreur — pas seulement générer une réponse plausible.

Un bon exemple se trouve dans les workflows liés à la conformité ou à la confiance élevée. J’ai travaillé sur des concepts produits où l’IA peut extraire des informations de documents, signaler des problèmes et recommander les prochaines actions. Sur le papier, cela semble être un cas d’usage idéal pour l’IA. En pratique, la difficulté réside dans le fait que le modèle peut fournir une réponse avec une grande assurance tout en omettant un contexte clé, mal lire une clause, ou ne pas comprendre pourquoi une exception a plus d’importance qu’une autre.

Cela crée immédiatement un problème de confiance. L’utilisateur ne se demande pas « Ce résultat est-il impressionnant ? » Il s’interroge plutôt : « Puis-je m’appuyer sur ce résultat sans générer de risques ultérieurs ? »

Ce que j’ai appris, c’est que l’IA a souvent un jugement faible lorsque :

• Le contexte est partiel
• Les conséquences d’une erreur sont asymétriques
• L’utilisateur a besoin d’une explication, pas seulement d’un résultat

Comment l’IA restructure les équipes

L’IA a changé la forme de mes équipes produit, passant de silos basés sur les rôles à des équipes plus réduites, intégrées et orientées système.

Par le passé, les équipes étaient organisées autour de transitions claires : le produit définit, le design conçoit, l’ingénierie construit, et la data analyse. Ce modèle s’effondre quand l’IA compresse l’exécution et introduit des systèmes probabilistes nécessitant des boucles de rétroaction serrées.

Désormais, je privilégie moins de personnes capables d’opérer sur plusieurs domaines. Les product managers vont plus loin dans la data, la conception de prompts, et la logique des workflows. Les ingénieurs sont plus proches du problème et du contexte utilisateur, pas seulement de l’implémentation. Le design porte moins sur des écrans statiques et plus sur les interactions, la confiance, et la manière dont le système réagit dans l’incertitude ou l’erreur.

J’ai également observé l’émergence de nouvelles responsabilités plutôt que de nouveaux rôles à part entière. Parmi celles-ci :

• Prendre en charge le « comportement du système » dans les cas limites, pas seulement sur le chemin idéal
• Définir des seuils de confiance et des moments d’intervention humaine
• Gérer la qualité des données et les boucles de retour comme des préoccupations produit de premier ordre

Comment les responsables produits doivent utiliser l’IA

Mon conseil est simple : n’utilisez pas l’IA pour aller plus vite. Utilisez-la pour avoir plus souvent raison.

Actuellement, la plupart des équipes cherchent la rapidité, plus de fonctionnalités, des cycles plus courts, des résultats plus rapides. C’est l’avantage évident. Mais la vitesse sans clarté ne fait qu’accélérer les erreurs.

Le conseil d’Adam

Mon conseil est simple : n’utilisez pas l’IA pour aller plus vite. Utilisez-la pour avoir plus souvent raison…Le vrai changement est là : la contrainte n’est plus la construction, c’est le jugement.

Le vrai changement est là : la contrainte n’est plus la construction, c’est le jugement.

Ainsi, en tant que responsable produit, votre rôle devient moins celui d’accélérer l’exécution et davantage celui de :

• Définir les bons problèmes
• Ordonner les décisions
• S'assurer que ce qui est construit change réellement le comportement des utilisateurs

Utilisez l’IA pour élargir votre réflexion, synthétiser les signaux et mettre vos idées à l’épreuve. Mais ne déléguez pas les décisions difficiles. C’est là que réside la véritable valeur.

Repensez également la manière dont votre équipe fonctionne :

• Considérez la découverte comme un processus continu, et non comme une phase.
• Concevez pour instaurer la confiance, pas seulement la fonctionnalité.
• Construisez des systèmes, pas des fonctionnalités.

Et surtout, résistez à la tentation de négliger la réflexion difficile.

Suivez-nous

Vous pouvez suivre Adam Root sur LinkedIn alors qu’il continue de développer Sotia, VowVista et les autres produits SaaS de son portefeuille.

D’autres interviews d’experts à venir sur The CPO Club !