Coaching – Collaboration

Dans cet article, je continue la série sur le coaching des chefs de produit en parlant d’une autre compétence d’une importance cruciale qui est si souvent mal comprise ou sous-estimée, et qui est collaboration.

La collaboration est l’un de ces mots qui est utilisé si souvent de tant de façons différentes qu’il a perdu son sens pour de nombreuses personnes. Bien sûr ils pensent qu’ils collaborent. Peu se considèrent comme anti-collaboratifs.

Mais dans le contexte d’une équipe de produits autonome et interfonctionnelle, être collaboratif a une signification très spécifique, et c’est certainement ne pas combien de personnes, en particulier les chefs de produit, sont enclins à travailler. C’est donc souvent un domaine d’une importance cruciale pour le manager de se concentrer pendant le coaching.

Dans l’article Beyond Lean and Agile, je parle des trois caractéristiques essentielles des équipes de produits solides, quels que soient les processus qu’ils utilisent, et la seconde est que les équipes de produits solides résolvent les problèmes en collaboration.

En particulier, ce n’est plus l’ancien processus en cascade d’un chef de produit qui définit les exigences et les confie à un concepteur pour proposer une conception qui répond à ces exigences, puis les confie aux ingénieurs pour mettre en œuvre la conception.

Qu’entendons-nous vraiment par collaboration?

Commençons par parler de la collaboration ne pas.

Tout d’abord, la collaboration ne concerne pas consensus. J’ai écrit plus tôt combien il est important de ne pas confondre collaboration et consensus. Bien que cela nous plaise lorsque l’équipe produit est d’accord sur la meilleure ligne de conduite, nous n’insistons pas là-dessus. Nous dépendons plutôt de l’expertise de chaque membre de l’équipe produit. De manière générale, si le responsable technique estime qu’une architecture spécifique est requise, nous nous en remettons au responsable technique. Si le concepteur estime qu’une expérience utilisateur spécifique est requise, nous nous en remettons au concepteur. Parfois, il y aura des conflits et des appels de jugement, et normalement nous exécuterons un test pour résoudre.

Deuxièmement, la collaboration ne concerne pas artefacts. De nombreux chefs de produit pensent que leur travail consiste à produire une sorte de document capturant les «exigences», ou au moins, ils sont là pour écrire des user stories. Il est vrai que parfois nous devons créer des artefacts (surtout lorsque les membres de l’équipe sont éloignés), mais ce n’est certainement pas ainsi que nous collaborons. En fait, ces artefacts entravent le plus souvent une collaboration réelle.

Pourquoi donc? Parce qu’une fois que le chef de produit a affirmé que quelque chose est une «exigence», cela met pratiquement fin à la conversation et fait passer la discussion à la mise en œuvre. À ce stade, la créatrice a l’impression d’être là pour s’assurer que la conception est conforme au guide de style de l’entreprise, et les ingénieurs ont l’impression qu’ils ne sont là que pour coder, et nous sommes de retour à la cascade.

Troisièmement, la collaboration ne concerne pas non plus faire des compromis. Si vous vous retrouvez avec une expérience utilisateur médiocre et des performances lentes et une évolutivité limitée et une valeur douteuse pour les clients, en tant qu’équipe, vous perdez.

Nous devons trouver une solution qui travaux. Nous entendons par là qu’il est précieux (suffisamment précieux pour que les clients cibles l’achètent ou choisissent de l’utiliser); il est utilisable (afin que les utilisateurs puissent réellement ressentir cette valeur), il est faisable (afin que nous puissions réellement fournir cette valeur) et il est viable pour notre entreprise (afin que le reste de notre entreprise puisse commercialiser, vendre et soutenir efficacement la solution) .

Comme nous en avons longuement discuté ailleurs, pour ce faire, nous devons savoir ce que nous ne pouvons pas savoir, admettre ce que nous ne savons pas et nous concentrer sur la découverte d’une solution qui fonctionne.

Et cela nécessite une véritable collaboration.

N’oubliez pas que notre travail dans le produit consiste à résoudre les problèmes que nous sommes appelés à résoudre, d’une manière que nos clients aiment, mais qui fonctionnent pour notre entreprise. C’est notre travail en tant qu’équipe produit interfonctionnelle, et chaque membre de l’équipe est là parce qu’il apporte les compétences nécessaires.

Tout commence par une collaboration véritable et intense avec vos coéquipiers de conception et d’ingénierie.

Ma façon préférée de le faire est de s’asseoir autour d’un prototype (généralement créé par le concepteur) afin qu’en équipe, vous puissiez considérer et discuter de la solution proposée sur la table, et le concepteur peut envisager différentes approches de l’expérience, et les ingénieurs peut considérer les implications de différentes approches et le potentiel de différentes technologies habilitantes, et le chef de produit peut considérer les impacts et les conséquences de chaque direction potentielle (par exemple, y aurait-il des violations de la vie privée, ou est-ce que cela fonctionnerait avec notre canal de vente?) .

Notez que lors de la découverte de produits, certains outils et techniques servent à la fois à faciliter la collaboration et à fournir un artefact en tant que sortie de cette collaboration. Les prototypes et les Story Maps en sont deux exemples très populaires. L’acte même de créer et de discuter des prototypes et des cartes d’histoires facilite une véritable collaboration. Et si vous tenez à garder votre prototype ou votre carte d’histoire à jour, ils peuvent également servir d’artefact capturant l’apprentissage et les décisions du travail de découverte. Le véritable avantage et le but des outils dans ce cas est de favoriser la collaboration, cependant, c’est un avantage secondaire agréable de pouvoir avoir un artefact à la fin.

Notez que le chef de produit et les ingénieurs n’essaient pas de dire au designer comment faire son travail. Et le chef de produit et les concepteurs ne sont pas là pour dire aux ingénieurs comment faire leur travail. Et les concepteurs et ingénieurs ne sont pas là pour dire au chef de produit comment faire son travail.

Au contraire, dans une équipe saine et compétente, chaque membre de l’équipe compte sur les autres pour avoir fait ses devoirs et apporter les compétences nécessaires à la table.

Mais ne vous méprenez pas, car les concepteurs ne sont responsables que de la convivialité et les ingénieurs ne sont responsables que de la faisabilité, car cela manquerait le véritable point de collaboration.

Les concepteurs ont souvent des idées basées sur une compréhension approfondie de nos utilisateurs et de leurs comportements qui nous conduisent dans une direction différente en termes de problème que nous résolvons ou de notre approche du problème. Ces informations auront souvent un impact important sur la valeur et des impacts indirects sur des choses comme les performances.

De même, des ingénieurs solides ont une connaissance approfondie de la technologie habilitante qui nous conduit souvent à des solutions entièrement différentes aux problèmes qui nous ont été attribués, souvent bien mieux que tout ce que le chef de produit, le concepteur ou en particulier le client aurait pu imaginer.

Si je devais choisir la seule chose que j’aime le plus dans le sentiment de véritable collaboration au sein d’une équipe de produits compétente, c’est la forme de magie qui se produit lorsque vous avez des personnes qui sont a) motivées et b) compétentes dans leur discipline respective – produit, conception et ingénierie – et ils s’assoient autour d’un prototype ou regardent un utilisateur interagir avec notre prototype, et l’ingénieur souligne de nouvelles possibilités, et le concepteur souligne différentes expériences potentielles, et le chef de produit pèse sur les ventes ou les finances ou implications liées à la vie privée, et après avoir exploré un tas d’approches, ils en trouvent une qui fonctionne réellement – elle est précieuse, elle est utilisable, c’est faisable et c’est viable.

D’après mon expérience, il y a deux situations où cela se passe le plus souvent.

La première est que la chef de produit n’a pas fait ses devoirs et qu’elle ne connaît pas les différents aspects et contraintes de l’entreprise – vente, marketing, finance, juridique, vie privée, etc. – donc l’équipe produit n’a vraiment pas les informations dont il a besoin pour résoudre les problèmes qui lui ont été attribués (ce qui signifie généralement qu’ils sont de retour à la mise en œuvre des fonctionnalités sur une feuille de route). C’est pourquoi nous avons discuté au début de cette série sur le coaching qu’en tant que manager, votre première priorité est d’évaluer le chef de produit et de créer un plan pour l’amener à la compétence.

Le second est l’arrogance. Si la chef de produit estime que la solution qu’elle a déjà en tête est clairement la meilleure, même si elle a raison, la collaboration est étouffée et elle a probablement maintenant une équipe de mercenaires plutôt que de missionnaires.

S’il est vrai que la majorité de la collaboration réelle d’un chef de produit se produit avec son concepteur et ses ingénieurs, il existe plusieurs autres exemples où nous avons également besoin d’une véritable collaboration.

Une relation saine avec les parties prenantes est basée sur une véritable collaboration. Le chef de produit n’est pas là pour «recueillir les exigences» des parties prenantes, mais le chef de produit n’est pas non plus là pour dicter des solutions aux parties prenantes. Au contraire, le chef de produit solide comprend que chaque partie prenante est responsable d’un aspect clé de l’entreprise, et ils sont un partenaire clé pour aider à trouver une solution qui fonctionne.

Un exemple courant et clair de cela est que souvent ce que nous essayons de faire a des implications juridiques, peut-être en ce qui concerne la confidentialité ou peut-être la conformité réglementaire. L’intervenant juridique est votre partenaire pour comprendre ces contraintes et aider à évaluer la pertinence de différentes approches.

Encore une fois, une relation constructive et collaborative avec les parties prenantes repose sur le fait que le chef de produit a fait ses devoirs afin qu’elle puisse être ce partenaire efficace avec la partie prenante et pas seulement une forme de facilitateur ou de chef de projet.

Tout ce que j’ai dit ci-dessus est doublement important lorsque nous parlons de collaborer avec des dirigeants d’entreprise. En général, plus les dirigeants de l’organisation sont nombreux, plus les dirigeants se soucient de tout – clients, marque, chiffre d’affaires, conformité – et plus il est important que le chef de produit ait fait ses devoirs.

Collaborer avec les parties prenantes et les dirigeants implique une écoute attentive pour essayer de comprendre les contraintes et une réflexion approfondie sur les solutions qui fonctionneraient pour nos clients et notre entreprise.

Une autre forme de collaboration importante, en particulier dans les entreprises disposant d’une force de vente directe, consiste à dialoguer avec des clients potentiels pour déterminer si votre produit peut répondre à leurs besoins. Il est naturel que le prospect essaie de dicter les exigences des fonctionnalités, mais votre travail consiste à comprendre leurs problèmes et contraintes sous-jacents, puis à travailler en collaboration avec vos clients potentiels pour déterminer s’il existe une solution générale qui répondra à leurs besoins. Cette forme de collaboration est au cœur de la technique du programme de découverte client.

La collaboration signifie travailler ensemble avec nos concepteurs et ingénieurs, parties prenantes et cadres pour trouver une solution qui résout tout de nos contraintes – c’est ce que nous entendons par des solutions que nos clients aiment, tout en travaillant pour notre entreprise.

Obtenir une bonne collaboration est au cœur du fonctionnement des chefs de produit solides. C’est une combinaison de compétences et de mentalité, et il faut souvent un coaching actif de la part du gestionnaire pour aider le nouveau chef de produit à développer cette capacité.