Réorganisation des équipes produits | – Octets de produit de Rich Mironov

Lors des ateliers pour les chefs de produit, nous discutons souvent de différentes approches exécution changements organisationnels majeurs au sein des équipes de gestion des produits et des groupes adjacents (par exemple, l’ingénierie). Sans surprise, la réponse générale est “ça dépend”Sur de nombreux facteurs. Mais il vaut la peine de récapituler certains des choix et leurs implications.

Tout d’abord, un clin d’œil à Saeed Khan, qui souligne qu’il n’existe pas de modèle organisationnel universel et parfait dans toutes les équipes produits et toutes les situations. Paraphraser:

Les gens veulent savoir ce qui a bien fonctionné dans d’autres entreprises prospères, car on suppose que cela pourrait bien fonctionner pour eux… c’est compréhensible. Mais ce qui a fonctionné chez Spotify ou Shopify ou Stackify ne fonctionnera pas nécessairement pour eux.

Et récemment, un chef de produit chez Spotify a partagé que son groupe (et bien d’autres dans son entreprise) ont évolué vers des modèles organisationnels très différents de ceux décrits dans Henrik Kniberg. 2012 Scaling Agile @ Spotify. J’ai vu à plusieurs reprises que couper et coller l’organisation de quelqu’un d’autre ignore la dure rétrospection sur ce qui ne fonctionne pas (et ce qui fonctionne bien) dans votre propre entreprise.

Une fois que nous (en tant que chefs de produit) avons choisi un nouveau modèle d’organisation de produit, nous avons également besoin d’une stratégie pour y arriver. Big Bang? Équipe incrémentale par équipe? Participation facultative? Changer la façon dont une équipe de gestion de produit divise son travail – et comment elle interagit avec les groupes de développement / conception / marketing – concerne autant la gestion du changement que les organigrammes.

J’ai donc présenté deux grands exemples de changements organisationnels ainsi que des idées pour les déployer. J’espère que vous verrez qu’une taille unique ne convient pas à tous et que la compréhension de votre organisation actuelle est essentielle pour planifier toute transition.

[1] Projets de services professionnels → Équipes de produits stables

Il est typique que les entreprises de services professionnels et les ateliers de développement sur mesurejectpools de ressources basés sur. Comme chaque nouveau project arrive, nous formons une équipe de courte durée pour ce projet en fonction des besoins perçus et de la disponibilité du personnel. À la fin, cette équipe est détruite et nous formons de nouvelles équipes de projet. L’entreprise gagne de l’argent en baliser le temps de développement / conception, il y a donc une forte incitation à commencer un nouveau travail rémunéré dès la fin des engagements actuels. Et les entreprises de services n’ont généralement pas product managers: au lieu de cela, les clients individuels nous disent ce qu’ils veulent chacun et nous le concevons de manière rentable sur mesure. Pas besoin de validation du marché, de calculateurs de retour sur investissement, d’analyse concurrentielle, de modèles de tarification par siège ou de feuilles de route à plusieurs versions.

Mais de nombreuses entreprises de services disent vouloir entrer product business: construisez quelque chose une fois et demandez à de nombreux clients de payer pour ce même morceau de technologie. C’est de l’argent presque gratuit! En réalité, ils lancent rarement des produits, car les membres (théoriquement) dévoués de cette équipe de produits sont à plusieurs reprises amenés à travailler sur le projet du trimestre en cours pour générer des revenus pour le trimestre en cours. Des morceaux de produits inachevés flottent autour avec un ensemble rotatif de travailleurs à temps partiel les ramassant et les déposant à nouveau.

Qu’est-ce qu’une meilleure approche?

Je suis un fervent partisan d’équipes de produits entières engagées à long terme: nous réunissons un groupe de deux pizzas de développeurs, de concepteurs, de spécialistes des produits et d’ingénieurs en automatisation des tests qui resteront fidèles au produit qui leur a été attribué pendant de nombreuses versions et le développeront. Ils doivent comprendre en profondeur leurs utilisateurs finaux ainsi que leurs acheteurs, posséder leurs propres bogues et leurs dettes technologiques, parcourir un carnet de commandes stratégique de la version 1.0 à la version 3.0 à la version 8.3 et se concentrer sur les ventes en volume plutôt que sur les demandes des clients uniques. Dans un vrai sens, l’équipe est synonyme du produit.

Comment pouvons-nous y arriver?

Nous pourrions simplement nous déclarer comme une entreprise de produits et affecter tout le monde à des rôles récemment inconnus. Big Bang. Avant d’annoncer tout changement organisationnel, il convient de deviner les objections probables, le recul, les différences de compétences et les normes culturelles. Votre situation peut être différente, mais dans les entreprises de services, je vois chaque processus réglé pour dire «oui» chaque fois qu’un client veut payer quelque chose. Les ventes apportent une perspective, nous dimensionnons le travail et nous sautons pour fournir une solution unique sur mesure pour cette seule entreprise. Les mesures de l’entreprise concernent marge basée sur le projet et garder notre organisation de développement chargée de facturer son temps. C’est diamétralement opposé à la façon dont les sociétés de produits pensent – les sociétés de produits veulent des installations reproductibles à faible friction avec le moins de prise en main possible, afin de vendre à des centaines / milliers / millions d’utilisateurs une seule ligne de code à des prix bien inférieurs à ce que les clients dépenseraient pour la construire. se.

Nous devons donc nous attendre à une énorme résistance organisationnelle au passage des approches de service aux approches de produit:

• Les équipes commerciales sont formées et récompensées pour apporter tout ce qu’un client dit vouloir, au lieu de trouver des acheteurs intéressés uniquement par ce que nous avons construit
• Le personnel de développement était habitué à interrompre les projets à la fin, avec peu de lien émotionnel avec les utilisateurs finaux ou un engagement à long terme pour un code compatible
• Lacunes dans les compétences du personnel actuel: aucune expérience de validation critique des concepts de produits; dimensionnement des segments de marché (“Combien différent les clients ont besoin de cette chose exacte et combien vont-ils payer pour cela? »); estimer l’impact réel sur l’entreprise en unités mesurables; repousser dur sur les one-offs et les spéciaux.

Donc une approche possible…

Nous pourrions créer une équipe de développement entière, affectée à un produit sélectionné à la main. Cette équipe comprendrait des personnes clés: développeurs, concepteur, architecte, ingénieur en automatisation des tests, documentation technique. Et comme il est peu probable que nous ayons quelqu’un en interne qui gère avec succès des logiciels commerciaux via plusieurs versions, nous allons à l’extérieur pour embaucher un chef de produit chevronné et politiquement avisé qui sait déjà guider les équipes / produits du concept à la livraison.

Et anticipant que le comportement des dirigeants sera notre plus grand défi, nous aurons besoin d’un chef de produit de niveau C pour limiter les interruptions de niveau C. Au cours des premières semaines d’existence de cette équipe, nous verrons des dizaines d’escalades vers les dirigeants d’entreprise de demandes de style services professionnels: “Project Zed a besoin d’un développeur frontal, nous allons donc emprunter à l’équipe produit pendant une semaine seulement” et “Big Client Y veut presque ce que le team building, mais en a besoin sur place plutôt que dans le cloud, donc nous allons peaufiner l’architecte un tout petit peu” et “J’ai une idée de produit qui est encore meilleure que ce que nous construisons: examinons cela à la place.”

A mon humble avis, le principal mode d’échec pour les équipes de produits au sein des sociétés de services est qu’elles ne sont pas autorisées à terminer quoi que ce soit. Chaque jour apporte de nouvelles interruptions et de nouvelles opportunités. Ainsi, certains cadres expérimentés en produits ont besoin de suffisamment d’influence pour défendre notre toute première équipe de produits.

Cela peut prendre quelques trimestres ou plus, car la construction de produits reproductibles est différente du travail de projet à usage unique. Une fois que nous avons obtenu quelque chose et obtenu un tout petit succès sur le marché, nous pouvons parler de former une deuxième équipe de produits.

[2] Propriétaire de produit étroit Scrum → Gestionnaire de produit de bout en bout

“Proxies” est un mot de quatre lettres

J’ai écrit et parlé largement sur la façon dont IMHO restreindre les définitions de propriétaire de produit n’encourage pas les produits logiciels commerciaux réussis. Les livres d’introduction Scrum se concentrent sur les activités de produits transactionnels – écrire des histoires, réorganiser les backlogs – en supposant que la stratégie de produit et les informations sur le marché arrivent comme par magie de l’extérieur. À mon avis, chaque produit devrait passer environ la moitié de son temps à écouter directement les utilisateurs finaux et les prospects réels. (Sans intermédiaire par les parties prenantes, les mandataires, les équipes de vente et les analystes de l’industrie.)

Lorsque je tombe dans des entreprises en tant que produit CPO / VP intérimaire, c’est l’une des premières choses que je considère. Je souhaite élargir les rôles de chef de produit en rôles de gestion de produit de bout en bout: chaque responsable de produit étant responsable à la fois du travail entrant (priorisation, définition des problèmes, définition des objectifs et des histoires pour une seule équipe) travail sortant (entretiens de détection de marché directs avec utilisateurs en direct, apprentissage en profondeur, validation du marché, emplois à faire axés sur la valeur, analyse concurrentielle). Il s’agit d’un grand changement dans le temps et l’accent.

Mais comment y arriver?

Il ne suffit pas de simplement déclarer qu’une équipe de propriétaires de produits a soudain des responsabilités beaucoup plus étendues et doit commencer à recueillir ses propres informations directes sur les utilisateurs / marchés. Nous risquons de rencontrer:

• Des lacunes importantes dans les compétences, où les OP ont été hermétiquement scellées dans des rôles liés au développement. La plupart d’entre eux manqueront d’expérience en entretien, d’outils de sensibilisation et de confort pour réinterpréter les plaintes de surface en problèmes de produits sous-jacents.
• Reprise des équipes de vente et de développement commercial, qui sont l’habitude d’écrire les exigences elles-mêmes. «Nous discutons avec les clients toute la journée et savons ce qu’ils veulent.»
• Amélioration lente. Cela peut prendre un quart (ou deux ou trois) pour qu’un flux constant de commentaires directs des utilisateurs modifie les attitudes, les plans de produits et les taux de désabonnement. Les idées prennent du temps. Pendant ce temps, revenir au modèle précédent est une tentation quotidienne.
• Les modifications apportées à la gestion des produits n’accélèrent pas le développement. J’entends des plaintes sans fin de la part des cadres supérieurs selon lesquelles les équipes d’ingénierie sont trop lentes ou improductives, bien que je ne trouve presque jamais cela vrai dans la pratique. Il faut du temps pour démontrer que la construction des bonnes choses – avec les chefs de produit dé-priorisant impitoyablement tout le reste – est la façon dont nous mettons plus d’efforts contre la valeur réelle et gaspillons moins sur les objets brillants.

Donc une approche possible…

J’aime choisir un propriétaire de produit à fort potentiel et son équipe de développement dédiée pour un pilote. Commencez, découvrez les problèmes ou les obstacles, adaptez-vous comme nous le faisons. Appelez cela une expérience, découvrez les obstacles organisationnels. Et je prévois un coaching / mentorat personnel intensif sur le travail sortant axé sur l’expérience:

Si nous le faisons bien, la plupart des organisations de produits et de développement verront le bien et voudront y participer. (Voir Tom Sawyer et la peinture de clôture.) En cours de route, quelques propriétaires de produits actuels peuvent demander des rôles de développement ou de gestion de projet au lieu de cela. travail sortant mixte.

Octet sonore

Les organisations sont complexes et le changement est difficile. Simplement publier un nouvel organigramme ou annoncer un nouvel ensemble de responsabilités n’y fait rien. En tant que chefs de produit, nous devons comprendre nos propres situations, bloqueurs et bassin de talents. Élaborez ensuite un plan pour «vendre» le changement tout en le mettant en œuvre. Cela ressemble beaucoup à l’application d’une pensée agile aux organisations.