Feature Team VS Product Team : de quelle équipe produit êtes-vous le Product Manager ?

Product Strategy

Antoine

Product Manager

Alors que l’Agile s’est largement diffusé ces dernières années, la Feature Team s’est rapidement imposée comme le modèle de référence des organisations Produit.

Parmi ses principaux enjeux, l’autonomie des équipes visait à stimuler l’innovation et renforcer leur engagement. Pour quels résultats aujourd’hui ?

Si la Feature Team s’est traduite par une prise de pouvoir de l’équipe sur le design et le delivery de ses fonctionnalités, qu’en est-il de son autonomie réelle sur sa roadmap ? De sa responsabilisation sur ses OKR ? De son influence sur le Discovery ?

Au même moment, le poste de “Product Manager” n’a jamais été aussi populaire. Du chef de projet au CEO du produit, il recouvre pourtant des réalités bien différentes. Au-delà de la place de l’équipe produit, c’est surtout celle du Product Manager qu’on va s’interroger ici.

La Feature Team : une usine à fonctionnalités ?

Au commencement, le mode projet

Pionnier du développement informatique dans les entreprises, le mode projet fait toujours de la résistance dans les départements IT, même s’il a été peu à peu éclipsé par les méthodes agiles.

La Project Team présente les écueils que l’on connaît bien :

  • Une durée de vie limitée au temps du projet ;
  • Une absence de vision produit et d’amélioration continue ;
  • Un cloisonnement des compétences Product, Design et Tech ;
  • Un contact faible voire souvent inexistant avec les utilisateurs finaux.

Au-delà de la méthodologie employée - on peut faire du Scrum en mode projet - la Project Team est avant tout là pour exécuter : elle implémente une fonctionnalité définie en amont par des interlocuteurs business. En tant que PM, tu es surtout amené à faire le pont entre Business et Tech, à traduire des besoins métier en spécifications, voire à faire office de “passe-plat” entre ton interlocuteur business et ton chef de projet IT.

Product Manager, Product Owner, ces termes sont utilisés de manière un peu abusive ici : dans les faits tu es avant tout chef de projet ou assistance à maîtrise d’ouvrage (AMOA) pour reprendre une terminologie quelque peu passée de mode.

L’arrivée des Feature Teams et leur montée en puissance sur le produit

Popularisée par Spotify et son concept de squad, on ne présente plus la Feature Team dont l’essor a été fulgurant dans les Directions Digitales. Cette équipe produit, stable, intégrant des compétences Product/Design/Tech, est organisée autour d’un périmètre fonctionnel dont elle est responsable de bout en bout (développement, maintenance, amélioration continue).

Par rapport à la Project Team, la Feature Team gagne nettement en responsabilité sur le design et le delivery de ses fonctionnalités :

  • Les méthodologies Agiles (Scrum, Kanban…) étant utilisées de manière systématique, l’équipe s’auto-organise et prend en main son backlog
  • Grâce à l’intégration de compétences Design, l’équipe devient autonome sur la conception UX/UI de ses fonctionnalités et de ses parcours clients

En termes d’empowerment, le progrès est donc considérable. Cela étant dit, et c’est là où le bât blesse, cette autonomie reste limitée à l’aval du cycle de vie produit. C’est toute la thèse défendue par Marty Cagan dans son best-seller Empowered.

Une équipe qui reste avant tout objectivée sur la livraison d’outputs

En tant que Product Manager tu restes en effet cantonné à délivrer une roadmap (au sens de liste de fonctionnalités) définie et contrôlée par des interlocuteurs business externes à ton équipe :

  • L'équipe exerce une faible influence sur le choix des sujets et des fonctionnalités à prioriser ;
  • Elle fait peu ou pas de Discovery (peu d’intérêt puisque les solutions sont déjà définies en amont par d’autres interlocuteurs) ;
  • Elle a peu ou pas de visibilité sur la valeur client et l’impact business générés par les évolutions.

En bref : l’équipe est objectivée avant tout sur sa capacité à livrer des “outputs”.  

L'équipe ressemble davantage à une petite usine à fonctionnalités, et toi à un Product Owner focalisé sur le delivery, plutôt qu’à un Product Manager pleinement maître de son produit.

La Product Team ou quand l’équipe prend (vraiment) son destin en main

Avec la Product Team, on change de paradigme : l’Agile n’est plus appliquée uniquement à la phase de delivery, mais à l’ensemble du cycle de vie produit.

Un grand pouvoir implique de grandes responsabilités

L’objectif n’est plus de livrer une liste de fonctionnalités, mais de générer de la valeur pour ses clients et par ricochet de l’impact pour son business. On donne à l’équipe des problèmes utilisateurs ou business à résoudre, et on lui laisse toute la latitude pour choisir les meilleures solutions permettant d’y répondre. Dans une Product Team, tu prends la main en tant que Product Manager sur l’ensemble de ton produit et tu endosses donc la pleine responsabilité des résultats obtenus.

Quand la méthode OKR prend tout son sens

Sans alignement, l’autonomie des Product Teams peut vite tourner à l’anarchie. Cette autonomie doit donc s’inscrire dans un cadre précis : le contexte, la vision et la stratégie produit doivent être clairement définis et partagés aux équipes. C’est dans ce cadre que la méthode OKR se révèle particulièrement efficace : on assigne des objectifs à la Product Team tout en la laissant indépendante dans le choix des actions à mener pour les atteindre. La product team est donc pleinement responsabilisée sur l’atteinte - ou non - de ses OKR. Cela représente une rupture majeure avec la Feature Team où cette responsabilité était diluée avec ses interlocuteurs business : elle ne pouvait être tenu responsable des résultats d’une solution qu’elle n’avait pas choisie.

Plein cap sur le Discovery

“Do the right product and do it right.”

C’est au sein d’une Product Team que la Discovery prend tout son sens et devient une activité essentielle de l’équipe, au même titre que le Delivery. Pour rappel, la phase de Discovery implique l’ensemble des compétences de la Product Team pour réduire les risques inhérents au développement d’une fonctionnalité :

  • Utilisabilité : mes clients vont-ils comprendre comment utiliser ma fonctionnalité ?
  • Faisabilité : avons-nous la capacité de développer cette fonctionnalité ?
  • Valeur client : mes clients vont-ils choisir de l’utiliser ?
  • Viabilité : cette solution impacte-elle positivement nos objectifs business ?

Si les 2 premiers risques sont généralement couverts par une Feature Team, la valeur client et la viabilité business sont uniquement pris en charge par une Product Team. Puisqu'elle choisit les fonctionnalités qu’elle développe, elle doit assumer la valeur client et l’impact business qu’elle génère. En tant que Product Manager, c’est donc une responsabilité bien plus lourde, d’où l’intérêt d’investir massivement dans le Discovery à partir des objectifs qui te sont assignés (OKR). Ici, tu es pleinement Product Manager, avec un ownership complet sur ton produit.

Fort de cette distinction, de quelle équipe produit es-tu le Product Manager ?

La transition de Carrefour de Feature team à Product Team

Mikaël Piolet, Lead Product Manager au sein de la Digital Factory e-commerce de Carrefour, revient sur les étapes clés de la transformation produit chez Carrefour.

Carrefour, pionnier dans le domaine de la grande consommation, a souhaité transitionner en 2022 d’une culture produit orientée delivery à une culture produit orientée impactLa Digital Factory e-commerce a été à l'origine de cette transformation en tant que pilote.

Le contexte de la Digital Factory avant sa transition :

Alors que depuis 2018 les équipes étaient organisées sous le modèle SaFe, en 2021, elles ont pris conscience que de nombreux points devenaient problématiques et qu’une forme de rigidité s’était installée.

Cette transformation a été réalisée en suivant les mêmes étapes qu’une initiative.

  1. Identifier les problèmes à résoudre :
    • Output vs Outcome : les équipes étaient objectivées au nombre de projets réalisés, ce qui engendrait une perte de vue sur la valeur et l’impact visés.
    • Processus lourds : des time to market de plus en plus longs sur des projets stratégiques et transversaux, dus à des processus lourds et complexes, et non uniformes entre les équipes.
    • Problèmes d’alignement et de communication entre les équipes : de nombreuses frictions entre les équipes produits et le business, dues à des difficultés d’alignement avec une communication manquant parfois de transparence et de fluidité 
    • Des rôles parfois peu explicites ou peu clairs

Cette analyse réaliste des principaux freins vécus par les équipes dans un contexte d’organisation SaFe a été la clé pour déterminer les objectifs de la transformation et ainsi pouvoir en mesurer le succès.

  1. Définir des objectifs de succès :
    • Amélioration de l’agilité et du ownership au sein des équipes
    • Devenir encore plus customer-centric en allant chercher l’impact (outcome) de chaque projet/produit sur l’expérience utilisateur.
    • Accroître les cycles d’innovation en e-commerce.
  1. Déterminer les solutions pour atteindre les objectifs :
    • Modifier l’organisation des équipes :some text
      • OKR : pour répondre à l’objectif de créer de l’impact et à la problématique de vision peu explicite, le top management a mis en place des OKR à deux niveaux. Chaque année, le top management fixe des objectifs annuels pour atteindre la vision de l’entreprise, qui sont déclinés au niveau des équipes de manière trimestrielle. Cela a permis de donner plus de sens, de se concentrer sur les projets à forte valeur ajoutée, d’aligner les équipes et de leur donner plus d’autonomie.
      • Modification de l’organisation avec le modèle North Star : auparavant, les équipes travaillaient sur un produit de Carrefour. Aujourd’hui, tout le parcours client est découpé en étapes et chaque équipe est responsable d’une étape. Par exemple, l’équipe qui était assignée au produit “service client” est aujourd’hui responsable de l’étape “post-achat” dont le produit “service client” fait partie. Cela permet d’accroître l’autonomie et apporte plus de sens dans leur travail en ayant une vision globale de l’étape.
      • Amélioration de la collaboration : mise en place du processus de “4 in a box”. Un peu à l’image des “tres amigos”, le processus regroupe 4 équipes (produit, business, tech et design). Elles travaillent main dans la main sur les problèmes et les solutions à mettre en place. Cela permet encore une fois d’améliorer l’autonomie et la responsabilité des équipes car elles sont les garantes de la mise en œuvre des solutions jusqu’à leur suivi dans le temps.
    • Accentuer et organiser la Discovery :
      • Implémentation de frameworks communs à tous : l’Opportunity Solution Tree (OST) de Teresa Torres ou Discovery Discipline de Rémy Guyot et Tristan Charvillat sont quelques exemples de frameworks utilisés par les équipes de Carrefour.
      • Utilisation de la data : chaque solution ou opportunité est basée sur des données quantitatives (questionnaires, outils analytiques) et qualitatives (interviews utilisateurs, focus groupes) afin de s’assurer que les efforts sont déployés sur les bonnes initiatives et de réduire les risques des solutions envisagées
  1. Déterminer les facteurs de réussite :
    • Engagement des stakeholders : le top management a été moteur dans la transformation en étant eux-mêmes des exemples (lead-by-example).
    • Des processus produit et une stack technique déjà en place : les équipes étaient déjà sensibles aux notions d’agilité et de Discovery, ce qui a permis d’aller plus vite dans la transformation.
    • Accompagnement des équipes dans la transformation : en étant sur un modèle de “change management”, les équipes ont été accompagnées, écoutées et formées pour éviter les frustrations et permettre l’adoption par tous de cette transformation.
    • Recrutement : intégration de nouveaux PM ayant de l’expérience en termes de Discovery et d’agilité afin d’aider les équipes en place et la transformation.
    • Encourager le test and learn : afin que chaque équipe puisse s’approprier les nouvelles manières de travailler, elles ont été encouragées à pouvoir les tester et apprendre par elles-mêmes ce qui fonctionnait ou non.
  1. Analyser les résultats et itérer : suite à cette transformation débutée en 2021, les résultats significatifs :
    • Les OKR ont été très bien adoptés à tous les niveaux de l’organisation. Les équipes ont gagné en autonomie. Elles sont jugées sur l’impact de leurs actions en fonction des résultats qu’elles ont eux-mêmes définis et non sur le nombre de projets sortis durant le trimestre.
    • La qualité et la vitesse des solutions proposées aux utilisateurs de Carrefour se sont améliorées grâce à des choix plus judicieux basés sur des données tangibles. Ce constat est également visible dans l’abandon de certains projets vus comme n’étant pas assez pertinents pour atteindre les résultats.
    • La communication et la collaboration entre les équipes, surtout entre le produit et le business, se sont grandement améliorées. Il y a un meilleur alignement et une communication plus fluide qui permettent de pouvoir avancer de manière plus efficace sur les projets.
    • Figure d'exemple pour les autres digital factories : cette transformation à l’échelle d’une partie des équipes de Carrefour a permis de donner un exemple à répliquer. Par conséquent, de plus en plus d’équipes et de digital factories comme celle de la logistique, du magasin, du merchandising ont repris des piliers forts comme les OKR et le “4 in a box”.

Pour conclure, globalement, si on constate tous les cas de figure sur le marché, il semble que la norme se situe aujourd’hui entre la Feature Team et la Product Team. En effet, si les grandes fonctionnalités restent souvent décidées et imposées en “top-down”, les équipes ont une autonomie de plus en plus forte sur l’amélioration continue de leur produit comme par exemple les équipes de Carrefour. Drivées par l’impact et en particulier leurs OKR, elles ont davantage de liberté pour optimiser leurs fonctionnalités et parcours clients. Prochaine étape : étendre cette logique à l’ensemble du produit, pour tirer tous les bénéfices de l’empowerment des équipes tout en prenant soin en amont d’analyse des points à améliorer afin de se concentrer sur des actions clés.

Dans la même catégorie
Qu’est-ce qu’un Product Manager Green ?
Qu’est-ce qu’un Product Manager Green ?
​​Comment être un bon Product Manager mobile ?
​​Comment être un bon Product Manager mobile ?
Comment WeFiiT a accompagné la scale-up industrielle CHR Numérique à devenir une entreprise product-centric ?
Comment WeFiiT a accompagné la scale-up industrielle CHR Numérique à devenir une entreprise product-centric ?