‍

Product Trio : des équipes Tech des années 2000 au Product Trio augmenté par l’IA

Par Remi Edart

Le Product Trio est aujourd’hui devenu l’un des concepts structurants des organisations Product. Dans sa forme la plus courante, il réunit trois expertises complémentaires : Product Management, Product Design et Engineering. Ensemble, elles cherchent à comprendre les problèmes qui méritent d’être résolus, explorent les solutions possibles et prennent les décisions qui permettent au produit de progresser.

Mais le Product Trio n’est pas apparu soudainement avec la Continuous Discovery. Le terme est relativement récent ; la pratique organisationnelle qu’il décrit est beaucoup plus ancienne.

Des entreprises technologiques faisaient déjà travailler ensemble des profils Product ou Business, Design et Engineering bien avant que cette collaboration soit formalisée sous le nom de Product Trio. Les travaux autour des empowered product teams ont ensuite contribué à documenter ces pratiques. Plus récemment, Teresa Torres a fortement popularisé le terme dans le cadre de la Continuous Discovery, avec l’idée que Product Manager, Designer et Engineer doivent collaborer dès l’amont plutôt que de se transmettre successivement le travail.

Aujourd’hui, une nouvelle évolution est en cours.

L’IA réduit les frontières entre certaines compétences. Le Product Manager peut prototyper. Le Designer peut produire des expériences fonctionnelles. L’Engineer ou le Builder peut participer plus directement à la Discovery. Le Product Building permet également de transformer beaucoup plus rapidement une hypothèse en produit testable.

Chez Dthinking, nous faisons donc évoluer cette logique autour d’un Product Manager, d’un Product Designer et d’un Product Builder, et nous l’étendons de la Discovery à l’ensemble de la création de valeur : Strategy, Discovery, Design, Delivery, Growth et Sustaining.

1. Le Product Trio existait avant le terme «Product Trio»

Pour comprendre le Product Trio, il faut distinguer trois niveaux historiques.

Le premier est celui de la pratique organisationnelle.

Dans les organisations technologiques, la nécessité de faire collaborer business, utilisateurs et technologie ne date évidemment pas de la Continuous Discovery. La complexité même du développement d’un produit technologique obligeait déjà différentes expertises à travailler ensemble.

J’ai personnellement expérimenté ce type de fonctionnement dès les années 2000 chez ASML. Nous ne parlions pas alors de « Product Trio ». Nous l'appelions le Triangle avec le product manager, le product leader et le system engineer. Pourtant, le principe était déjà présent : réunir différentes perspectives pour comprendre un problème, arbitrer les choix et transformer une intention en produit.

Il serait donc inexact de chercher une organisation qui aurait « inventé » le Product Trio. Ce que nous appelons aujourd’hui Product Trio formalise et rend explicite une pratique cross-fonctionnelle plus ancienne.

Le deuxième niveau historique correspond à la formalisation des empowered product teams.

Dans les années 2000 et 2010, Marty Cagan et d’autres acteurs de la communauté Product ont largement contribué à documenter une autre manière d’organiser le développement produit : des équipes durables, cross-fonctionnelles et responsabilisées autour de problèmes et de résultats plutôt qu’une succession de silos spécialisés exécutant des demandes.

La distinction est fondamentale.

Dans une organisation fonctionnelle traditionnelle, le travail peut circuler séquentiellement : le business formule une demande, le Product rédige des spécifications, le Design conçoit une interface, puis Engineering développe ce qui lui est transmis.

Une équipe Product responsabilisée fonctionne différemment. Les différentes expertises participent beaucoup plus tôt aux décisions.

Pour aller plus loin — Marty Cagan explique pourquoi les meilleures équipes Product sont responsabilisées sur les problèmes à résoudre plutôt que sur l’exécution d’une liste de fonctionnalités.

Le troisième niveau est celui de la popularisation du terme Product Trio, notamment par Teresa Torres dans le contexte de la Continuous Discovery.

Le Product Trio devient alors une représentation particulièrement simple de cette collaboration : Product Manager + Product Designer + Engineer, travaillant ensemble dès la Discovery pour déterminer quoi construire.

Cette simplicité explique probablement une partie de la force du concept.

2. Pourquoi le Product Trio est-il devenu si important?

Un produit se situe à l’intersection de plusieurs systèmes.

Il doit répondre à un problème suffisamment important pour les utilisateurs.

Il doit proposer une expérience suffisamment désirable et utilisable.

Il doit être techniquement réalisable.

Il doit également créer suffisamment de valeur pour l’organisation qui investit dans sa conception, sa construction et son développement.

Aucune fonction ne possède seule toutes ces perspectives.

Le Product Manager peut avoir une excellente compréhension du marché et du business sans percevoir certaines subtilités de l’expérience utilisateur.

Le Product Designer peut parfaitement comprendre les utilisateurs tout en sous-estimant une contrainte économique ou technologique.

Le Tech lead ou Product Builder peut identifier une opportunité technique considérable sans disposer de l’ensemble des éléments permettant de déterminer si elle mérite d’être construite.

La valeur du Trio ne réside donc pas simplement dans le fait de réunir trois métiers.

Elle réside dans leur capacité à confronter continuellement trois perspectives sur le même problème.

C’est pourquoi un véritable Product Trio ne devrait pas fonctionner comme trois mini-silos.

Il ne s’agit pas de dire :

Le PM décide. Le Designer dessine. L’Engineer construit.

Il s’agit plutôt de créer une responsabilité collective sur les décisions produit, tout en conservant des expertises et des responsabilités différentes.

3. Le Product Manager : orienter et piloter la création de valeur

Dans le Trio, le Product Manager apporte notamment la perspective Product, marché et business.

Son rôle ne se limite pas à gérer un backlog ou à écrire des user stories.

Il contribue à identifier les opportunités, comprendre l’environnement, définir les outcomes recherchés et prioriser les problèmes qui méritent l’attention de l’équipe.

En Strategy, il contribue fortement à la vision, aux objectifs et aux choix qui orientent le produit.

En Discovery, il cherche avec le Trio à réduire les incertitudes : que savons-nous réellement ? Quels problèmes observons-nous ? Quelles hypothèses devons-nous tester ?

En Design, il ne prend pas la place du Designer. Il contribue à challenger les solutions et à relier les choix réalisés aux outcomes recherchés.

En Delivery, il ne se contente pas d’administrer une roadmap. Il aide à arbitrer valeur, effort, risque et priorité.

En Growth, il observe les résultats et cherche avec l’équipe les leviers permettant de développer la valeur créée.

En Sustaining, il participe aux décisions nécessaires pour maintenir la pertinence du produit dans le temps.

Le Product Manager apporte donc une capacité essentielle au Trio : relier les décisions quotidiennes à la valeur recherchée.

4. Le Product Designer : transformer la compréhension en expérience

Le Product Designer apporte principalement la perspective des utilisateurs, des usages et de l’expérience.

Là encore, réduire son rôle à la production d’interfaces serait une erreur.

Son travail commence bien avant Figma.

En Strategy, le Designer contribue à faire entrer la perspective utilisateur dans les choix structurants.

En Discovery, il joue un rôle central dans la recherche : comprendre les comportements, motivations, frustrations, contextes et besoins.

En Design, son expertise devient particulièrement profonde. Il transforme les apprentissages de la Discovery en différentes hypothèses de solutions, les matérialise, prototype et teste.

En Delivery, il travaille avec le Builder pour préserver l’intention et la qualité de l’expérience lorsque le prototype devient produit.

En Growth, il analyse les usages et les frictions afin d’améliorer les parcours, l’activation, l’engagement ou la rétention.

En Sustaining, il contribue à faire évoluer l’expérience, les systèmes de design et la cohérence globale du produit.

Le Product Designer apporte donc au Trio une capacité essentielle : transformer la compréhension des utilisateurs en expériences pertinentes et testables.

5. Du Tech Lead au Product Builder

Dans la représentation traditionnelle du Product Trio, le troisième rôle est généralement un Engineer, parfois un Tech Lead.

C’est parfaitement cohérent dans de nombreuses organisations.

Le Tech Lead apporte la compréhension de l’architecture, des contraintes techniques, des risques, de la sécurité, de la performance et de la maintenabilité. Il peut déterminer si une solution est réalisable et proposer des alternatives auxquelles Product et Design n’auraient pas pensé.

Chez Dthinking, nous utilisons davantage le terme Product Builder.

Ce choix traduit une évolution du contexte.

Avec les plateformes modernes, les APIs, le low-code, le vibe coding et les coding agents, la capacité à transformer une idée en solution fonctionnelle n’est plus exclusivement liée au développement logiciel traditionnel.

Le Product Builder apporte donc la perspective de la faisabilité et de la construction, mais avec une forte orientation vers l’expérimentation.

En Strategy, il contribue à évaluer les possibilités technologiques.

En Discovery, il peut construire rapidement des expérimentations permettant de réduire une incertitude.

En Design, il aide à transformer un concept en prototype fonctionnel.

En Delivery, sa contribution devient centrale : construire, connecter, tester et déployer.

En Growth, il permet d’instrumenter le produit et de mettre rapidement en œuvre des expérimentations.

En Sustaining, il participe à la maintenance, l’automatisation et l’évolution du produit.

Le Product Builder ne remplace donc pas nécessairement l’Engineer ou le Tech Lead. Il décrit une capability de construction Product qui peut être portée par différents profils selon le contexte.

6. La composition du Product Trio n’est pas une règle rigide

C’est un point important.

Le Product Trio est un modèle de collaboration, pas nécessairement un organigramme composé exactement de trois personnes.

Selon le produit, l’organisation et le problème traité, d’autres expertises peuvent intervenir.

Un UX Researcher peut jouer un rôle déterminant dans une Discovery complexe.

Un Data Analyst ou Data Scientist peut devenir essentiel lorsqu’une décision dépend fortement de données quantitatives ou d’un modèle.

Un Growth Lead peut être très impliqué lorsqu’un produit cherche son moteur d’acquisition ou de rétention.

Un expert métier peut devenir indispensable dans la santé, la finance, l’industrie ou d’autres domaines spécialisés.

Un Tech Lead peut naturellement représenter Engineering.

Le Product Trio doit donc être compris comme la réunion des perspectives nécessaires à une décision Product, et non comme une doctrine imposant systématiquement trois intitulés de poste.

Cette flexibilité devient encore plus évidente lorsque l’on change d’échelle.

7. Dans une petite organisation, le Trio peut être une seule personne

Dans une startup très jeune, une petite entreprise ou un projet entrepreneurial, il n’est pas toujours possible d’avoir un Product Manager, un Product Designer et un Product Builder dédiés.

Une même personne peut alors réunir les trois capabilities.

Elle doit être capable de se demander successivement :

Est-ce le bon problème à résoudre ?

Quelle expérience pourrait y répondre ?

Comment puis-je la rendre fonctionnelle et la confronter rapidement au terrain ?

Cette personne n’est évidemment pas nécessairement experte au même niveau dans les trois disciplines.

Mais elle dispose de suffisamment de compétences en Product Management, Product Design et Product Building pour passer de l’opportunité à l’expérimentation.

L’IA accélère fortement cette évolution.

8. L’IA transforme les frontières du Product Trio

L’IA ne fait pas disparaître les expertises. Elle augmente leur capacité d’action et élargit certaines frontières entre elles.

Un Product Manager peut aujourd’hui analyser rapidement de grandes quantités d’informations, synthétiser des interviews, explorer des scénarios et créer un prototype fonctionnel pour matérialiser une hypothèse.

Un Product Designer peut accélérer la recherche, explorer beaucoup plus de variantes, générer des interfaces et transformer certaines expériences en prototypes fonctionnels.

Un Product Builder peut utiliser des coding agents pour construire plus rapidement, mais aussi contribuer davantage à l’exploration et à la conception.

Cela ne signifie pas que chacun devient expert de tout.

Au contraire, plus les outils rendent l’exécution accessible, plus la capacité à poser les bonnes questions, exercer son jugement et arbitrer collectivement devient importante.

Le Product Trio augmenté par l’IA n’est donc pas un Trio dans lequel les métiers disparaissent.

C’est un Trio dans lequel chaque métier possède davantage de capacité à comprendre et pratiquer le travail des autres.

Cette évolution renforce la collaboration plutôt qu’elle ne la rend inutile.

Video Dthinking

9. De la Continuous Discovery à la création de valeur end-to-end

La popularisation moderne du Product Trio est fortement associée à la Continuous Discovery.

‍

Cette contribution reste fondamentale : Product, Design et Engineering doivent collaborer pour comprendre les problèmes et décider quoi construire, plutôt que recevoir une solution déjà définie.

Chez Dthinking, nous proposons d’étendre cette logique.

Pourquoi cette collaboration devrait-elle s’arrêter à la Discovery ?

Les arbitrages entre valeur utilisateur, business, expérience et faisabilité continuent pendant la conception.

Ils continuent pendant la construction. Ils continuent lorsque le produit est lancé. Ils continuent lorsque l’équipe cherche à développer son adoption. Et ils continuent lorsqu’il faut faire évoluer le produit dans le temps.

Nous positionnons donc le Product Trio sur l’ensemble du Value Operating Model :

Strategy → Discovery → Design → Delivery → Growth → Sustaining.

Chaque rôle possède des zones d’expertise plus profondes.

Le Product Manager approfondit notamment Strategy, Discovery et Growth.

Le Product Designer approfondit Discovery et Design.

Le Product Builder approfondit Design, Delivery et Sustaining.

Mais chacun doit également comprendre ou pratiquer les autres dimensions pour que le Trio puisse prendre de bonnes décisions collectivement.

C’est cette combinaison entre expertise métier et compréhension end-to-end qui rend le modèle particulièrement puissant.

10. Comment fonctionne réellement un Product Trio ?

Un Product Trio performant ne passe pas nécessairement toute sa journée ensemble.

La collaboration ne signifie pas que chaque tâche doit être réalisée à trois.

Chacun doit pouvoir approfondir son expertise et produire depuis sa perspective.

Le Designer peut conduire une recherche ou travailler une interaction.

Le Builder peut explorer une architecture ou construire une expérimentation.

Le PM peut analyser un marché ou préparer un scénario stratégique.

L’enjeu est ensuite de créer des boucles fréquentes permettant de : partager les apprentissages ; confronter les hypothèses ; challenger les solutions ; arbitrer ensemble ; observer les résultats ; décider de la prochaine étape.

On peut résumer ce fonctionnement en cinq mouvements :

APPROFONDIR

Développer son expertise.

PRODUIRE

Appliquer ses compétences au problème traité.

PARTAGER

Croiser données, livrables et perspectives.

DÉCIDER ENSEMBLE

Arbitrer désirabilité, viabilité, utilisabilité et faisabilité.

FAIRE PROGRESSER

Transformer collectivement les décisions en valeur.

C’est beaucoup plus proche du fonctionnement réel d’une équipe Product que trois fonctions travaillant successivement sur le même projet.

11. Dthinking applique aussi le principe à sa propre organisation

Le Product Trio n’a pas besoin de conserver exactement les mêmes rôles dans tous les contextes.

Dthinking en fournit lui-même un exemple.

Notre produit est une expérience d’apprentissage. Les capabilities nécessaires ne sont donc pas exactement celles d’un produit logiciel traditionnel.

Notre Product Trio réunit ainsi :

Product Lead — porte la vision, la proposition de valeur et les décisions Product.

Growth Lead — développe l’acquisition, l’engagement et la croissance.

Learning Experience Lead — conçoit l’expérience d’apprentissage et veille à sa qualité pédagogique.

La composition change, mais le principe reste identique : réunir les perspectives déterminantes autour d’une responsabilité commune sur la valeur créée.

C’est précisément pourquoi le Product Trio doit être considéré comme un modèle adaptable plutôt qu’une recette organisationnelle.

Du Trio historique au Product Trio augmenté

Le Product Trio n’est donc pas né avec la Continuous Discovery.

Il formalise une pratique cross-fonctionnelle plus ancienne des organisations technologiques. Les empowered product teams ont contribué à la documenter. Teresa Torres a ensuite donné au Product Trio une formulation particulièrement claire et l’a fortement associé à la Continuous Discovery.

Aujourd’hui, l’IA et le Product Building ouvrent une nouvelle étape.

Les frontières entre les disciplines deviennent plus perméables. Les cycles d’expérimentation raccourcissent. Une personne peut matérialiser une hypothèse beaucoup plus rapidement. Et dans certaines petites organisations, elle peut même porter les trois principales capabilities.

Mais la finalité reste la même :

réunir les bonnes perspectives pour prendre de meilleures décisions et créer davantage de valeur.

Chez Dthinking, nous résumons cette évolution ainsi :

Trois expertises. Une responsabilité commune. Un même produit.

Et désormais, un Product Trio augmenté par l’IA capable d’agir de la Strategy au Sustaining, de bout en bout.