Forum des équipes produit de l'entreprise : programme Product Day

Le forum des équipes produit relie le portefeuille, les dépendances inter-équipes et les décisions de la direction. Nous analysons le programme du Product Day, les rôles, la préparation des supports et le travail après l'événement.

Le forum des équipes produit de l'entreprise, ou Product Day interne, est nécessaire pour les questions qui ne rentrent plus dans les réunions d'une seule équipe. Les participants y construisent une vision globale du portefeuille, identifient les dépendances inter-équipes, discutent des contraintes et actent les décisions. La valeur d'un tel événement se mesure à ses résultats concrets : cartographie du portefeuille, registre des dépendances, journal des décisions et suite claire.

Chez Aventura, nous sommes responsables de la construction événementielle du forum : programme, scénario, parcours des participants, lieu, dispositif technique et consignation des résultats. Les données produit, les priorités et le droit de décision restent au client. Cette répartition doit être établie avant le choix des intervenants et des salles.

Quand une entreprise a-t-elle besoin d'un forum des équipes produit ?

En bref : Un forum est nécessaire lorsque plusieurs équipes dépendent de plateformes, de données, de canaux, d'experts ou de décisions de gestion communs. Une simple réunion de synchronisation ne suffit plus : chaque équipe ne voit que son périmètre, et les conflits de priorités et de ressources restent entre les services.

Le premier signe : les décisions d'une équipe ont des conséquences pour les autres. Une nouvelle version exige des modifications de la plateforme, un accès aux données, une validation juridique, le soutien des ventes ou une modification du parcours client commun. Si ces liens sont discutés dans différents calendriers, la vue d'ensemble se disloque.

Le deuxième signe : la direction doit comparer les initiatives après une série de rapports séparés. Les équipes présentent leurs feuilles de route et leurs métriques, mais utilisent des formats différents. En conséquence, le temps est consacré à la traduction et à la clarification des données initiales. Le choix de portefeuille est reporté à une réunion fermée, dont les participants découvrent la logique plus tard.

Le troisième signe : un différend exige des compétences de niveau supérieur à l'équipe. Une équipe peut préciser elle-même une hypothèse ou l'ordre des tâches. La question de la redistribution d'une ressource commune, de l'arrêt d'une initiative ou de la modification d'engagements doit être tranchée par le responsable concerné. Les principes GOV.UK pour la livraison agile proposent de prendre les décisions au bon moment, au bon niveau et avec les personnes concernées. Pour un forum, c'est une limite utile : le programme inclut les questions qui ne peuvent pas être réglées lors d'une réunion d'équipe ordinaire.

Un forum est prématuré si le commanditaire n'a pas d'objectif commun, de critères de choix et de personnes ayant le pouvoir de décision. Une grande salle ne corrigera pas des données non préparées. Il faut d'abord rassembler les contradictions et déterminer lesquelles nécessitent un travail commun.

La frontière avec le Demo Day, le hackathon et la session stratégique

L'essentiel : Le nom de l'événement ne détermine pas le format. Le Demo Day présente des résultats préparés, le hackathon donne le temps de créer une solution, la session stratégique choisit une orientation, et le forum relie le portefeuille en cours, les équipes, les contraintes et les prochaines étapes.

Un seul Product Day peut inclure une démo, une session de travail et une intervention d'un responsable. Le centre de gravité doit néanmoins être unique. Sinon, les participants reçoivent un long programme avec des promesses différentes : à certains on propose de montrer leur travail, à d'autres - d'inventer du nouveau, à d'autres encore - de coordonner les ressources.

Dans Scrum, la Sprint Review est décrite comme une session de travail pour vérifier le résultat et discuter de l'adaptation ultérieure. Il n'est pas proposé de la limiter à une présentation. Ce principe est également utile pour le forum : la démo doit fournir matière à une question ou à une décision, sinon elle se transforme en défilé d'écrans.

Si la tâche principale se termine par la présentation de projets préparés et une décision pour chacun, mieux vaut utiliser un démo day corporate de projets distinct. Pour une communauté professionnelle qui compare les pratiques et les documents, il est utile de voir comment est organisé un forum des technologues de l'entreprise. Le forum produit se distingue par son objet de travail : il relie des équipes transverses permanentes, des signaux produit, des feuilles de route et des contraintes communes.

Décisions qui doivent être prises d’ici la fin de la journée

Livrable : Avant de construire le programme, il faut consigner les décisions pour lesquelles les équipes se réunissent. Pour chaque question, on définit le niveau de résultat attendu : choix final, recommandation, liste des données manquantes, action assignée ou escalade.

L’expression « synchroniser les équipes » ne fournit pas de tâche opérationnelle à celui qui conçoit le déroulé. Il convient de la décomposer en questions concrètes. Quelles initiatives nécessitent une ressource commune ? Où deux équipes ont-elles promis des délais incompatibles ? Quelles dépendances créent un risque critique ? Sur quels sujets la direction doit-elle valider un choix ?

Nous commençons par une carte des décisions. Elle contient le sujet de discussion, le responsable de la préparation, les participants, la personne habilitée à approuver et le résultat admissible du forum. Si une décision ne peut pas être prise en séance, il faut déterminer honnêtement ce que le forum préparera pour l’étape suivante.

Il est commode de répartir les questions en quatre groupes :

1. L’équipe décide seule et communique le résultat aux autres.
2. Plusieurs équipes conviennent d’une action commune.
3. Le responsable confirme la priorité ou résout le conflit.
4. La question nécessite des données complémentaires et se voit attribuer un responsable pour la suite.

Tout désaccord ne doit pas nécessairement se conclure par une réponse le jour même. Parfois, un résultat de qualité consiste à consigner quelles données manquent, qui les collecte et quand les participants reviendront au choix. C’est plus utile qu’un vote formel sans information sur les coûts, les risques et les engagements.

Dans son article sur la prise de décision, Atlassian décrit le problème des discussions répétées lorsque les rôles restent flous. Pour le forum, la conclusion est directe : les participants doivent savoir où ils apportent leur contribution, où ils formulent une recommandation et qui approuve le résultat. La mécanique du vote recueille un signal de l’auditoire, mais elle ne remplace pas le droit de décision.

Composition des participants et rôles

En bref : Les participants sont choisis en fonction de leur contribution à la décision. Le forum a besoin des détenteurs du contexte produit, des contraintes techniques, des données utilisateurs, des engagements commerciaux et des ressources communes, ainsi que des responsables capables de valider l'étape suivante.

Un forum réservé aux product managers donnerait une image incomplète. Un pari produit peut dépendre de l'architecture, de la recherche, de l'analytique, du support, des ventes, du marketing, des opérations, des finances ou de contraintes juridiques. Le GOV.UK Service Manual associe le travail d'un service numérique à une équipe pluridisciplinaire et à la participation des personnes qui prennent réellement les décisions.

La composition dépend de l'ordre du jour. Il n'existe pas de liste universelle de postes. Nous proposons de parcourir chaque bloc du programme et de répondre à trois questions : qui valide les données initiales, qui voit les conséquences d'une décision et qui a le pouvoir de passer à l'étape suivante.

Les RH et la communication interne aident à rassembler l'audience, à expliquer l'objectif et à transmettre les résultats aux participants. Elles ne doivent pas se substituer aux propriétaires des décisions produit. L'équipe événementielle ne détermine pas non plus les priorités à la place du CPO ou du propriétaire du portefeuille.

Nous désignons séparément le propriétaire de chaque décision et le propriétaire du forum lui-même. Le premier est responsable du contenu de la question. Le second coordonne le programme, les versions des supports, les accès et les modifications. Cette séparation réduit le risque que les tâches organisationnelles et les conclusions produit se retrouvent dans un seul rôle surchargé.

Les analyses de programmes, de modération et de décisions opérationnelles sont publiées dans le canal Telegram d'« Aventura ».

Que rassembler auprès des équipes avant le forum ?

Principe de travail : Chaque équipe prépare un pre-read comparable, et non une présentation arbitraire. Il doit contenir le problème ou l'opportunité, le public cible, les données, le résultat attendu, les contraintes, les dépendances et une demande précise adressée aux autres équipes ou à la direction.

Il est préférable de collecter les supports avant la répétition technique. Si une équipe apporte des métriques et des options, une deuxième l'historique des versions, et une troisième un spot publicitaire, il est impossible de les comparer. Une relecture dans la dernière semaine ne corrigera pas l'absence d'une question commune.

Nous prenons la fiche d'identité de l'équipe sur une ou plusieurs pages courtes :

• objectif produit ou problème ;
• utilisateur ou client interne ;
• signal : métrique, étude, retour d'expérience ou engagement ;
• décision prise précédemment et alternatives étudiées ;
• résultat attendu ;
• risque ou incertitude ;
• dépendances vis-à-vis des équipes, des plateformes et des fonctions transverses ;
• demande précise pour le forum ;
• niveau de divulgation autorisé des supports.

La roadmap dans un tel dossier sert à relier les objectifs, les initiatives et les résultats attendus. Product School et Aha! décrivent la roadmap comme un moyen de transmettre une vision d'ensemble et de relier la stratégie au travail. Pour le forum, un calendrier de versions ne suffit pas. Les participants doivent comprendre le fondement du pari, le changement attendu, la contrainte et le point de choix.

Les éléments factuels que l'on peut lire à l'avance sont intégrés au pre-read. Le handbook public de GitLab décrit les live-doc meetings et le lien entre la conversation synchrone et la documentation commune. Nous ne proposons pas de copier le processus d'une entreprise. Le principe pratique est utile : il vaut mieux réserver le temps en salle aux questions, aux conflits et à l'édition de la décision.

Il est pratique de fixer la liste des supports, du public, des flux et des contraintes dans un cahier des charges pour le forum d'entreprise. Sur cette base, nous calculons le programme, le lieu, l'équipement, la navigation et la composition de l'équipe.

Architecture du programme Product Day

En bref : Le programme progresse d'un cadre général vers des analyses opérationnelles et une validation collective. Le participant comprend d'abord les objectifs et les règles de sélection, puis travaille sur son parcours, avant de voir les décisions, les responsables et la suite.

Chez Aventura, nous construisons l'organisation de forums et séminaires autour des actions des participants. Nous commençons par identifier où les personnes écoutent le contexte général, comparent les initiatives, analysent les dépendances, assistent aux démos et prennent des décisions. Ensuite, nous sélectionnons les salles, la scène, les écrans, le réseau et le planning des transitions.

Le parcours de travail peut se présenter comme suit :

1. Cadre général de la direction : objectifs, critères de sélection, contraintes et questions du jour.
2. Bref aperçu du portefeuille : carte générale des initiatives et des liens.
3. Analyses thématiques : paris produits, signaux utilisateurs, contraintes techniques.
4. Dependency clinic : travail sur les liens critiques entre équipes.
5. Démos sur les sujets où une démonstration en direct confirme la thèse.
6. Créneau fermé pour les décisions sensibles, si nécessaire.
7. Point de décisions collectif : ce qui est adopté, ce qui nécessite des données, qui poursuit le travail.

La scène principale est nécessaire pour le contexte, que chacun doit entendre de la même manière. Le travail détaillé se fait mieux dans de petites salles ou à des tables de travail. La finale rassemble à nouveau les participants, mais pas pour répéter toutes les présentations. L'animateur montre les changements dans la vision globale et indique les prochaines étapes.

Les flux parallèles nécessitent un parcours. Chaque participant doit avoir une logique de choix claire, et les organisateurs doivent gérer la capacité des salles, le temps de transition et la manière de consigner les résultats dans le journal commun. Si le travail d'un groupe n'est pas intégré à la validation finale, il reste une conversation locale.

Pour un large événement d'entreprise, nous relions le contenu, la logistique et la production technique dans l'organisation d'événements d'affaires. Le client conserve la maîtrise du contenu de l'agenda produit et valide toutes les conclusions.

Des formats de travail au lieu d'une série d'exposés

En bref : Un exposé se justifie lorsqu'il crée rapidement un contexte commun. Pour comparer, analyser un risque et aligner les actions, des formats de travail sont nécessaires : table ronde, clinic, revue de décision, cartographie du portefeuille, failure review ou travail collaboratif sur un document.

Une série de présentations est pratique pour le programme, mais elle modifie peu le travail des équipes. Chaque intervenant présente sa propre histoire, les questions se réduisent, et les liens entre les interventions restent dans les notes des participants. Le forum paraît donc dense, alors que les décisions n'apparaissent qu'après l'événement.

Nous choisissons le format en fonction de l'action visée :

L'analyse d'une erreur exige une modération sécurisée. Nous discutons la décision et les conditions, en examinant séparément ce qui était connu au moment du choix et ce qui est apparu plus tard. Nous ne transformons pas la reconnaissance d'une erreur en classement des services.

Pour un cas complexe, le modérateur reçoit à l'avance la question, les données disponibles et les limites de la discussion. Sa tâche est de maintenir la conversation dans le cadre de la demande. Si les participants s'égarent dans les détails de mise en œuvre avant d'avoir clarifié le problème, le modérateur les ramène au choix initial.

Comment mener une revue de portefeuille ?

En bref : La revue de portefeuille compare les initiatives selon un modèle unique. L'équipe présente l'objectif, le résultat attendu, les justifications, les contraintes, les dépendances et la demande de décision. La beauté des slides et le nombre de fonctionnalités livrées ne doivent pas se substituer au fond.

La revue commence par une carte globale. On y voit les axes produits, les initiatives, les plateformes communes et les dépendances majeures. Ensuite, les équipes ne détaillent que les éléments qui nécessitent le regard des autres participants ou un arbitrage managérial.

Pour chaque pari, sept champs suffisent :

1. Quel problème ou quelle opportunité l'équipe examine.
2. Pour qui elle est importante.
3. Quelles données confirment sa pertinence.
4. Quel résultat est attendu.
5. Quelles contraintes et alternatives sont déjà connues.
6. De qui dépend l'étape suivante.
7. Quelle décision est requise lors du forum.

L'animateur ne demande pas à l'équipe de défendre toute la roadmap. Il pose des questions sur le point litigieux. Si les données sont suffisantes, le responsable désigné confirme le choix. Si les justifications sont faibles, l'équipe reçoit une mission de vérification. Si le conflit concerne une ressource commune, la question est transférée vers une fenêtre de décision avec le propriétaire de cette ressource.

L'antipattern de ce type de bloc, c'est le défilé de statuts verts. Les participants entendent que tout se passe comme prévu, mais ne voient ni les hypothèses arrêtées, ni le coût du retard, ni les demandes adressées à d'autres équipes. Nous proposons de conclure chaque revue par l'un des statuts clairs : poursuivre, modifier, arrêter, vérifier les données ou escalader.

Le secrétaire de séance consigne la formulation directement à l'écran ou dans un document partagé. Les participants voient le texte et peuvent corriger toute ambiguïté avant de passer à la question suivante. Le compte rendu final doit être compréhensible pour une personne qui n'était pas présente dans la salle.

Dependency clinic et carte des liens inter-équipes

Réponse : Une dépendance devient exploitable lorsque les deux parties, le responsable, l'action requise, la conséquence d'un retard et le point de contrôle sont indiqués. Une ligne entre deux cartes sans ces champs montre un lien, mais ne définit pas la suite du travail.

Dans sa méthode de dependency mapping, Atlassian propose d'identifier les dépendances et les risques en amont, de désigner des responsables, de planifier la réduction des risques et de définir le rythme des retours d'information. Pour le forum, c'est la base d'une session de travail dédiée.

Avant l'événement, les équipes consignent les liens connus dans un registre commun. Pendant le forum, les participants vérifient les dépendances critiques, identifient les personnes manquantes dans la discussion et précisent l'action. Nous ne promettons pas de lever chaque blocage en salle. Si les autorisations ou les données manquent, le résultat devient un chemin d'escalade.

La fiche de dépendance comprend :

La carte doit avoir un responsable après l'événement. La photo du mur ne remplace pas le registre. Toutes les fiches sont transposées dans l'environnement numérique où l'équipe mène déjà son travail produit. Le format de l'outil est choisi par le client.

Lors de la session elle-même, il est utile de réunir côte à côte des personnes des deux côtés du lien. Si une partie est absente, la discussion devient rapidement une supposition sur les capacités des autres. Une telle question est consignée comme ouverte et n'est pas présentée comme un plan validé.

Rôle de la direction et session à huis clos

Repère : Les dirigeants sont nécessaires dans les blocs où leur autorité change le résultat. Un mot de bienvenue ne remplace pas la participation au choix des priorités, des ressources et du chemin d'escalade. Les questions sensibles peuvent être portées dans une salle fermée, mais la logique des décisions doit revenir aux équipes dans un volume autorisé.

Avant le forum, nous confrontons le calendrier des décideurs avec le programme. Si le CPO, le CTO ou un responsable métier n'est présent qu'à l'ouverture, les questions litigieuses repartiront « pour validation ». C'est pourquoi les fenêtres de décision sont placées à un horaire confirmé et un pre-read est transmis à l'avance au dirigeant.

Une large audience peut discuter des signaux utilisateurs, des dépendances, des options d'exécution et des conséquences. Les questions portant sur des personnes, des données confidentielles, des limites d'investissement ou une stratégie non encore annoncée peuvent exiger une composition restreinte. La frontière est définie par une matrice d'accès approuvée par le client.

Une session à huis clos ne doit pas transformer tout le forum en décor. À l'issue de celle-ci, les équipes reçoivent un statut clair : décision prise, question reportée dans l'attente de données, réunion distincte planifiée ou priorité modifiée. Les détails peuvent être limités, mais les participants doivent savoir quoi faire ensuite.

Pour chaque décision, il est utile de conserver la justification dans le volume autorisé. La phrase « la direction a décidé » perd rapidement son contexte. La mention « priorité confirmée en raison d'un engagement commun ; l'équipe A met à jour le plan, l'équipe B vérifie la dépendance » facilite l'exécution et réduit les débats répétés.

Comment concevoir un format hybride, une démo et un plan de secours technique ?

En bref : Les participants à distance doivent pouvoir poser des questions, travailler avec des documents et influencer les décisions. Chaque live demo doit disposer d'un plan de secours validé, et les règles d'enregistrement, de présentation des feuilles de route et d'accès aux supports sont approuvées avant la répétition technique.

Un Product Day hybride ne peut pas être conçu comme une simple diffusion de scène avec un chat passif. Le W3C recommande de prendre en compte en amont les besoins des participants, la qualité du son, les sous-titres ou transcriptions, la description des informations visuelles importantes et l'accessibilité des supports. Les questions posées dans la salle doivent être répétées dans le micro, sinon l'audience à distance perd une partie de la conversation.

Pour les équipes réparties, nous créons une source de vérité numérique unique. On y trouve les documents de prélecture, les modèles de travail, le journal des décisions et les supports autorisés. Dans chaque salle, une personne doit surveiller le circuit à distance et ramener les questions dans la discussion.

Si l'entreprise a besoin d'une organisation complète d'un événement hybride, nous construisons séparément les parcours studio et présentiel : connexion, son, affichage des écrans, votes, travail en groupes et transmission des conclusions. Une seule plateforme ne résout pas cette tâche automatiquement.

Nous vérifions le live demo comme une chaîne de production : accès à l'environnement, version du produit, compte utilisateur, réseau, câbles, commutation des sources, échelle de l'interface et autorisation de présenter les données. Pour le plan de secours, un enregistrement validé, des captures d'écran ou un parcours statique conviennent. La solution de remplacement doit confirmer la même thèse que celle pour laquelle la démo a été incluse au programme.

Il est utile de passer en revue les points de jonction lors de la répétition technique de l'événement. On y vérifie les fichiers finaux, les transitions entre les flux, les droits d'accès, le plan de secours, l'affichage des données confidentielles et la transmission de la décision dans le journal commun. Une répétition de présentation sans ces points de jonction ne démontre pas la préparation du forum.

Les règles d'enregistrement sont définies à l'avance. Les participants sont informés de l'enregistrement et le consentement nécessaire est recueilli conformément aux règles du client et au droit applicable. Le client définit également l'accès, la durée de conservation et l'utilisation autorisée des supports. Une personne doit connaître le régime avant le début de la discussion d'un sujet sensible.

Artefacts, métriques et prochaine étape

En bref : après le forum, il reste des documents de travail et un calendrier de suite. Il convient d'évaluer l'avancée des décisions : les responsables ont-ils été désignés, les dépendances ont-elles été mises à jour, les données manquantes ont-elles été collectées et les participants sont-ils revenus aux points de contrôle. L'impression des invités complète ce tableau, mais ne le remplace pas.

Le pack minimal après un Product Day comprend une cartographie du portefeuille, un registre des dépendances, un journal des décisions, une liste des questions ouvertes et les supports autorisés. Dans le journal, chaque entrée précise la formulation, le fondement, le responsable, les participants à la suite, les données manquantes, le mode d'accès et le point de contrôle.

Le résultat comporte quatre états :

1. La décision est consignée et confirmée par les participants.
2. Le responsable a accepté l'action suivante.
3. L'action est réalisée ou mise à jour au point de contrôle.
4. Le résultat produit ou business est vérifié par le responsable au sein du périmètre de travail de l'entreprise.

Le forum peut accomplir qualitativement les deux premières étapes. Les autres dépendent de la gestion régulière après l'événement. C'est pourquoi il ne faut pas attribuer à une seule journée l'accélération du lancement d'un produit, la croissance d'un indicateur financier ou l'augmentation de l'engagement sans les données du client.

Après l'événement, il est utile de vérifier les indicateurs organisationnels : les groupes de travail ont-ils atteint le résultat annoncé, le temps consacré aux décisions a-t-il été suffisant, les supports étaient-ils disponibles, où sont apparus des problèmes de son, de transitions ou d'accès. Ces observations aident à améliorer le cycle suivant, mais ne prouvent pas l'effet produit.

La préparation d'un nouveau forum commence par un brief court. Celui-ci doit contenir l'objectif business, la composition des équipes, la cartographie des questions litigieuses, les droits de décision, le mode d'accès et le pack de documents attendu. Ensuite, nous élaborons l'architecture du programme, le lieu, le plan technique, les rôles et le devis.

Sources

• Scrum Guides : le guide officiel de Scrum
• Atlassian Team Playbook : cartographie des dépendances
• Atlassian Team Playbook : prise de décision et rôles
• GOV.UK Service Manual : équipe pluridisciplinaire
• GOV.UK Service Manual : principes de gouvernance de la livraison agile
• Product School : feuille de route produit
• Aha! : guide sur la feuille de route produit
• W3C Web Accessibility Initiative : événements et présentations accessibles
• GitLab Handbook : réunions entièrement à distance