Compréhension partagée : ce qui distingue les meilleures équipes produit

La compréhension partagée est la compétence principale d'une excellente équipe produit. Elle distingue les bonnes équipes des meilleures. Selon un Product Manager d'Atlassian avec onze ans d'expérience, le meilleur product manager n'est pas celui qui connaît toutes les réponses. Il s'assure que son équipe comprend quoi elle fait, pour qui, et pourquoi. Cet article partage l'expérience de l'équipe hi.ducalis.io dans l'adoption de la compréhension partagée—un processus long et complexe avec des résultats remarquables.

Comment être un bon product manager

Selon les discussions sur Quora, il existe deux principales listes de compétences :

• Compétences spécifiques : analytics, UX/UI, entretiens, recherche, tests A/B
• Compétences générales : empathie, pensée stratégique, proactivité, adaptabilité, capacité à prévoir les conséquences imprévues

L'ensemble des compétences d'un bon PM n'est pas difficile à déterminer et à apprendre.

Mais le product management ne se résume pas aux compétences. Il s'agit de prendre des décisions.

Deux approches de prise de décision

Après une centaine d'heures d'entretiens utilisateurs avec des PM, nous avons repéré deux approches :

1. Superhéros—un PM omniscient et tout-puissant qui répond à chaque question de l'équipe et prend toutes les décisions
2. Facilitateur—un PM qui aide l'équipe à comprendre les problèmes et à prendre des décisions

Le piège du consultant produit

Les histoires sur Steve Jobs inspirent les gens à devenir des superhéros.

L'héroïsme vous piège. Au lieu d'être un manager, vous devenez un consultant—une personne qui répond à toute question sur le produit.

Être un superhéros produit est une pente glissante

Sherif Mansour, Distinguished Product Manager chez Atlassian, partage une histoire d'expérience précieuse.

Une capture de « What is product management ? »

Au début de sa carrière, il croyait qu'un PM est un superhéros avec des réponses à toutes les questions. Finalement, cela a conduit à un problème : il devait répondre à chaque question sur le produit. Même des questions comme « placer le bouton ici », « le colorer en bleu », « faire les requêtes API de cette manière », et ainsi de suite. Il s'est retrouvé surchargé de tâches quotidiennes.

Lors d'une réunion individuelle avec son manager, il a décrit des dizaines de subtilités sur ce que l'équipe faisait. Quels boutons ils mettaient et à quel point il se sentait dépassé. Mais ce qu'il a entendu, c'est qu'il devrait se concentrer sur des choses plus stratégiques.

C'est l'un des plus grands pièges du product management :

Vous vous rétrogradez de Product Manager à Consultant Produit en répondant constamment à de plus en plus de questions de vos coéquipiers. (idée d'Ivan Spasojevic du fil Quora)

Problèmes du consultant produit

1. Le nombre de questions augmente—la portée diminue
2. Le travail s'arrête sans vous
3. L'équipe fait plus de travail inutile

Vous devez tout vérifier et étudier. Sinon, ce sera mal implémenté. Probablement sans objectif clair.

Vous cherchez de l'aide dans la planification de la feuille de route, les documents d'exigences produit et la priorisation du Backlog.

Cependant, même si votre équipe lit tout cela, elle perçoit les tâches différemment.

Écrire ou lire des idées et des stratégies ne signifie pas nécessairement les comprendre.

Le product management est un sport d'équipe

Une capture de Mind the Product en 2019

Dans son discours à la conférence Mind The Product, Sherif Mansour souligne la principale idée fausse de toute sa carrière—les Product Managers prennent toutes les décisions.

Vous devez changer cette mentalité et donner à vos équipes le pouvoir de prendre des décisions.

Un PM possède la vélocité de la prise de décision. La mission est de l'augmenter en construisant une compréhension partagée de l'équipe. C'était sa leçon la plus précieuse.

Les trois W de la compréhension partagée

L'équipe doit clairement comprendre :

• Le qui—Ils ont suffisamment de contexte sur qui ils aident
• Le quoi—Ils comprennent quel problème ils résolvent
• Le pourquoi—Ils comprennent comment cela s'inscrit dans le tableau d'ensemble

L'un des signaux de la compréhension partagée est que votre équipe fonctionne bien sans que vous touchiez au Backlog. Ils n'ont pas besoin que vous sélectionniez les bonnes tâches pour vos clients et votre stratégie. Ils sont toujours pleinement conscients de ce qu'ils font, comment et pourquoi.

Vos designers, ingénieurs et analystes peuvent-ils décider des solutions par eux-mêmes ?

Signaux d'une excellente compréhension partagée

• Vous n'avez pas consulté votre Backlog depuis des mois, et votre équipe exécute bien
• Votre équipe vous remet en question sur des choses qu'ils font qui ne sont pas alignées avec votre étoile du nord
• Votre équipe fait référence aux clients par leur nom
• Votre équipe veut travailler sur les résultats plutôt que sur la production. Ils disent « Ceci nous aidera à augmenter la rétention » et non « Je dois terminer l'Epic pour recevoir un bonus »
• Les démos d'équipe sont formées autour de « nous construisons X pour résoudre le problème Y du client » sans aucune incitation
• Leurs projets parallèles sont tous alignés avec votre feuille de route

Réfléchissez : en tant que PM/CEO/propriétaire, êtes-vous prêt à ne pas vous immiscer dans les plans de l'équipe et à ne pas attribuer toutes les tâches vous-même ?

Ce qui fait un product manager distingué

Sherif souligne deux métiers principaux du product management :

• Construire la compréhension partagée—faire de la recherche client, des analyses de données, des collectes, des sondages, du prototypage rapide, et ainsi de suite. Il est important de faire ces activités ensemble en équipe. Cela vous aide à mieux comprendre le problème et l'intention du client et à construire une compréhension partagée ensemble
• Identifier les lacunes dans la compréhension partagée—demander à votre équipe si elle comprend clairement le quoi, le qui et le pourquoi. Parlez à votre équipe ou faites des sondages. Lorsque vous trouvez des lacunes, vous menez des activités pour les combler

Exemples de résultats du sondage « Les 3 W »

Expérience personnelle dans la construction de la compréhension partagée

Toute l'histoire de la façon dont notre équipe utilise hi.ducalis.io est une tentative de construire une compréhension partagée chez hi.ducalis.io.

1. Partager les émotions des clients avec toute l'équipe

Nous utilisons la méthode « The Mom Test » pour les entretiens clients. Nous essayons de ne pas vendre, de ne pas faire de démo ou de dire quoi que ce soit sur nos solutions. Nous écoutons seulement comment nos clients potentiels décrivent leur workflow, leurs problèmes et leurs points de douleur.

Nous demandons la permission d'enregistrer une vidéo pour le reste de notre équipe. Il est important de partager les moments les plus vifs de l'histoire de l'utilisateur avec leurs émotions et leurs mots. Cet exercice aide à avoir un aperçu des problèmes du client et ne prend pas beaucoup de temps à l'équipe.

2. Exprimer les objectifs produit dans les critères d'évaluation

Nous avions l'habitude d'avoir un document avec les buts et objectifs de l'entreprise. Mais il était difficile de se souvenir des indicateurs clés et des objectifs sans indice. Plus tard, nous les avons transformés en Critères d'évaluation de tâches dans Ducalis.

Nous avons trois ensembles de Critères :

• Critères communs que toute l'équipe doit comprendre : Activation, Rétention, Vitesse de service et Assistance à la collaboration
• Critères développeurs : Complexité de développement
• Critères managers : Potentiel de vente et Demande de fonctionnalités

Un ensemble de Critères pour le grooming du Backlog

3. Évaluer le Backlog ensemble le vendredi

Chaque membre de l'équipe doit estimer les tâches et les Idées du Backlog. Les développeurs et les product managers ont des Critères légèrement différents. Nous attribuons des scores subjectivement, donc c'est facile et rapide. L'important est de le faire régulièrement. Nous utilisons des Sprints hebdomadaires, donc nous faisons le grooming du Backlog chaque semaine.

Évaluation des tâches par Critères dans Ducalis

4. Planifier les Sprints le lundi

Après le grooming, nous obtenons toutes nos tâches classées par priorité. La liste de Priorité absolue est consultative. L'équipe remplit le Sprint de manière indépendante. Lors de la planification, nous expliquons le quoi, le qui et le pourquoi. Nous pouvons ajuster nos plans si le contexte a changé durant le week-end.

Tâches du Backlog triées par priorité

5. Trouver les lacunes dans la compréhension partagée

• Si nous ne comprenons pas comment évaluer un Critère, nous mettons un tiret. Ensuite, nous discutons du Critère ensemble et pouvons réécrire sa description. Si nous ne comprenons pas la tâche, nous laissons des commentaires dans Jira. Cela aide le rapporteur à trouver la confusion dans l'Idée ou le manque d'alignement avec la vision
• Les scores sont supprimés 30 jours après l'évaluation de la tâche. Si elle n'a pas été complétée, nous estimons et repensons à nouveau. Assez souvent, nous décidons de supprimer la tâche. La réévaluation est critique. Cela nous aide à comprendre la pertinence du Backlog car nous recevons régulièrement un nouveau contexte client

Tout cela nous donne une image de l'Alignement de l'équipe. Nous voyons où l'équipe a des désaccords ou manque de compréhension partagée.

Les résultats de la construction de la compréhension partagée dans l'équipe hi.ducalis.io

Le système a commencé à porter ses fruits en quelques mois. Voici les retours de l'équipe :

• La plupart du temps, c'est génial. Les managers et les développeurs ont maintenant une meilleure compréhension du produit. Nous essayons de regarder sous différents angles. Nos discussions sont devenues plus raisonnées.
• La compréhension partagée semble être de haut niveau.
• Il nous manque les indicateurs de notre direction. Par exemple, le nombre de clients devrait être X, le revenu K, et ainsi de suite. Cela aiderait lors de l'étude des priorités. La tâche contribue-t-elle aux valeurs ? (Celui-ci nous l'avons corrigé)
• Beaucoup de choses dépendent encore de Vit (CEO). Il ne délègue pas ou ne confie pas beaucoup l'implémentation des tâches.

Comme vous le voyez, nous ne pouvons pas dire que tout est splendide. Mais cela s'améliore chaque semaine. Construire une compréhension partagée nécessite beaucoup d'efforts. Mais cela en vaut la peine. Nous pensons encore parfois « C'est plus rapide de l'implémenter que de l'expliquer ». Mais ce n'est que mettre les problèmes de côté pour l'avenir.

Essayez nos méthodes sur hi.ducalis.io

Inscrivez-vous et essayez d'évaluer les tâches. Le produit lui-même vous guidera à travers la méthodologie.

Liste de lecture

• Product managers make all the decisions… right? Par Sherif Mansour

• The Fastest Issue Prioritization—Ducalis Story

P.S. Le syndrome Steve Jobs—être un génie solitaire qui prévoit l'avenir. Une personne qui ne s'intéresse pas aux opinions des clients ou des collègues. Celui qui sait quoi faire ensuite. Mais nous nous souvenons encore que Steve disait : « Embauchez des personnes intelligentes et laissez-les vous dire quoi faire. »