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.
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 :
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.
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 :
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.
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 :
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.
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.
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.
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.
“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é :
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 ?
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. 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.
Le spécialiste du conseil fullstack Produit : Strategy, Discovery & Delivery !
