Pourquoi la conception de produits IA est différente—et pourquoi les équipes produit doivent évoluer

Galen Low : Y a-t-il vraiment quelque chose de si différent dans le processus de développement d’un produit doté d’une fonctionnalité IA native, par rapport à d’autres produits qui se contentent d’intégrer des technologies IA existantes ?

Jyothi Nookula : Oui. Lorsque vous concevez un produit natif IA, vous faites face à trois éléments qui diffèrent. Premièrement, l’IA est fondamentalement imprévisible.

Galen Low : Quelle est la première chose que vous faites, en tant que leader, lorsque vous remarquez qu’une équipe n’a pas le même niveau de compréhension, d’appropriation, ou même d’acceptation des technologies émergentes comme l’IA ?

Jyothi Nookula : Je sépare le problème en deux aspects distincts. Le premier aspect est la compétence. Le second est la disposition. Si vous traitez un problème de disposition comme un problème de compétence, vous ne ferez qu’empirer la situation.

Galen Low : Quelles sont, selon vous, les compétences essentielles qu’un chef de produit souhaitant se démarquer dans le développement de produits IA doit absolument mettre en avant dans son CV ou son portfolio ?

Jyothi Nookula : D’abord, il faut avoir déjà conçu quelque chose avec l’IA, pas seulement en parler. La seconde chose est…

Galen Low : Bienvenue dans le podcast du Digital Project Manager — l’émission qui accompagne les responsables de livraison pour travailler plus intelligemment, livrer plus vite et mieux diriger à l’ère de l’IA. Je suis Galen, et chaque semaine nous plongeons dans des stratégies concrètes, de nouveaux outils, des frameworks éprouvés et parfois quelques histoires de tranchée du front des projets. Que vous pilotiez d’immenses projets de transformation, que vous gériez des workflows IA, ou que vous essayiez simplement de garder le chaos sous contrôle, vous êtes au bon endroit. Entrons dans le vif du sujet.

Aujourd’hui, nous parlons de l’avenir du chef de produit, de ce qu’il faut pour concevoir des produits IA, des façons dont l’IA simplifie le développement et le lancement des produits, et de ce que peuvent faire les leads lorsque leurs équipes produit présentent des disparités en termes de compétences ou d’attitudes face aux nouvelles technologies comme l’IA.

Avec moi aujourd’hui en studio, Jyothi Nookula. Jyothi possède plus de 13 ans d’expérience à la tête de l’innovation des produits et plateformes IA dans des entreprises comme Netflix, Meta, Amazon AWS et Etsy. Elle détient aussi 12 brevets en machine learning et a accompagné plus de 1 500 chefs de produit dans leur transition vers des postes liés à l’IA via son entreprise de formation Next Gen Product Manager.

Jyothi, merci beaucoup d’être avec moi aujourd’hui.

Jyothi Nookula : Bonjour à toutes et à tous. Ravie d’être ici aujourd’hui.

Galen Low : Moi aussi, je suis enthousiaste et j’attendais ce moment depuis des semaines. Lorsque nous avons discuté la première fois et que j’ai vu ton profil, je me suis dit : « waouh, Jyothi, c’est une vraie force ! » Il y a énormément de marques et de technologies dans ton parcours qui font rêver.

Et j’ai toujours un faible pour celles et ceux qui cherchent à aider la nouvelle génération dans leur métier, à gravir les échelons dans un monde de plus en plus technologique et désormais orienté IA. Et quand nous avons échangé, je me suis dit qu’on avait beaucoup en commun : je suis côté projet ; toi davantage côté produit. Mais j’ai vraiment hâte d’explorer les évolutions à venir et les enseignements tirés de ton parcours à travers les produits IA et machine learning.

Je sais que nous allons certainement dévier sur quelques tangentes, mais je suis sûr qu’elles seront très intéressantes et riches d’enseignements, donc j’espère vraiment y parvenir. Mais côté chef de projet, j’ai aussi préparé une feuille de route pour aujourd’hui. Pour commencer, je voulais évacuer dès le départ une question brûlante, un peu inconfortable mais essentielle et que tout le monde se pose.

Ensuite, j’aimerais qu’on élargisse sur trois axes. D’abord, identifier et combler les écarts de compétences dans les équipes produit confrontées à des produits intégrant des fonctionnalités d’IA et de machine learning ; ensuite explorer des exemples de l’utilisation d’outils IA dans le processus de développement produit — que ce soit en recherche, analyse de données, design, ingénierie, tests utilisateurs ou tout autre domaine ; enfin, discuter du futur du rôle du chef de produit, en abordant les éléments à inscrire dans un CV ou un portfolio pour être considéré par des groupes tels que Meta, AWS, Netflix, Etsy et d’autres grandes entreprises à la pointe de l’IA.

Jyothi Nookula : J’adore ! Ça me passionne, c’est le sujet en vogue. J’adore vraiment.

Galen Low : Parfait. Commençons alors avec cette grande question. Donc, ma question pour cadrer la discussion tourne autour de l’IA. Parce que tu as une grande expérience du développement de solutions IA et machine learning pour des géants comme Meta, Amazon, Etsy, Netflix… Ma question : y a-t-il vraiment une grande différence dans le processus de création de produits avec IA native par rapport à d’autres produits intégrant simplement de l’IA existante ?

Jyothi Nookula : Très bonne question car cela touche vraiment au cœur de ce qui change actuellement dans le développement produit. Et la réponse honnête est fondamentalement oui, mais pas de la façon dont on l’imagine. Je vais m’expliquer. Lorsque vous créez un produit natif IA, vous faites face à trois éléments qui le distinguent des logiciels traditionnels ou même des produits intégrant simplement l’IA via une API.

Le premier point, c’est l’imprévisibilité de l’IA. Dans le développement traditionnel, on écrit du code déterministe : « si telle chose se produit, alors fais ceci »… Ou, si je clique sur ce bouton, cela mène toujours à l’écran suivant. Chaque clic mène toujours au même résultat. Or, avec un produit IA natif, on travaille avec des systèmes probabilistes. Donc la même fonction IA peut réagir différemment à chaque exécution.

Cela signifie que tout le processus de QA, la gestion des cas limites, les garanties de fiabilité, tout cela doit être totalement repensé. Il ne s’agit plus seulement de vérifier si quelque chose fonctionne, mais si cela fonctionne suffisamment bien, et de manière suffisamment constante sur une distribution de résultats.

Voici le premier point fondamentalement différent : cette imprévisibilité ; déterministe versus probabiliste. Ensuite, le deuxième point, c’est que le sol change sous nos pieds : les modèles sous-jacents évoluent sans qu’on puisse les maîtriser. Par exemple, un nouveau modèle peut modifier le comportement du système.

Ce n’est pas forcément une rupture, mais cela peut changer subtilement le fonctionnement, étendre les capacités ou introduire de nouveaux modes d’échec. Et cela arrive du jour au lendemain avec la rapidité des évolutions actuelles. Contrairement aux dépendances classiques que l’on peut versionner et documenter, ici les mises à jour de modèles vont plus vite qu’on ne peut les suivre.

Et troisièmement, point essentiel, vos indicateurs de succès doivent être différents. Vous ne pouvez plus simplement mesurer si la fonctionnalité s’est exécutée avec succès. Il faut maintenant mesurer : est-ce que le résultat a été utile ? Il ne suffit pas que cela s’exécute, il faut que ce soit efficace.

Est-ce que cela répond à l’intention de l’utilisateur ? À la question qu’il a posée ? Et comment même définir « bon » pour votre cas d’usage ? Il faut donc établir une boucle de retour plus directe avec les utilisateurs et intégrer ces mécanismes d’évaluation directement dans le développement : c’est très différent du développement produit traditionnel.

Ce sont donc ces trois éléments qui changent profondément la donne. Les produits qui n’intègrent l’IA que comme une brique, par exemple en intégrant ChatGPT, peuvent rester basés sur une logique plus classique. Il y a certes des métriques de succès à surveiller, mais il existe au moins un contrat. Mais lorsqu’on construit un produit dès le départ comme natif IA, c’est tout autre chose, et c’est à ce moment-là que ces trois aspects impactent bien plus le développement produit.

Galen Low : C’est drôle, parce qu’en posant la question je m’attendais à ce que tu répondes que oui, c’est à peu près pareil avec quelques éléments en plus, mais là, c’est un vrai changement de paradigme.

J’ai adoré ton point sur la mesure de l’intention, le côté évaluation, parce qu’en gestion de projet, tout est binaire : il y a un cahier des charges, c’est oui ou non, la fonctionnalité fait ce qui est prévu, point. Mais là, il y a de l’ambiguïté, car c’est probabiliste, donc le résultat n’est jamais le même, et l’architecture de fond évolue toute seule, de façon opaque, plus vite que l’humain ne comprend. C’est très différent de la majorité des produits numériques récents. Ça fait sens. Voilà ce que je me dis en t’écoutant.

Tu as plus de dix ans d’expérience avec le machine learning et l’IA. Beaucoup découvrent seulement cela depuis deux ans avec ChatGPT, alors que cela existe en réalité depuis longtemps dans les logiciels et produits digitaux.

Et puis on se dit : parce qu’on regarde Netflix, par exemple, on peut croire que tout cela est simple, alors que non. L’algorithme, le machine learning à l’arrière-plan, la façon dont les données sont traitées, ce n’est pas juste des liens relatifs comme sur un site web. C’est une question de comportements et d’intention, et c’est très facile de se tromper. Et parfois, on ne s’aperçoit qu’on s’est trompé que lorsqu’une personne s’en plaint (exemple : « mon Netflix ne comprend rien à mes goûts parce que j’ai regardé une vidéo : maintenant il me propose dix saisons de Barney le dinosaure !»).

Jyothi Nookula : Même chose avec Instagram Reels ou TikTok. Il suffit de regarder une vidéo de ski pour se retrouver inondé de vidéos de ski. Oui !

Galen Low : Je pense qu’on prend cela pour acquis. Pour beaucoup de gens, ça a l’air facile ou anodin, alors que ce n’est pas du tout le cas. Pour aller plus loin, en plus de ton brillant parcours pour de grands noms comme Amazon, Meta, Netflix ou Etsy, tu es la fondatrice de Next Gen Product Manager, qui propose par exemple un bootcamp de 5 semaines pour passer d’un management produit classique à un management produit IA.

Le fait même que cette formation existe montre bien que les compétences traditionnelles de chef de produit ne suffisent plus. Il faut une nouvelle posture, un état d’esprit différent, davantage tourné vers le futur. Et même si tu as pu choisir tes équipes, cela reste rare que tous les membres aient exactement les mêmes compétences ou la même appétence pour l’IA et les technos émergentes. Ma question : quelle est la première chose que tu fais, en tant que leader, quand tu remarques que ton équipe n’est pas à un niveau homogène d’adoption ou d’acceptation de l’IA ?

Jyothi Nookula : Oui, c’est un vrai défi concret, que je rencontre très souvent et encore aujourd’hui. J’ai managé des équipes de toutes tailles, de 3 à 12 personnes. L’écart de compétences et de confort vis-à-vis de l’IA est, selon mon expérience, le plus large que j’aie rencontré pour une technologie ou une transformation.

Voilà ce que je fais en premier : je distingue deux problématiques. La première : la compétence (manque de savoir-faire IA). La seconde : la disposition (réticence, anxiété, scepticisme…). Il faut bien identifier laquelle on affronte, ou s’il y a un mix, car si on traite un problème de disposition comme une question de compétence, on empire la situation. Pour le déficit de compétences, ma première action est de créer un contexte partagé par la pratique, pas par la théorie. C’est ce que j’enseigne aussi dans mon bootcamp : apprendre par l’action.

Je n’envoie donc pas mon équipe en formation ou regarder des tutos, au contraire, j’intègre l’IA directement dans nos workflows réels (rédaction de comptes-rendus de rétrospective via Claude ou ChatGPT, synthèse de thématiques, recherche documentaire, comptes-rendus de recherches utilisateur, etc.), afin qu’ils voient l’utilité directe de l’outil sans avoir le sentiment d’être remplacés. Deux semaines après, en réunion, je demande : racontez-moi un cas où l’IA vous a fait gagner du temps, ou bien une idée que vous n’auriez pas eue sans elle. Ces expériences partagées servent alors de socle pour la montée en compétences.

Pour les questions de disposition (réticence, peur…), je pense qu’il faut montrer de la curiosité et non forcer les choses. En one-to-one, je demande simplement : quelle est vraiment ta préoccupation ici ? Puis je me tais et j’écoute. Cela fait émerger des préoccupations légitimes : peur de voir son expertise dévalorisée, manque de confiance dans la qualité des résultats, sentiment d’être dépassé… Ce sont de vraies inquiétudes, et on ne peut pas les balayer d’un revers de la main. Il faut alors les reconnaître, les normaliser, et proposer une voie d’évolution. Par exemple, pour quelqu’un qui craint pour la valeur de son savoir-faire, je montre comment l’IA prend en charge les tâches fastidieuses, pour qu’il/elle puisse se focaliser sur le travail à plus forte valeur ajoutée. Pour ce qui est des craintes de vérification, je propose de construire ensemble des cadres d’évaluation, afin qu’ils deviennent experts de l’assurance qualité IA.

En complément, j’identifie assez vite des « personnes ponts » : presque partout, certains membres d’équipe sont naturellement curieux, expérimentent et obtiennent des résultats avec l’IA. Je leur donne l’occasion de partager leurs retours (exemple : démonstration lors d’un stand-up ou d’une session « show and tell »). Cela favorise l’apprentissage pair-à-pair, car voir un collègue s’approprier la technologie est souvent plus convaincant qu’une injonction descendante.

Enfin — et c’est point délicat —, j’établis assez vite que la maîtrise de l’IA devient une compétence de base attendue. Je fais preuve d’empathie, je suis patiente, mais je reste ferme : ce n’est plus optionnel. Comme à l’époque où l’on devait apprendre l’agilité ou les analytics, aujourd’hui l’IA fait partie du job.

J’ai constaté que cette combinaison « fort support et exigences élevées » réduit l’anxiété. Les pires situations sont celles où les attentes sont floues et le support inexistant : cela crée de la frustration et du ressentiment. L’objectif n’est pas que tout le monde atteigne le même niveau d’un coup, mais que l’on progresse collectivement, dans un climat de sécurité psychologique avec des outils concrets.

Galen Low : J’adore. Cette séparation entre compétence et disposition est précieuse. Cela ressemble à un mélange de gestion du changement et de dynamique d’équipe, appliqué en continu. Souvent, on croit que la gestion du changement est ponctuelle, liée à un grand projet… Là, c’est la gestion du changement au quotidien, favorisant le collectif et la clarté, avec beaucoup de support et un aspect « apprentissage entre pairs » qui fait toute la différence.

Tu soulignes aussi bien les anxiétés légitimes vis-à-vis de l’IA : peur d’être à la traîne, de manquer de temps, sentiment de dévalorisation de son métier… Rien de tel, pour avancer, que de voir ses pairs l’appliquer, et d’apprendre ensemble — pas juste en théorie, mais en pratique. Et « clarifier » tout cela est essentiel. Car la question « est-ce une mode passagère que je peux ignorer ? » est tranchée : non, l’IA ne peut plus être ignorée, il faut avancer collectivement.

Jyothi Nookula : Exactement.

Galen Low : Tu parlais tout à l’heure de petites expérimentations, de pilotes, pour que l’équipe puisse manipuler de l’IA, progresser en compétence et en confiance. J’imagine que les exemples sont nombreux sur la façon dont l’IA s’intègre dans le développement de produits eux-mêmes IA. Peux-tu nous donner, peut-être, quelques exemples concrets des usages de l’IA dans la conception et le développement ?

Jyothi Nookula : Oui, bien sûr. Je peux te donner des exemples concrets qui couvrent tout le cycle de développement produit.

Galen Low : Super, je prends !

Jyothi Nookula : Dès la phase de découverte et de recherche utilisateur, l’IA nous permet de générer des insights beaucoup plus rapidement. Au lieu d’analyser pendant une semaine des dizaines d’interviews utilisateurs : on alimente les transcripts dans Claude, qui identifie patrons, contradictions et cas extrêmes.

Mais attention, il faut toujours garder un humain dans la boucle : le chercheur lit, challenge, affine les résultats. L’IA donne une excellente ébauche en une heure au lieu d’une semaine, le chercheur consacre son temps au jugement, à la pertinence des insights, à ce qui remet en question nos hypothèses.

Même chose sur les tickets support. Quand le produit est en prod, le flux support est énorme. Plutôt que de lire manuellement chaque ticket, nous analysons des milliers de conversations pour comprendre quelles sont les réelles douleurs, leurs ampleurs… L’IA fait émerger des tendances invisibles à l’œil humain à grande échelle. Cela permet de hiérarchiser les priorités, d’alimenter la roadmap.

Côté documentation ou communication, l’IA élimine le travail répétitif. On l’utilise pour rédiger drafts de spécifications, résumer des revues de sprint, produire des synthèses pour les parties prenantes. Ce ne sont que des brouillons solides, mais le chef de produit passe de 30 % de son temps à rédiger à 30 % à éditer, ce qui a bien plus de valeur.

On exploite aussi l’IA pour rendre la documentation plus accessible : quelqu’un peut demander « qu’a-t-on décidé concernant le nouveau parcours de paiement ? » et obtenir une synthèse qui croise plusieurs fils Slack, réunions et documentations.

Au final, l’IA intervient à toutes les étapes du cycle : phase de test, documentation, même la relation avec les ingénieurs : avant, le chef produit rédigeait exclusivement des PRD ; désormais, on y joint des prototypes IA, pour faciliter la recherche du product-market fit, puis transférer au développement. La PRD garde la vision, les critères d’évaluation, les scénarios, mais le prototype montre l’interaction, l’expérience utilisateur attendue. Bref, on voit l’impact partout sur le cycle produit.

Galen Low : J’adore ce point parce que justement, je parlais récemment avec des chefs de produit qui s’interrogeaient sur la disparition possible des PRD, ces fameux cahiers des charges… mais en réalité, on voit que le besoin de clarté demeure. L’IA possède le don d’accélérer la structuration de la pensée mais ne remplace pas totalement la réflexion stratégique, la vision du produit, la capacité à servir l’utilisateur…

Par ailleurs, les chefs de produit sont souvent très orientés documentation – déjà un avantage, car ils ont matière à entraîner l’IA, tandis que d’autres équipes, moins documentées, doivent s’y mettre pour en profiter. Il y a aussi ce principe de « machines à premier jet », que j’adore. Question : les équipes se contentent-elles de ce premier jet de l’IA, ou bouclent-elles les itérations, en renvoyant leur propre version éditée pour améliorer la machine ?

Jyothi Nookula : Nous appelons ça le « one-shot ». Beaucoup pensent que l’IA fonctionne en une seule passe : tu lui donnes ton contenu, tu reçois un rapport, et basta… Mais c’est rarement le cas. On obtient une ébauche prometteuse, on retravaille dessus, on y injecte sa patte, on la challenge à nouveau pour affiner. L’IA propose, tu juges, puis tu remets dans la moulinette pour avoir un feedback critique. Cela fonctionne comme un partenaire avec lequel tu raffines ton document jusqu’à obtenir un résultat satisfaisant.

Si on considère l’IA comme une boîte noire one-shot qui va tout sortir instantanément, ça ne marchera pas. Le vrai gain, c’est dans l’itération. Enseigner la méthode d’itération est facile, mais développer le « goût », la finesse du jugement, ça, c’est le travail du chef de produit.

Galen Low : J’adore la notion de « goût ». Certains chefs de produit ont l’impression de passer la moitié de leur temps à « parler à un robot » en éditant des documents, alors que le métier est très humain (entretiens utilisateurs, études qualitatives, interaction avec l’équipe…). N’y-a-t-il pas un risque de déshumanisation du métier avec autant d’IA ?

Jyothi Nookula : Je ne pense pas qu’il s’agisse vraiment de parler avec un robot : ce n’est jamais juste toi et la machine. Tu dois toujours expliquer tes besoins aux parties prenantes, aux ingénieurs… Le product manager est un pivot relationnel. Je vois l’IA comme un assistant, un partenaire de brainstorming disponible à toute heure : ce n’est pas du tout comme interagir avec un robot au sens traditionnel, mais plutôt un renfort pour démarrer, itérer et trouver le bon angle de solution.

Galen Low : Pour jouer un peu l’avocat du diable… Tu as travaillé dans des entreprises où, j’en suis certain, on t’a demandé pourquoi ne pas tout automatiser ? Pourquoi garder un humain dans la boucle ? Peut-on vraiment tout confier à une IA : lecture des tickets, priorisation, développement, release… sans aucune intervention humaine ? A-t-on vraiment besoin d’un humain dans le flux ? Et comment argumenter, notamment face aux grosses entreprises tech, que la technologie ne doit pas tout régir, qu’il faut rester centré sur l’utilisateur ?

Jyothi Nookula : C’est une question fréquente, même chez mes apprenants : tout le monde veut faire de l’IA pour l’IA. On a tendance à oublier l’utilisateur, le problème qu’on veut résoudre, et à démarrer par la techno, ce qui est contre-productif.

C’est difficile de résister car la pression institutionnelle va dans le mauvais sens. Entre les dirigeants qui ne jurent que par l’IA, les investisseurs qui réclament une stratégie IA à chaque réunion, et les ingénieurs ultra motivés, la tentation est grande. Ce que je fais, c’est revenir aux fondamentaux produits : partir de l’utilisateur et du problème, jamais de la techno. Je répète sans cesse « l’utilisateur avant l’algorithme ».

Quand on me propose une nouvelle techno (multimodal, voix…), je ne dis pas non tout de suite, mais je demande : « quel problème cela résout-il ? » Et j’invite à décrire une journée type de l’utilisateur, à identifier à quel moment cela intervient, et ce qu’il ferait autrement. Là, il se passe trois choses possibles. Soit on se rend compte qu’on cherche un usage à une solution, et l’idée s’essouffle d’elle-même. Soit il existe bel et bien un problème, mais la meilleure solution n’est pas nécessairement l’IA, parfois c’est une question de design ou de processus, voire d’une version déterministe plus simple. Troisième cas : c’est le « jackpot », l’IA est réellement bénéfique et là naît l’innovation.

Chez Amazon, on cultive la méthode du « working backwards » : on commence par rédiger le communiqué de presse du produit futur (avec impact, témoignage utilisateur), ce qui force à préciser l’utilité réelle et évite de tomber dans le fantasme. Même face à un top management intransigeant, je tente au moins d’orienter la démarche vers une problématique concrète : « ok, on y va, mais visons une vraie douleur utilisateur, pas la facilité d’usage de la techno pour la techno ».

Au début, je pensais devoir protéger la vision produit contre les distractions ; en réalité, il faut canaliser l’énergie positive et l’enthousiasme pour les faire converger vers des vrais bénéfices utilisateurs. C’est dans cet esprit qu’il faut raisonner : utilisateur, problème, pas techno d’abord. Personne ne commence sa journée en se disant « j’ai ouvert un Word, que vais-je écrire ? »… C’est la même chose.

Galen Low : Où est Clippy quand on a besoin de lui ? Franchement, c’était une vraie leçon tactique pour qui veut naviguer dans la politique produit ! Ta vision du rôle est très précieuse : beaucoup de responsables produits se voient comme les gardiens, ceux qui tiennent la porte, qui imposent des garde-fous… mais apprendre à canaliser l’énergie et à fédérer autour du problème utilisateur génère de bien meilleurs résultats. J’aime l’idée de ne pas passer son temps à dire « non », mais d’être constructif et orienté solution, même quand la décision semble déjà prise. Travail collaboratif, clarté… Et le coup du communiqué de presse, je valide à mille pourcent : c’est le meilleur outil pour se forcer à penser à l’impact et au sens du produit, pas simplement à sa livraison. Je m’en inspirerai !

Jyothi Nookula : Ce principe du communiqué de presse, je l’utilise encore après AWS, il reste très utile et donne du recul.

Galen Low : J’adore, c’est très pertinent.

J’aimerais conclure sur l’avenir, parce qu’on le pressent, le métier de chef de produit est en transformation. Les produits changent, les méthodes, les outils, les attentes en matière de compréhension technique, business, stratégie de livraison aussi. Quelles sont, selon toi, les 3 ou 4 atouts majeurs qui feront sortir du lot un chef de produit IA sur son CV/portfolio ?

Jyothi Nookula : Merci de poser cette question : c’est très concret. À mes yeux, le regard sur les CV a radicalement changé depuis deux ans.

Ce qui me fait vraiment retenir une candidature, c’est d’abord la preuve qu’on a vraiment réalisé quelque chose avec l’IA, pas juste en avoir parlé. Comme recruteuse, je cherche quelqu’un à placer, pas un chercheur : la personne doit avoir livré une fonctionnalité ou un produit IA. Pas juste « j’ai bossé dans une équipe qui utilisait l’IA » ou « j’ai contribué à une stratégie » : je veux savoir quel problème vous avez résolu avec cette IA, ce qu’elle faisait concrètement, comment vous l’avez mesurée, quelles surprises dans l’apprentissage. Pour ceux qui n’ont pas encore livré de produit IA, je conseille justement de construire un projet côté, c’est ce qu’on fait dans mon bootcamp – portfolio à la clé.

Mais il faut le transformer en vrai produit : ne pas s’arrêter à « j’ai fini, je ferme l’ordi » mais le faire tester par des amis ou la communauté, récolter des feedbacks, améliorer le produit, aller jusqu’à facturer un euro (ou cinquante centimes) si besoin : créer les conditions d’un vrai produit apporte bien plus qu’écrire « j’ai travaillé sur un projet IA ». Vous pouvez construire cela hors job officiel – l’important, c’est la démarche.

Ensuite, important aussi : prouver sa culture technique. Pas besoin d’être ingénieure ML ou de coder, mais il faut prouver qu’on sait dialoguer sérieusement avec les ingénieurs, comprendre le fonctionnement de ces systèmes. Cela peut apparaître dans le portfolio via des cadres d’évaluation, test A/B, choix d’architecture (latence versus qualité, coût versus performance…), ou même les termes employés. Si je lis « j’ai utilisé l’IA pour améliorer l’expérience utilisateur », cela ne me dit rien. Mais si vous expliquez que vous avez implémenté une architecture RAG pour réduire les hallucinations de réponses, augmenté la précision de X à Y, là, j’y vois clair.

La question que je pose souvent : pouvez-vous expliquer à un ingénieur pourquoi il faut utiliser la technique A plutôt que B pour ce cas ? Ou expliquer à un décideur business pourquoi la décision technique influence les résultats business ? Le rôle du chef produit IA est précisément de traduire les possibles techniques en impacts business, et inversement.

Enfin, il faut être à l’aise avec l’incertitude et l’itération rapide. Les produits IA évoluent vite, modèles qui mutent, besoin de prototyper, tester, apprendre en continu… Cela doit se voir dans le CV : mentionnez, par exemple, que vous avez lancé un produit « from zero to one », ou travaillé en contexte ultra agile. Même des projets auto-dirigés deviennent alors des preuves de qualités recherchées.

Ce que je ne recherche pas : du jargon ou l’affichage de certifications en pagaille (« passionné par l’IA », buzzwords, etc.). Ce qui m’intéresse, c’est la vitesse d’apprentissage, la capacité à aller en profondeur, à comprendre comment tout s’articule — et aujourd’hui tout le monde peut progresser côté IA, même sans expérience directe : rien n’empêche de se lancer. On peut écrire sur ses propres apprentissages, documenter ses blocages et résultats, publier des études de cas, etc. Plus de barrière technique, tout le monde cherche, ce qui différencie c’est ceux qui agissent, pas ceux qui attendent la permission.

Galen Low : C’est tellement bien résumé ! J’entends souvent « je ne suis pas développeur, donc la technique n’est pas mon problème » alors qu’il y a ce middle-ground : il faut savoir traduire le métier en technique et inversement, savoir où sont les points de friction, anticiper, comprendre où l’on va. Et ça, ce n’est pas réservé à ceux qui ont bossé chez les « grands », il faut le prouver, montrer la logique, la rapidité d’adaptation, la maîtrise du flou – pas simplement indiquer avoir bossé chez “Untel”.

Jyothi Nookula : C’est pour ça que je dis : n’attendez pas, lancez-vous – il n’y a quasiment plus d’obstacles maintenant.

Galen Low : Jyothi, un immense merci pour ce moment. C’était passionnant. Avant de te laisser, où peut-on en savoir plus sur toi ?

Jyothi Nookula : Vous pouvez me retrouver sur LinkedIn sous Jyothi Nookula. Rendez-vous aussi sur nextgenproductmanager.com pour découvrir mes formations sur le management de produits IA, l’IA agentique et le PM Accelerator.

Galen Low : Parfait, je mettrai également ces liens en description ou en notes de l’épisode. Jyothi, encore merci !

Jyothi Nookula : Merci beaucoup, ce fut un vrai plaisir !

Galen Low : Voilà, c’est tout pour cet épisode du Digital Project Manager Podcast. Si cette discussion vous a plu, abonnez-vous où que vous soyez. Et pour encore plus d’études de cas, tactiques et playbooks, direction thedigitalprojectmanager.com. À bientôt, et merci d’avoir écouté.