Depuis quelques mois, le terme de Product Builder s’impose dans les conversations produit. Derrière ce concept, une promesse : permettre à davantage de profils de concevoir, prototyper et construire des solutions grâce à l’IA, sans dépendre systématiquement d’autres équipes. Mais au-delà des débats théoriques sur l’avenir du métier de Product Manager, certaines entreprises ont déjà commencé à expérimenter.
C’est le cas de Poppins. L’entreprise développe des thérapies numériques destinées aux enfants présentant des troubles du neurodéveloppement, notamment des troubles du langage. Dans un contexte où les besoins sont importants et les ressources médicales limitées, la capacité à tester rapidement de nouvelles solutions est devenue un enjeu stratégique.
Pour Julie Prieur, Head of Product chez Poppins, le Product Builder ne désigne pas simplement un PM qui sait coder avec l’aide de l’IA. Le sujet est plus large. Il touche à la façon dont les organisations sont structurées, à la répartition des responsabilités et à l’autonomie accordée aux équipes.
Cette conviction ne s’est pas construite à partir d’une réflexion théorique. Elle est née d’une série d’expérimentations menées ces derniers mois au sein de l’entreprise.
Tout a commencé par un défi lancé à l’ensemble des équipes
En début d’année, Poppins lance un exercice inhabituel : chaque collaborateur est invité à identifier un problème concret dans son quotidien et à construire une solution à l’aide des outils d’IA générative. Le défi concerne les équipes produit, mais aussi la finance, le customer care, les orthophonistes qui travaillent avec les enfants et, plus largement, l’ensemble des métiers de l’entreprise.
L’idée est d’abord de mettre les équipes en situation de pratique : manipuler les outils, comprendre ce qu’ils permettent, identifier leurs limites, avant même d’imaginer de nouvelles fonctionnalités pour les utilisateurs.
« On voulait que chacun se confronte directement aux outils, quel que soit son métier. »
L’exercice permet de dépasser rapidement les discussions abstraites sur l’IA. Les équipes découvrent concrètement ce qu’il est possible de construire par elles-mêmes et identifient les limites des approches traditionnelles basées sur une forte spécialisation des rôles.
D’après Julie, cette première étape agit comme un révélateur. Beaucoup de sujets qui nécessitaient auparavant plusieurs interlocuteurs peuvent désormais être explorés, testés ou validés beaucoup plus rapidement.
Le Product Builder comme réponse à un problème bien connu des équipes produit
Cette expérimentation conduit progressivement l’équipe à remettre en question certaines habitudes organisationnelles.
Pendant des années, les organisations produit ont gagné en expertise en spécialisant les rôles : Product Manager, Product Designer, UX Researcher, développeur frontend, développeur backend, QA. Cette évolution a apporté de nombreux bénéfices. Mais elle a également multiplié les dépendances.
« On passe un temps fou à synchroniser des roadmaps, des agendas et des priorités au lieu de résoudre les problèmes. »
Selon Julie, c’est précisément là que le concept de Product Builder devient intéressant. L’enjeu n’est pas qu’une seule personne réalise l’ensemble du travail. Il s’agit plutôt de permettre à chacun d’aller beaucoup plus loin dans l’exécution avant d’avoir besoin de solliciter d’autres équipes. Une idée peut être explorée, matérialisée sous forme de prototype, confrontée à des utilisateurs et parfois même testée sur le terrain sans mobiliser immédiatement une chaîne complète d’intervenants.
Cette autonomie change profondément la dynamique de travail. Elle réduit les temps d’attente et rapproche davantage les équipes du problème qu’elles cherchent à résoudre.
Transformer une équipe sans faire disparaître les expertises
Quelques mois après cette première expérimentation, Poppins décide d’aller plus loin en appliquant cette logique de Product Building à une équipe produit web. Poppins ne veut pas supprimer les expertises existantes. Les développeurs restent développeurs, les Product Designers conservent leur rôle, et chacun est encouragé à intervenir plus largement dans le cycle de création : cadrer, prototyper, tester, construire, ou contribuer plus tôt à des étapes qui relevaient auparavant d’autres expertises.
Cette évolution s’accompagne également de la création d’une équipe transverse chargée d’accompagner les autres métiers de l’entreprise dans leurs projets liés à l’IA. Pour Julie, cette démarche s’inscrit dans un mouvement plus large d’hybridation des métiers. Elle rappelle que les frontières ont déjà commencé à s’effacer depuis plusieurs années. Les Product Designers couvrent aujourd’hui des sujets qui étaient autrefois répartis entre UX, UI et parfois même copywriting. Les développeurs full-stack ont brouillé les distinctions historiques entre frontend et backend.
Le Product Builder apparaît finalement comme une étape supplémentaire dans cette évolution.
Les compétences qui deviennent réellement différenciantes
Si davantage de collaborateurs peuvent désormais construire eux-mêmes des solutions, quelles compétences restent véritablement stratégiques ? Selon Julie, la réponse se trouve moins dans la maîtrise des outils que dans la capacité à créer de l’impact.
« On va de moins en moins te demander comment tu as fait. On va surtout te demander ce que tu as amélioré. »
Les activités de rédaction, de cadrage ou même certaines analyses deviennent progressivement assistées par l’IA. En revanche, identifier les bons problèmes, comprendre les enjeux business et mesurer l’impact restent des compétences essentielles. La culture data prend également une place grandissante.
« Je pense qu’avant on pouvait être PM sans vraiment aimer la data. Ça devient beaucoup plus compliqué. »
Dans un environnement où construire devient plus accessible, la valeur se déplace progressivement vers la capacité à prendre les bonnes décisions.
Une transformation qui concerne aussi les managers
Cette évolution ne touche pas uniquement les équipes opérationnelles. D’après Julie, les managers doivent eux aussi expérimenter ces nouveaux outils.
« Un CPO qui dirait aujourd’hui qu’il n’a pas ces outils sur sa machine, ça me paraît compliqué. »
Au-delà de comprendre la technologie, il s’agit aussi de conserver un langage commun avec les équipes et d’être capable d’évaluer les nouvelles façons de travailler qui émergent. Cela soulève également de nouvelles questions managériales. Comment évaluer la performance lorsque certaines tâches sont réalisées avec l’aide de l’IA ? Comment distinguer la qualité d’exécution de la qualité du jugement ?
Pour Julie, les compétences qui prennent de la valeur sont souvent les plus difficiles à automatiser : l’esprit critique, la capacité de synthèse, la communication ou encore la compréhension des enjeux business.
Plus qu’un nouveau métier, une nouvelle façon de construire
Poppins n’a pas la prétention d’avoir trouvé un modèle définitif. L’entreprise avance encore par expérimentation, en observant ce que ces nouveaux outils changent concrètement dans la manière de travailler, de décider et de construire.
Cette démarche permet déjà de déplacer le débat. Plutôt que de chercher à savoir si tous les Product Managers deviendront des Product Builders, elle invite à regarder ce que ces outils rendent possible dans les organisations : moins de dépendances historiques, plus d’autonomie pour les équipes, et une capacité renforcée à passer plus vite de l’idée à l’apprentissage.
Pour Julie, les profils qui tireront le mieux parti de cette transformation ne sont pas nécessairement les plus experts techniquement. Ce sont avant tout ceux qui restent curieux, qui aiment apprendre et qui sont prêts à remettre en question leurs habitudes de travail. Car derrière le terme Product Builder se cache peut-être une évolution plus profonde : le passage d’organisations conçues autour de la spécialisation à des organisations capables d’apprendre et de construire beaucoup plus rapidement.
Si cet article vous a plu, découvrez également Le rôle de modèle du CPO face à l’IA avec Benoit Terpereau, CPO chez Believe.
