Meetups
Voici les prochains meetups et rencontres de la communauté.
Mardi 13 février, le chapter Bordeaux-SudOuest propose le meetup “Impact Talk #3 | REX Back Market” avec :
Philippine de Fonscolombe - Director BuyBack & Logistics @Back Market
Victoria Raspaldo - Group Product Manager @Back Market
Frédéric Girard - Engineering Manager @Back Market
Jeudi 15 février, le chapter #Nantes-Bretagne propose un “Déjeuner FrenchProduit !” pour se rencontrer et discuter autour d’une table.
Jeudi 22 février, le chapter #Lille-Nord propose “Apéro produit : L'apéro des amoureux du product management”. Un moment convivial pour rencontrer d'autres Product lovers.
Mercredi 28 février, le chapter #Toulouse-SudOuest propose le meetup “Construire un produit à succès grâce aux jeux vidéo” avec :
Alessandro Costa, créateur du média « Au coin du feu », Ex @Hivency, Ex @Eldo et membre de FrenchCPO.
Voici les résumés de la semaine !
⚠️ Les résumés ci-dessous sont générés par IA (chatGTP4) à partir des fils de discussion de la communauté sur le Slack FrenchProduit. Une relecture est faite ainsi que la mise en page.
#product-design
Gestion de la compétence design au sein d'équipes produit
Au sein de notre communauté, Charline a soulevé une question pertinente sur la gestion de la compétence design UX/UI au sein des équipes produit, spécifiquement quand les profils de managers de produit (PM) ne possèdent pas de compétences en design.
De nombreux membres ont partagé leurs expériences et suggestions, y compris l'option de travailler avec des freelances, bien que cela puisse s'avérer coûteux, ou d'internaliser des compétences en design à terme.
Charline a expliqué que dans son équipe, les PMs sans arrière-plan en design, s'occupent eux-mêmes des interfaces, une situation qui devient difficile à gérer du point de vue de la scalabilité.
Matthieu a posé une question sur la structure d'équipe, quant à l'absence de collaboration entre les PMs et les designers de produit.
Gautier a suggéré d'évaluer le coût d'un designer freelance pour établir une base solide malgré les restrictions budgétaires.
Aerandirsurion a partagé son expérience d'engager d'abord un Product Designer (PrD) freelance avant d'internaliser cette compétence.
Mcutin a souligné l'importance d'un design system qui permettrait aux PMs d'assembler des éléments de design comme des "legos", réduisant ainsi le besoin de compétences design approfondies.
Agathe a présenté une approche où un seul designer senior travaille avec plusieurs PMs formés minimement en UX/UI, soutenus par un design system robuste.
Anael a proposé d'autres idées telles que la formation, les revues de design entre PMs, et l'établissement de principes de design pour améliorer la compétence design au sein de l'équipe.
#product-organisation
Débat sur l'Utilisation de SAFe dans l'Industrie Numérique - Part#3
Dans le channel #product-organisation, une discussion animée a eu lieu autour de l'approche SAFe (Scaled Agile Framework) pour la gestion de projet dans l'industrie numérique, avec des points de vue variés et enrichissants.
Thomas a partagé un post de John Cutler sur LinkedIn, soulignant les contextes où SAFe pourrait être pertinente, notamment pour les entreprises aux multiples dépendances, difficultés de livraison, et un besoin immédiat de stabilisation. Il a mis en lumière les divers défis auxquels ces entreprises font face, telles que la gestion de l'héritage d'une organisation IT traditionnelle et les obstacles au changement organique. Cutler fait valoir qu'il est injuste de comparer des entreprises utilisant SAFe à des géants comme Netflix et Amazon, vu leurs univers différents.
Cory, en revanche, pense que John Cutler cherche parfois trop le compromis. En se référant à des interventions lors de la dernière LPC, Cory souligne l'importance de distinguer entre « feature factory » et « impact teams », mettant en avant la définition du succès collectif comme clé : est-ce simplement livrer des fonctionnalités ou atteindre des objectifs d'impact significatifs ?
Vincent328 s’est joint à la discussion en précisant qu'en admettant que SAFe soit bénéfique dans certains contextes, cela suppose une amélioration de la performance des organisations qui l'adoptent, une affirmation pour laquelle il manque, selon lui, de documentation concrète. Il a également clarifié que SAFe ne se résume pas à une « feature factory », et que de nombreuses équipes de features n'utilisent pas nécessairement SAFe.
#product-organisation
Approches variées sur le processus de wording dans le monde du produit
La communauté a partagé plusieurs pratiques concernant le processus de "wording" ou rédaction des contenus dans les produits digitaux. Voici un résumé des points principaux :
Généralement, le Product Designer propose le wording initial, souvent en collaboration avec le Marketing pour des éléments plus orientés business. Ce processus semble courant dans plusieurs organisations.
Certains évoquent des défis, notamment des délais longs pour la validation des mots ou des phrases, des termes juridiques rendant le contenu difficile à comprendre pour les clients, ou des contenus marketing parfois trompeurs.
Un point de friction notable est la variance dans l'appel à l'action (CTA), qui change selon le validateur ou son humeur, soulignant un manque de guidelines claires.
La discussion souligne l'importance de l'ownership et de la collaboration entre les différents rôles (Design, Produit, Marketing) pour créer un contenu cohérent et efficace.
Une proposition idéale mentionnée serait d'avoir une personne dédiée au copywriting, prenant en compte les contraintes de chaque département pour rédiger les textes.
Vincent propose une approche où l'imputabilité du wording est placée du côté du UX, en suggérant une intégration plus étroite entre la création et la validation pour éviter les retards et pour assurer la cohérence et l'adéquation des contenus avec les besoins des utilisateurs.
#product-management
Stratégies pour Engager les Équipes dans la Mesure de l'Impact Produit
Camille a partagé son défi d'impliquer son équipe (composée de développeurs et d'un UX designer) dans la mesure de l'impact de leur produit à travers des OKR et des KPI. Malgré leurs efforts pour définir les OKR et les epics associés, l'équipe montre peu d'engagement dans l'élaboration et le suivi de ces KPI, même après avoir tenté d’inclure des KPI techniques. L’équipe semble plus intéressée par les aspects techniques du produit que par la réflexion stratégique sur son impact.
Matthieu a partagé une approche qui a fonctionné pour lui, consistant à impliquer l'équipe technique dès la phase d'idéation en leur rappelant leur expertise et en co-construisant les solutions et les objectifs.
L a suggéré d'initier la démarche par des objectifs liés à des stories spécifiques, pour attirer l'intérêt de l'équipe sur des résultats mesurables, et de réduire la pression en gardant leur contribution à un niveau consultatif.
Gautier a questionné si l'approche OKR est intégrée à l'échelle de l'entreprise, soulignant l'importance de l'alignement organisationnel et de la culture d'entreprise pour faciliter l'adoption.
Tommy a pointé vers le système d'incentives et la culture d'entreprise comme leviers potentiels pour renforcer l'intérêt des développeurs pour les KPIs, indiquant que les récompenses liées à l'impact produit peuvent motiver l'engagement.
En résumé, la discussion a souligné plusieurs pistes pour engager les équipes dans la mesure de l'impact produit, incluant l'implication dès les premières étapes, la mise en place d'une culture orientée impact et l'alignement des incentives. La conversation est toujours ouverte pour d'autres suggestions ou retours d'expérience.
#product-management
Méthodologies et astuces pour organiser des ateliers efficaces et aligner les équipes autour des besoins des produits.
Matthieu a partagé une expérience riche en enseignements sur l'organisation d'un atelier pour aligner les équipes produit et les stakeholders. Il a mis en lumière l'importance de :
Bien préparer l'atelier avec une activité préliminaire claire
Utiliser un vocabulaire commun et agnostique
Se concentrer sur les situations des utilisateurs plutôt que sur les fonctionnalités spécifiques
Voir la fresque créée comme un travail en cours nécessitant partage et itérations
Inclure une diversité de participants, notamment des développeurs
Nouhad a évoqué son approche, qui consiste à démarrer avec un représentant de chaque pôle selon la complexité du sujet et à utiliser Miro pour visualiser le processus. Il souligne l'importance d'un "owner" du sujet dans le déroulement et le suivi de la delivery du projet.
La discussion a aussi abordé l'ordre des étapes dans le processus de conception, notamment l'opportunité de commencer par les événements métier avant les commandes. Matthieu et Nouhad ont partagé leurs points de vue sur l'utilité de cette approche pour bien comprendre les besoins et les situations des utilisateurs.
Psabo et Nouhad ont échangé sur le rôle des développeurs, soulignant qu'ils ne sont pas nécessairement lead mais sont responsables du suivi de la delivery et de la réponse aux questions.
#product-management
Synthèse des discussions autour de l'évaluation des points d'effort et de la complexité
La communauté a partagé diverses perspectives et expériences sur la gestion de l'évaluation des points d'effort par rapport à la complexité des tâches au sein des équipes de développement. Voici quelques points saillants :
Certains membres ont opté pour se concentrer sur l'accomplissement des tâches plutôt que sur des estimations précises.
D'autres ont suggéré de découper les tâches en plus petits morceaux ou d'utiliser des cas d'utilisation pour faciliter l'estimation.
L'importance du contexte économique et de l'impact potentiel des fonctionnalités a été soulignée pour orienter l'effort de développement.
Estimations et Clarté : La discussion a également porté sur l'importance de clarifier les estimations pour assurer une compréhension partagée au sein de l'équipe. Les "story points" ont été évoqués comme un moyen de mesurer la complexité et de vérifier la compréhension mutuelle des tâches.
Gestion de l'Incertitude : La complexité et l'incertitude ont été distinguées, et l'usage de "spikes" ou tickets d'investigation a été recommandé comme moyen de réduire l'incertitude avant de procéder à des estimations plus précises.
Discovery Technique : L'importance d'un "discovery technique" a été soulignée, invitant les développeurs à s'impliquer davantage dans l'exploration et la résolution de problèmes techniques dès les phases initiales d'un projet.
Les participants ont partagé des liens vers des articles et des discussions précédentes pour approfondir le sujet, et ont encouragé l'utilisation de méthodes pragmatiques adaptées à chaque contexte d'équipe et de projet.
#share-tools
Echanges sur l'utilisation de l'IA et des méthodologies agiles dans la rédaction d'US
Dans une discussion récente sur notre channel #share-tools, plusieurs membres ont échangé sur leurs expériences et astuces concernant la rédaction des User Stories (US), surtout dans les contextes où le temps presse ou les processus standards ne sont pas suivis. Voici un aperçu des sujets évoqués :
Lberthelot partage sa tactique d'utiliser chatGPT 4 pour générer des ébauches d'US en utilisant le format standard "As... I need... So that..." ainsi que les critères d'acceptance. Cela lui permet de gagner du temps en optimisant la rédaction des US, même dans des conditions projet loin d’être idéales.
L propose une approche différente, privilégiant la rédaction « just enough, just in time » des US, et favorisant l'implication de l'équipe dans ce processus pour mieux s'approprier les tâches. Cette méthode permet de limiter la rédaction à un horizon d'un sprint et encourage l'équipe à poser des questions et à proposer des solutions.
Tommy soulève un point important sur le rôle et le partage des responsabilités dans la rédaction et la délivrance des US, indiquant que la culture et l'approche de l'équipe peuvent grandement influencer la méthode la plus efficace à adopter.
Tpommier exprime son intérêt pour une IA capable de segmenter des designs Figma en US afin de simplifier encore davantage le processus.
#product-tech
Échanges sur la période de Warm up et partage de bonnes pratiques
Dans une récente discussion sur le channel #product-tech, Thomas a abordé l'importance d'une période de "warm up" lors du passage à une nouvelle IP, surtout en ce qui concerne l'envoi d'e-mails en grand volume. Il souligne que cela est crucial pour ne pas nuire à la réputation de l'IP et recommande d'augmenter progressivement le volume d'envois.
Il a aussi mentionné son expérience avec Twilio, bien qu'il ne se souvienne plus des volumes exacts, il suggère de consulter leur documentation pour des détails précis.Alentschener a réagi en remerciant Thomas pour ses insights et a confirmé l'importance de cette période de warm up suite aux retours reçus. Il a également mentionné avoir recueilli plusieurs bonnes pratiques auprès d'experts et s'est proposé de les partager avec la communauté si cela intéresse quelqu'un.
#share-tools
Discussion sur les Outils QA dans les Startups et Scale-ups
La conversation dans le channel share-tools a été principalement axée sur la recherche d'outils QA adaptés à l'environnement de startup et de scale-up, lancée par Margarita, qui cherche à migrer de Excel vers un outil QA plus structuré pour la gestion des bugs et la réalisation des scénarios de test.
Kvn a mentionné qu'ils utilisent Jira comme outil de collaboration et de suivi des problèmes, mais sans recommander d'outil QA spécifique.
Anna a partagé qu'elle est en train d'implémenter Notion pour remplacer les fichiers Excel multiples.
Anael a posé des questions sur le type de QA (manuelle ou automatique) et les outils déjà en place pour suivre le delivery des fonctionnalités, en soulignant l'importance de choisir un outil en fonction de la stack des développeurs.
Margarita a répondu que la QA est actuellement manuelle, et qu'ils utilisent Monday, mais envisagent de se diriger vers plus d'automatisation à l'avenir. Elle a également mentionné que la mise en place de la chaîne CI/CD est en cours.
Rose a indiqué que le choix de l'outil dépend de nombreux facteurs tels que l'organisation, les besoins, et les contraintes, et a offert de discuter plus en détail en privé.
Lecureur a conseillé l'utilisation de Notion pour des startups de petite taille et a mentionné Linear comme autre option, soulignant l'importance de l'adoption des outils par les développeurs et designers dans le processus QA
À la semaine prochaine ?