Equipes Produit vs Equipes Feature

Auteur : Marty Cagan
Source : Product vs. Feature Teams
Date : 29/08/2019

---

Traducteur : Fabrice Aimetti
Date : 14/11/2022

---

Traduction :

Cet article va certainement contrarier de nombreuses personnes.

J'en suis désolé, mais le niveau de bruit et de confusion qui entoure le rôle du produit dans les entreprises technologiques ne fait qu'empirer. De plus, je constate que les questions et les comportements problématiques sont institutionnalisés dans les conférences, les programmes de formation et les soi-disant programmes de certification pour les responsables des produits.

J'ai abordé cette question à plusieurs reprises dans le passé, plus particulièrement dans l'article et la conférence sur les équipes produits émancipées (fr) (NdT : choix tout à fait personnel pour traduire empowered product teams). Cependant, beaucoup de gens n'y entendent que ce qu'ils veulent entendre, et il est devenu évident pour moi que je dois être plus explicite.

Alors, bien que cet article puisse être pénible à lire, si vous avez été frustré par les messages contradictoires et confus des personnes dans l'univers des produits, si vous me faites confiance, j'espère que cet article apportera un éclairage indispensable.

Dans le monde de la technologie, il existe trois types distincts d'"équipes produits", au sens large.

Les plus courantes en nombre ne sont pas vraiment des équipes produits, mais des équipes delivery. Elles sont également appelées "équipes de développement", "équipes Scrum" ou "équipes d'ingénierie". Si votre entreprise utilise une méthode comme SAFe, vous êtes malheureusement dans ce cas. Dans cette situation, il y a un certain nombre de développeurs, et un Product Owner. Le Product Owner dans ce modèle est ce que j'appelle un "administrateur du backlog". Il faut bien que quelqu'un s'occupe de ce travail administratif, mais il s'agit avant tout de produire des résultats, et cela n'a pas grand-chose à voir avec ce qui me préoccupe, à savoir la nécessité d'une innovation véritable et cohérente pour nos clients. J'ai écrit ailleurs pourquoi ce modèle n'est en fait qu'un cycle en V repackagé, et n'est pas utilisé par les véritables entreprises de produits technologiques. Alors, laissons tomber cette idée.

Cet article porte en réalité sur la différence entre les deux autres types d'équipes.

Je vous préviens que je suis sur le point d'introduire une terminologie qui n'est pas standard et qui ne fait certainement pas l'unanimité. Mais je dois le faire parce qu'aujourd'hui, dans notre secteur, nous appelons les deux autres types d'équipes "équipes produits" ou "brigades". Mais comme vous le verrez, bien que ces deux types d'équipes se ressemblent à un niveau superficiel, elles sont radicalement différentes, surtout lorsque nous parlons du rôle du product manager.

Lorsque j'ai écrit sur les vertus des équipes produits émancipées (fr), je faisais référence à ce que je continuerai à appeler ici les équipes produits. Plus précisément, elles sont pluridisciplinaires (produit, conception et ingénierie), elles se concentrent sur les résultats/outcomes (plutôt que sur la production/output) et sont mesurées en fonction de ceux-ci, et elles sont émancipées pour trouver la meilleure façon de résoudre les problèmes qu'on leur a demandé de résoudre.

Dans cette optique, l'objectif d'une équipe produit est de résoudre les problèmes d'une manière qui satisfasse à la fois nos clients et notre entreprise.

Même si je souhaiterais qu'il en soit autrement, je sais que seul un faible pourcentage des équipes sont des équipes produits au sens propre du terme.

Le plus souvent, les équipes ne sont pas du tout émancipées. En revanche, elles sont là pour servir le métier.

Dans cet article, j'appellerai cette troisième catégorie d'équipes les équipes features (feature teams). Je m'écarte un peu de la définition habituelle des équipes features, mais j'utilise ce terme parce qu'il permet de mettre en évidence le fait que ces équipes se concentrent sur les résultats. Des features, et occasionnellement des projets. Généralement fournies à l'équipe sous la forme d'une liste de priorités appelée feuille de route.

Mais c'est là que je dois aller plus loin.

Rappelons que dans un produit, il y a toujours quatre risques :

• le risque de valeur (les gens vont-ils l'acheter ou choisir de l'utiliser ?)
• le risque d'utilisabilité (les utilisateurs peuvent-ils trouver comment l'utiliser ?)
• le risque de faisabilité (pouvons-nous le construire avec le temps, les compétences et la technologie dont nous disposons ?)
• le risque de viabilité économique (cette solution fonctionnera-t-elle pour les différentes activités de notre entreprise ?)

Dans une équipe produit émancipée, le product manager est explicitement responsable de la valeur et de la viabilité du produit, le designer est responsable de l'utilisabilité et le responsable technique (tech lead) est responsable de la faisabilité. Pour ce faire, l'équipe collabore véritablement de manière intense, en donnant et en prenant, afin de découvrir une solution qui fonctionne pour chacun d'entre nous.

Lorsque je parle et écris à quel point il est difficile d'être un véritable product manager d'une équipe produit émancipée, c'est précisément parce qu'il est très difficile de garantir la valeur et la viabilité. Si vous pensez que c'est facile de le faire, lisez ceci.

Cependant, dans une équipe feature, il y a toujours (si tout va bien) un concepteur pour assurer l'utilisabilité et des ingénieurs pour assurer la faisabilité, mais, et il est crucial de le comprendre : la valeur et la viabilité économique sont la responsabilité de la partie prenante ou de la personne dirigeante qui a demandé la feature dans la feuille de route.

S'ils disent qu'ils ont besoin que vous construisiez la feature x, c'est qu'ils croient que la feature x apportera une certaine valeur, et qu'elle est viable pour l'entreprise.

Il convient de souligner que même si la partie prenante est implicitement responsable de la valeur et de la viabilité, elle trouvera toujours un moyen de vous blâmer, vous et votre équipe, si les résultats escomptés ne sont pas atteints. Cela a pris trop de temps, la conception était mauvaise, des caractéristiques essentielles ont été supprimées pour respecter la date, etc. Et bien sûr, votre équipe n'a probablement jamais été convaincue que le projet valait la peine d'être construit. C'est une vieille chanson et j'ai beaucoup écrit sur ce problème.

À première vue, une feature team et une véritable équipe produit émancipée sont toutes deux des brigades. Elles se ressemblent donc, mais les différences sont profondes.

Commençons par le rôle du product manager. Dans une équipe produit émancipée, où le product manager doit assurer la valeur et la viabilité, une connaissance approfondie du client, des données, du secteur et surtout de votre entreprise (ventes, marketing, finance, support, juridique, etc.) constitue un élément absolument non négociable et essentiel.

Pourtant, dans une équipe feature, ces connaissances sont (au mieux) dispersées parmi les parties prenantes.

Dans tous les cas, j'espère qu'il est clair que les responsabilités du product manager dans ce modèle sont très différentes de celles d'une feature team.

Le travail du product manager au sein d'une équipe feature est le plus souvent décrit comme une sorte de facilitateur, qui "garde les chats" afin d'obtenir la conception et la livraison de la feature, ou une forme nébuleuse et faible de leader pluridisciplinaire qui n'est pas vraiment responsable de quoi que ce soit de spécifique. Ces équipes features pensent souvent qu'elles font de la découverte de produit, mais il s'agit en fait de conception et peut-être d'un petit test d'utilisabilité.

Mais il y a d'autres conséquences de la feature team sur le rôle du product manager.

Comme l'équipe n'est pas émancipée - pour être clair, lorsqu'on vous donne des travaux à réaliser, vous n'êtes pas émancipé au sens propre du terme - il est très difficile d'attirer et de retenir de véritables concepteurs produits (une personne compétente en matière de conception de services, de conception d'interactions, de conception visuelle et de recherche sur les utilisateurs).

Dans la grande majorité des cas où vous disposez d'équipes features, le concepteur (s'il y en a un) est un concepteur graphiste. Ce n'est pas que la conception graphique ou visuelle n'est pas importante, mais ce qui est pertinent ici, c'est qu'il y a maintenant un grand vide - quelqu'un doit au moins définir la conception de l'interaction et, si possible, faire des recherches sur les utilisateurs. Dans ce modèle, il est donc très courant de voir apparaître une pression sur le product manager pour qu'il tente de combler ces lacunes.

Cette situation a d'autres conséquences négatives, car il n'est pas difficile d'apprendre les outils utilisés par les concepteurs, mais il est difficile d'apprendre à faire une bonne conception et une bonne recherche sur les utilisateurs. Malheureusement, de nombreux chefs produits n'ont jamais eu l'occasion de travailler avec un véritable concepteur produit professionnel, de sorte qu'ils ne savent même pas ce qui leur échappe.

Si vous avez la chance d'avoir un véritable concepteur produit dans votre équipe (du moins jusqu'à ce qu'il parte dans une entreprise où ses compétences peuvent être pleinement utilisées), il se demande généralement (et à juste titre) à quoi sert le product manager, car il n'est pas difficile pour lui d'assumer les responsabilités supplémentaires du product manager de l'équipe feature, puisqu'il fait de toute façon la majeure partie du travail.

Il en résulte que dans les équipes features, le rôle du product manager est principalement celui de chef de projet, et partiellement celui de concepteur (non compétent).

Il y a souvent une frustration similaire chez les ingénieurs. Le product manager, qui est en fait un chef de projet, est souvent en désaccord avec la façon dont les ingénieurs pensent devoir travailler. Sans compter que dans ce modèle, les ingénieurs sont relégués au développement et, comme je l'ai dit à plusieurs reprises, si c'est le cas, nous n'obtenons que la moitié de leur valeur réelle (donc, encore une fois, les bons ingénieurs voudront partir et rejoindre une équipe produit émancipée où ils pourront vraiment exercer leur métier).

Pour conclure sur ce point essentiel, lorsque j'écris que le product manager doit "faire partie des meilleurs talents de l'entreprise", que "le PDG doit considérer les product managers comme les futurs leaders potentiels de l'entreprise" et que "le product manager le plus fort est le PDG du produit", je ne parle absolument pas du product manager d'une équipe feature.

J'espère qu'à ce stade, vous savez si vous travaillez dans un modèle d'équipe feature ou dans un modèle d'équipe produit émancipée, mais j'ai constaté que les gens sont souvent très réticents à admettre qu'ils sont dans le modèle d'équipe feature.

Donc, voici quelques tests que vous pouvez appliquez à votre équipe :

• Vous fournit-on des feuilles de route avec des features prioritaires et des dates, ou vous assigne-t-on des problèmes à résoudre avec des résultats métiers ?
• Y a-t-il une ambiguïté dans les rôles entre vous et votre concepteur ?
• Y a-t-il une ambiguïté dans les rôles entre vous et votre responsable développement ?
• Passez-vous la majeure partie de votre journée à gérer des projets ?
• Avez-vous essayé d'utiliser les OKRs et c'était un vrai désastre, soit parce qu'ils ont été rejetés, soit parce qu'il y a eu un mélange artificiel de résultats et de features livrées ?
• Avez-vous une équipe de missionnaires ou de mercenaires ?
• Quel est le niveau de responsabilisation ?

Si les équipes features et les équipes produits se ressemblent beaucoup en apparence, elles sont très différentes dans leur mode de fonctionnement, le niveau d'émancipation et de responsabilisation, et surtout les responsabilités du product manager.

Je peux vous dire qu'à quelques exceptions près, les meilleures équipes produits des meilleures entreprises utilisent toutes le modèle de l'équipe produit émancipée. Cependant, je dois admettre que même dans ce que je considère comme les meilleures entreprises produits, toutes les équipes produits ne sont pas émancipées. En réalité, certaines sont des équipes features. En général, c'est parce que la direction ne fait pas encore confiance à cette équipe particulière. Parfois, cette confiance doit d'abord être gagnée. Et parfois, le problème vient du fait que le dirigeant veut dicter les solutions.

Je n'ai jamais essayé de cacher mon fort penchant pour les équipes produits réellement émancipées. Mais je crois que je dois maintenant aller plus loin que le simple plaidoyer en faveur des équipes émancipées ; je dois dénoncer les équipes features, les problèmes qu'elles causent et les mauvais résultats qu'elles produisent.

D'innombrables entreprises réalisent aujourd'hui la futilité du modèle de l'équipe de développement, et elles savent qu'elles doivent se transformer en une véritable entreprise de produits axée sur la technologie, mais elles pensent qu'elles peuvent "cocher cette case" en effectuant les changements superficiels nécessaires pour passer à ces équipes features.

Pour conclure, je tiens à souligner la différence entre un product manager pour une équipe feature et un product manager pour une équipe produit émancipée. C'est un travail complètement différent, qui requiert un ensemble de compétences très différent. Le titre du poste ne devrait sans doute pas être le même.

Je trouve triste que tant de concepteurs et d'ingénieurs n'aient jamais été exposés à un véritable product manager, et n'aient jamais pu travailler au sein d'une équipe véritablement émancipée. C'est pourquoi je prétends qu'il y a tant de talents sous-utilisés et que je continue à essayer de persuader les gens de travailler comme le font les meilleures entreprises.

La prochaine fois que vous lisez un article ou un tweet sur les produits, que vous assistez à une conférence ou à une formation sur les produits, demandez-vous si l'auteur, le conférencier ou le formateur parle du modèle d'équipe produit émancipée ou du modèle d'équipe feature.

MISE À JOUR : J'ai publié un article complémentaire répondant aux nombreuses questions que j'ai reçues à propos de ce billet.