Aller au contenu

Feature Team VS Product Team : de quelle équipe produit êtes-vous le 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 la 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 interroger ici. 

Sommaire

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 vous connaissez 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 vous êtes surtout amenés à faire le pont entre Business et Tech, à traduire des besoins métier en spécifications, voire à faire office de “passe-plat” entre votre interlocuteur business et votre chef de projet IT. 

Product Manager, Product Owner, ces termes sont utilisés de manière un peu abusive ici : dans les faits vous êtes 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 vous restez 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 à votre équipe : 

  • Vous exercez une faible influence sur le choix des sujets et des fonctionnalités à prioriser 
  • Vous faites peu ou pas de Discovery (peu d’intérêt puisque les solutions sont déjà définies en amont par d’autres interlocuteurs) 
  • Vous avez peu ou pas de visibilité sur la valeur client et l’impact business générés par vos évolutions
     

En bref : vous êtes objectivés avant tout sur votre capacité à livrer des “outputs”. 

outcome vs output

Votre équipe ressemble davantage à une petite usine à fonctionnalités, et vous à 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, théorisée par Marty Cagan, 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, vous prenez la main en tant que Product Manager sur l’ensemble de votre produit et vous endossez 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. 

Vous êtes donc pleinement responsabilisés sur l’atteinte – ou non – de vos OKR. 

Cela représente une rupture majeure avec la Feature Team où cette responsabilité était diluée avec vos interlocuteurs business : vous ne pouviez être tenu responsable des résultats d’une solution que vous n’aviez pas choisie. 

Plein cap sur la 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 : puisque vous choisissez les fonctionnalités que vous développez, vous devez assumer la valeur client et l’impact business qu’elles génèrent. 

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 vous sont assignés (OKR).

Ici, vous êtes pleinement Product Manager, avec un ownership complet sur votre produit. 

Conclusion Feature Team et product Team

comparaison feature team vs product team

Fort de cette distinction, de quelle équipe produit êtes-vous le Product Manager ? 

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.  

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.