Deux Product Managers par Impact Team

Après la parution de l’article Product Owner ou Product Manager, vous avez été nombreux à me poser des questions sur l’organisation de nos équipes, notamment sur la charge de travail pour un Product Manager.

En 2019, quand on demande à un Product Manager s’il est important de faire du Discovery, il va dans 99% des cas dire oui. Il va également ajouter qu’il a lu des articles à ce sujet et qu’il est convaincu de la démarche. Mais il n’a jamais le temps de le faire. Parfois, il ne sait tout simplement pas comment faire, mais c’est un autre sujet.

QA, analyse de données, rédaction de User Stories, contributions aux rituels agiles : la journée d’un Product Manager déborde d’activités, et son périmètre n’étant jamais clairement défini il a toujours quelque chose à faire.

Parce que nous sommes convaincus qu’un bon Discovery fait économiser un temps considérable de toutes les équipes d’une entreprise (et pas seulement les développeurs), nous avons souhaité libérer du temps aux Product Manager. Mais nous ne voulions pas créer des rôles transverses dont dépendraient plusieurs équipes.

Nous avons choisi d’intégrer deux Product Managers et un Product Designer dans nos Impacts Teams. Parce que quand vous n’avez pas le temps, c’est toujours le Discovery qui subit.

Comment en sommes-nous venus à intégrer deux Product Managers par équipe ?

Tout d’abord en créant nos Impacts Teams. Ces équipes pluridisciplinaires auto-organisées en charge d’un objectif chiffré (s’inspirant de la méthode OKRs), sont constituées de 4 à 8 développeurs, 1 Product Designer et 2 Product Managers.

Nous n’avons pas de rôle transverse de QA : le Product Manager écrit les User Stories et les critères d’acceptance, l’équipe de développement rédige des tests unitaires et fonctionnels automatisés lors de chaque développement ce qui limite le temps passé en QA.

Nous n’avons pas non plus de rôle transverse de Product Analyst : chaque Product Manager est autonome pour lancer ses requêtes SQL, s’appuyer sur les travaux d’harmonisation des flux de la BI et utiliser Google Analytics. Les PMs doivent même passer leur certification Google Analytics à leur arrivée chez nous.

Pas non plus de rôle de UI Designer : on retrouve la même logique “Product Manager ou Product Owner” dans notre conception du rôle des Product Designers : un rôle complet qui regroupe les compétences UX et UI… mais cela fera l’objet d’un autre article !

Et là vous devez vous dire : ça fait pas beaucoup de travail pour un PM ?

Et vous avez raison.

Pourquoi ne pas simplement créer ces rôles transverses ?

L’absence de rôle de « QA » et de « Product Analyst » au sein de l’équipe produit est une volonté forte que nous avons eu chez Meilleurs Agents : nous souhaitons avoir des profils qui soient responsables et capables de créer les bons produits de A à Z. Cette responsabilité du produit tout au long de la chaîne aide à prendre en compte les contraintes (développement, impacts sur le business etc.) très tôt dans la réflexion et limite les allers retours entre la conception et la réalisation.

C’est cette même volonté qui nous a poussé à ne pas séparer les rôles de Product Owner et Product Manager. Vous voulons que le Product Manager soit en action sur l’ensemble des éléments du CORE Framework. Ce framework, documenté dans Product Management In Practice, explique que le Product Manager a trois grandes famille de compétences : Communication, Organisation, Recherche et Exécution. Pour plus de détails, vous pouvez voir notre article Product Owner ou Product Manager.

Nous avons la conviction que chaque rôle transverse nous éloigne de l’autonomie que nous souhaitons pour l’équipe. Nous ne renions cependant pas le fait que nous avons parfois besoin d’experts et allons chercher cette expertise quand nécessaire ! Mais l’équipe peut prendre des décisions et livrer de la valeur bien plus rapidement si elle est autonome sur l’ensemble du processus.

Pour la rendre autonome, nous avons donc choisi d’élargir le champ de compétence des Product Managers et des Product Designers, et de lui confier des objectifs chiffrés clairs pour guider ses décisions.

Il se passe quoi quand il n’y a qu’un PM dans l’équipe ?

1. Il n’a pas le temps

On a beau se répéter “no time is no excuse”, quand les responsabilités et activités d’un rôle ne rentrent pas dans une journée de travail, il faut faire des choix.

D’expérience, ce problème sacrifie systématiquement le Discovery. D’une part parce qu’on a tous en tête que la ressource limitante est la force de développement ce qui nous rend effrayé à l’idée de la laisser sans travail une journée. Comme si un backlog vide était pire qu’un backlog plein de mauvais sujets. D’autre part parce que le temps à consacrer à la phase de recherche est moins simple à prévoir que le temps nécessaire pour spécifier une ou plusieurs fonctionnalités.

2. Il a besoin de “ressources externes” et tout devient plus lent

En 2019, nous sommes tous convaincus qu’une petite équipe autonome va plus vite qu’une équipe travaillant en silos. Malheureusement cette conviction semble nous échapper dans la construction des équipes Produits. Il y a de plus en plus d’équipes qui décident de créer un “pôle” recherche utilisateur séparé des feature / component / impact teams.

Si cette construction garantit d’avoir une ressource experte sur le sujet de la recherche utilisateur, elle crée un goulet d’étranglement assez net : les équipes en charge du Delivery sont désormais dépendantes de la bande passante d’une autre équipe en charge de la recherche. Si en phase de priorisation du backlog on se pose une question imprévue, il faudra alors demander à l’équipe recherche de consacrer de la bande passante pour mener les études, ce qui peut considérablement rallonger les temps de décisions !

Comment s’organise le travail entre les deux Products Managers ?

En théorie, à tout instant un PM est en charge de la Discovery et un PM est en charge du Delivery. Cela nous permet de constamment augmenter notre niveau de confiance en la prochaine initaitive qui sera développée, tout livrant déjà de la valeur aux utilisateurs. On ne fait en revanche pas de transfert entre le PM Discovery et le PM Delivery : le PM qui mène la phase de Discovery ira faire celle de Delivery du même sujet, quand il y aura de la place dans les sprints de l’équipe. Son rôle est donc d’amener le sujet à un niveau de confiance acceptable pour nous permettre de le lancer en Delivery. Il est alors responsable du Delivery de ce même sujet. Ainsi, on évite d’avoir un PM en charge d’une phase et un autre PM en charge de l’autre.

Nous n’avons pas calqué la phase de Delivery avec la vision en Sprint de quinze jours: cette recherche, quand il s’agit d’un nouveau produit ou d’une fonctionnalité majeure (plusieurs semaines de travail), peut durer bien plus qu’un Sprint.

En pratique, chaque PM est leader de l’équipe pour son sujet, mais ces PMs vont également s’entraider selon les phases dans lesquelles ils se trouvent. Par exemple, si l’équipe vient de conduire un atelier de storymap et chercher à initier le backlog, le PM en charge de Discovery va prêter main forte à celui en charge du Delivery. Avec le temps, on estime que le PM en lead sur le Discovery va y passer 70% de son temps et contribuera tout de même à hauteur de 30% au Delivery. Et inversement pour le PM en lead sur le Delivery.

Il est important aussi de préciser qu’un Product Designer est avec les deux Products Managers à temps plein : lui aussi doit répartir son temps entre Delivery et Discovery, selon un partage du travail établit au cas par cas avec les Products Managers de son équipe.

En conclusion, créer une pratique de Discovery est essentiel pour limiter le gâchis et bénéficier au maximum des équipes. Pour permettre à cette pratique d’émerger, en plus de former vos collaborateurs, il va être indispensable de leur laisser du temps !

Nous avons de nombreux bénéfices à cette organisation avec deux Products Managers :

• Pas d’effet silos entre Discovery et Delivery
• Une même personne en charge du Delivery et du Discovery nous aide à prendre les bonnes décisions dans toutes les phases de vie du produit.
• Les Product Managers ont un parcours carrière clair et épanouissant qui leur permet de toucher à plus de choses que “seulement” du Delivery.

Notre challenge avec la croissance de nos équipes en 2020 va être la centralisation et le partage des apprentissages des phases de recherches : un beau sujet d’organisation en perspective !

Dernières mises à jour :

• 30/12/2019 : ajout de la section “comment s’organise le travail entre deux Products Managers” en réponse à la question d’Adrien.