Cet article va certainement bouleverser de nombreuses personnes.
Je suis désolé pour cela, mais le degré de bruit et de confusion qui entoure le rôle des produits dans les entreprises technologiques ne fait qu’empirer. De plus, je vois les problèmes et les comportements problématiques s’institutionnaliser dans les conférences, les programmes de formation et les soi-disant programmes de certification pour les gens du produit.
J’ai parlé de ce problème à plusieurs reprises dans le passé, plus précisément dans l’article et le discours sur les équipes de produits autonomes. Cependant, tant de gens n’entendent que ce qu’ils veulent, et il m’est devenu clair que je dois être plus explicite.
Donc, même si cet article peut être pénible à lire, si vous avez été frustré par les messages contradictoires et déroutants des gens dans le monde des produits, si vous me suivez ici, j’espère que cela apportera une clarté bien nécessaire.
Dans le monde de la technologie, il existe en réalité trois types distincts d ‘«équipes produit».
Les plus courants en termes de chiffres ne sont pas vraiment des équipes de produits, ils sont équipes de livraison. Aussi appelé «équipes de développement» ou «équipes de mêlée» ou «équipes d’ingénierie» et si votre entreprise gère quelque chose comme SAFe, alors malheureusement c’est vous. Dans cette situation, il existe un certain nombre de développeurs et un propriétaire de produit. Le propriétaire du produit dans ce modèle est ce que j’appelle un «administrateur de backlog». Quelqu’un a besoin de faire ce travail administratif, mais il s’agit de fournir des résultats, et cela n’a vraiment rien à voir avec ce qui me préoccupe en termes de besoin d’une véritable innovation cohérente au nom de nos clients. J’ai écrit ailleurs sur les raisons pour lesquelles ce modèle est vraiment juste une cascade reconditionnée et n’est pas utilisé dans les véritables sociétés de produits technologiques. Alors mettons ça de côté.
Cet article traite vraiment de la différence entre les deux autres types d’équipes.
Maintenant, avertissement juste que je suis sur le point d’introduire une nomenclature non standard et certainement pas convenue. Mais je dois le faire parce qu’aujourd’hui, en tant qu’industrie, nous appelons les deux autres types d’équipes des «équipes de produits» ou des «équipes». Mais comme vous le verrez, bien qu’elles se ressemblent à un niveau superficiel, elles sont radicalement différentes, surtout lorsque nous parlons du rôle du chef de produit.
Quand j’ai écrit sur les vertus des équipes de produits autonomes, je faisais référence à ce que je continuerai d’appeler ici équipes produits. Plus précisément, ils sont interfonctionnel (produit, conception et ingénierie); ils sont concentrés et mesurés par résultats (plutôt que de sortie); et ils sont habilité pour trouver la meilleure façon de résoudre les problèmes qu’on leur a demandé de résoudre.
Le but d’une équipe produit dans ce sens est de résoudre les problèmes comme nos clients les aiment, tout en travaillant pour notre entreprise.
Autant que je pourrais souhaiter le contraire, je sais que seul un petit pourcentage d’équipes existe dans ce sens.
Bien plus souvent qu’autrement, les équipes ne sont pas du tout habilitées. En revanche, ils sont là pour servir l’entreprise.
Dans cet article, je qualifierai cette troisième classe d’équipes de équipes vedettes. Je plie un peu la définition plus établie des équipes de fonctionnalités ici, mais j’utilise le terme parce qu’il permet de souligner que ces équipes sont toutes axées sur la sortie. Caractéristiques, et parfois des projets. Habituellement fourni à l’équipe sous la forme d’une liste prioritaire qui s’appelle la feuille de route.
Mais c’est ici que je dois approfondir.
Rappelons que dans un produit, il y a toujours quatre risques:
- Valeur risque (les gens vont-ils l’acheter ou choisir de l’utiliser?)
- Convivialité risque (les utilisateurs peuvent-ils comprendre comment l’utiliser?)
- Faisabilité risque (pouvons-nous le construire avec le temps, les compétences et la technologie dont nous disposons?)
- Viabilité commerciale risque (cette solution fonctionnera-t-elle pour les différentes dimensions de notre entreprise?)
Dans une équipe de produits habilitée, le chef de produit est explicitement responsable de valeur et viabilité; le concepteur est responsable d’assurer utilisabilité; et le responsable technique est chargé d’assurer faisabilité. L’équipe y parvient en collaborant véritablement dans un intense, donner et prendre, afin de découvrir une solution qui fonctionne pour nous tous.
Quand je parle et écris à quel point il est difficile d’être un vrai chef de produit d’une équipe de produits compétente, c’est précisément parce qu’il est si difficile d’assurer la valeur et la viabilité. Si vous pensez que c’est facile à faire, veuillez lire ceci.
Cependant, dans une équipe de fonctionnalités, vous avez (espérons-le) un concepteur pour assurer la convivialité, et vous avez des ingénieurs pour assurer la faisabilité, mais, et cela est essentiel à comprendre: le la valeur et la viabilité de l’entreprise sont la responsabilité de la partie prenante ou de l’exécutif qui a demandé la fonctionnalité sur la feuille de route.
S’ils disent qu’ils ont besoin de vous pour créer la fonctionnalité x, ils croient que la fonctionnalité x fournira une certaine valeur, et ils pensent que la fonctionnalité x est quelque chose de 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, les capacités critiques ont été réduites pour faire la date, etc. Et bien sûr, votre équipe n’a probablement jamais été convaincue que cela valait la peine d’être construit en premier lieu. C’est une vieille chanson et j’ai beaucoup écrit sur ce problème.
Superficiellement, une équipe de fonctionnalités et une véritable équipe de produits autonomes sont les deux équipes. Ils se ressemblent donc, mais les différences sont profondes.
Commençons par le rôle du chef de produit. Dans une équipe de produits responsabilisée, où le chef de produit doit assurer la valeur et la viabilité, une connaissance approfondie du client, des données, de l’industrie et surtout de votre entreprise (ventes, marketing, finance, support, juridique, etc.) est absolument non négociable et essentiel.
Pourtant, au sein d’une équipe technique, ces connaissances sont (au mieux) dispersées entre les parties prenantes.
Dans tous les cas, nous espérons qu’il est clair que les responsabilités du chef de produit dans ce modèle sont très différentes pour une équipe de fonctionnalités.
Le travail du chef de produit dans une équipe de fonctionnalités est le plus souvent décrit comme une forme de facilitateur, «élevant les chats» afin d’obtenir la fonctionnalité conçue et livrée, ou une forme nébuleuse et faible de leader interfonctionnel qui n’est pas vraiment responsable pour quelque chose de spécifique. Ces équipes de fonctionnalités penseront souvent qu’elles font de la découverte de produits, mais en réalité, il s’agit simplement de conception et peut-être de quelques tests d’utilisabilité.
Mais il y a d’autres conséquences de l’équipe technique sur le rôle de chef de produit.
Parce que l’équipe n’est pas habilitée – pour être clair, quand on vous donne un résultat à livrer, vous ne pas responsabilisés dans tout sens – il est très difficile d’attirer et de retenir de vrais concepteurs de produits (une personne qualifiée dans la conception de services, la conception d’interactions, la conception visuelle et la recherche d’utilisateurs).
Dans la grande majorité des cas où vous avez des équipes de fonctionnalités, le concepteur (s’il y en a un) est un 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 écart – quelqu’un doit comprendre au moins la conception d’interaction et, espérons-le, faire des recherches sur les utilisateurs. Par conséquent, il est très fréquent de voir la pression sur le chef de produit dans ce modèle pour essayer de combler ces lacunes.
Il y a des conséquences négatives supplémentaires de cette situation, car il n’est pas difficile d’apprendre les outils que les concepteurs utilisent, mais il est difficile d’apprendre à faire une bonne conception et à rechercher des utilisateurs. Malheureusement, de nombreux chefs de produit n’ont jamais eu l’occasion de travailler avec un vrai concepteur de produit professionnel, de sorte qu’ils ne savent même pas ce qui leur manque.
Si vous avez la chance d’avoir un véritable concepteur de produits dans votre équipe (au moins jusqu’à ce qu’ils partent pour une entreprise où leurs compétences peuvent être pleinement utilisées), ils se demandent généralement (et à juste titre) quel est l’objectif du produit le gestionnaire est, car il n’est pas difficile pour eux d’assumer les responsabilités supplémentaires du chef de produit de l’équipe de fonctionnalités car ils font de toute façon l’essentiel du travail.
Le résultat est que dans les équipes de fonctionnalités, le rôle de chef de produit est principalement le chef de projet et partiellement le concepteur (non qualifié).
Il y a souvent une frustration similaire chez les ingénieurs. Le chef de produit qui est vraiment un chef de projet est souvent en désaccord avec la façon dont les ingénieurs pensent qu’ils doivent travailler. Sans oublier que dans ce modèle, les ingénieurs sont relégués à la livraison, et comme je l’ai dit à plusieurs reprises, si c’est le cas, nous n’obtenons que la moitié de leur valeur réelle (encore une fois, les bons voudront partir et rejoindre une équipe de produits habilités où ils peuvent vraiment pratiquer leur métier).
Donc, pour terminer sur ce point critique, lorsque j’écris que le chef de produit doit «être parmi les talents les plus forts de l’entreprise» et «le PDG devrait considérer les chefs de produit comme de futurs futurs leaders de l’entreprise» et «le un chef de produit solide est le PDG du produit. “Je suis très certainement ne pas parler d’un chef de produit pour une équipe de fonctionnalités.
J’espère qu’à ce stade, vous savez si vous travaillez dans un modèle d’équipe technique ou un modèle d’équipe produit habilité, mais j’ai appris que les gens sont souvent très réticents à admettre lorsqu’ils sont dans le modèle d’équipe technique.
Voici donc quelques tests que vous pouvez appliquer à votre équipe:
- Des feuilles de route vous sont-elles fournies avec des fonctionnalités et des dates hiérarchisées, ou des problèmes vous sont-ils attribués pour résoudre les résultats commerciaux?
- Y a-t-il une confusion de rôles entre vous et votre designer?
- Y a-t-il une confusion de rôles entre vous et votre responsable de livraison?
- Passez-vous la majeure partie de votre journée à faire de la gestion de projet?
- Avez-vous essayé d’utiliser OKR et était-ce un gâchis, soit rejeté, soit un mashup artificiel de résultats et de fonctionnalités fournis?
- Avez-vous une équipe de missionnaires ou de mercenaires?
- Quel est le niveau de responsabilité?
Bien que les équipes de fonctionnalités et les équipes de produits semblent très similaires à première vue, elles sont radicalement différentes dans leur fonctionnement, le niveau d’autonomisation et de responsabilité, et en particulier les responsabilités du chef de produit.
Je peux vous dire qu’à quelques exceptions près, les meilleures équipes de produits dans les meilleures entreprises se concentrent sur le modèle d’équipe de produits habilité. Cependant, je dois admettre que même dans ce que je considère comme les meilleures sociétés de produits, toutes les équipes de produits ne sont pas habilitées. En vérité, certains sont des équipes techniques. Habituellement, c’est parce que les dirigeants ne font 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 leader veut dicter des solutions.
Je n’ai jamais essayé de cacher mon fort parti pris envers des équipes de produits véritablement autonomes. Mais je crois que je dois maintenant aller plus loin que simplement plaider pour des équipes autonomes; Je dois appeler les équipes techniques, les problèmes qu’elles causent et les mauvais résultats qu’elles fournissent.
D’innombrables entreprises réalisent aujourd’hui la futilité du modèle d’équipe de livraison, et elles savent qu’elles doivent se transformer en une véritable entreprise de produits reposant sur la technologie, mais elles pensent qu’elles peuvent «cocher cette case» en apportant les modifications superficielles pour passer à ces équipes de fonctionnalités. .
En terminant, je tiens à souligner la différence entre être un chef de produit pour une équipe technique et une équipe produit habilitée. C’est un travail complètement différent, nécessitant des compétences très différentes. Il ne devrait probablement même pas s’agir du même titre d’emploi.
Il est triste pour moi que tant de concepteurs et d’ingénieurs n’aient jamais été exposés à un véritable chef de produit et n’aient jamais pu travailler au sein d’une équipe véritablement compétente. C’est pourquoi je soutiens qu’il y a tellement de talents sous-utilisés et pourquoi je continue d’essayer de persuader les gens d’essayer de travailler comme les meilleures entreprises.
Une chose que vous pouvez faire immédiatement est que la prochaine fois que vous lirez un article ou un tweet lié au produit, assisterez à une conférence ou assisterez à une formation sur les produits, demandez-vous si l’auteur, le conférencier ou le formateur parle du modèle d’équipe de produit habilité, ou le modèle d’équipe de fonctionnalité?
MISE À JOUR: J’ai publié un article de suivi traitant de nombreuses questions que j’ai reçues à propos de ce message.
