Gestion des parties prenantes : l'art de dire non

Un bon développement de produit nécessite d'identifier et de se concentrer sur le chevauchement magique entre l'opportunité, la faisabilité et la viabilité, où vit l'innovation. Les chefs de produit sont constamment dans la position de devoir défendre l'équilibre entre ces domaines, contrecarrant les forces qui s'affrontent pour tirer un produit trop loin dans une direction au détriment des autres. Cela signifie dire non, plusieurs fois et à de nombreuses personnes, tout au long du parcours de développement du produit.

Plus tôt dans ma carrière, j'ai travaillé sur un projet dans l'espace automobile, développant une application qui utilisait l'apprentissage automatique informé par les données environnementales et le comportement des utilisateurs pour fournir des suggestions intelligentes aux conducteurs. Au moment où j'ai rejoint l'équipe, l'application était sur le point d'être lancée et la direction était impatiente de la publier, mais j'ai vite réalisé qu'elle était loin d'être prête pour la production.

Alors que l'application était visuellement attrayante, certaines des questions de conception les plus fondamentales avaient été ignorées, telles que "Quel problème résolvons-nous et pour qui?" » et « À quel point les gens sont-ils désespérés de résoudre ce problème ?

L'application se vantait d'une fonctionnalité qui afficherait la météo à la destination du conducteur. À partir des habitudes des utilisateurs et des données de trafic, l'algorithme pourrait déduire où un conducteur pourrait se diriger et combien de temps il lui faudrait pour s'y rendre, et une simple intégration de l'API météo a montré les prévisions météorologiques pour la destination au moment de l'arrivée. Cela semblait être un bon cas d'utilisation, mais en réalité, personne ne s'en souciait. Lorsque j'ai mené ma propre recherche auprès des utilisateurs, y compris une enquête rémunérée auprès des conducteurs européens, la réponse a été un "Meh" retentissant. C'est sans doute le pire retour que vous puissiez obtenir : cela signifie que votre produit a résolu un problème non pertinent et indique que la dimension de désirabilité est extrêmement faible. La viabilité est alors une cause perdue : il est impossible de bâtir une entreprise viable avec un produit dont personne ne veut. Nous avons dû tout casser.

Comment cela a-t-il pu arriver? La réponse est compliquée, mais elle se résume au fait qu'un mot critique n'a pas été prononcé alors qu'il aurait dû l'être : Non.

La compétence et les actifs de base de l'entreprise étaient les moteurs d'inférence d'apprentissage automatique et la conception d'architecture hautement évolutive. Le responsable de la science des données était un acteur puissant qui souhaitait voir ses moteurs d'inférence mis à profit dans une application client. Son influence, en partie, avait abouti à un produit complètement centré sur la technologie. Le développement avait été motivé par ce qui était faisable sur le plan technologique plutôt que par ce que les clients souhaitaient.

Il semblait que personne n'avait dit non à cette partie prenante, et s'ils avaient essayé, cela n'avait pas été efficace.

La stratégie produit signifie dire non

Dire non est difficile. Les gens n'aiment pas toujours entendre le mot, et ils craignent souvent que le dire nuise à des relations importantes. En tant que chefs de produit, les relations sont au cœur de notre rôle, mais il en va de même pour la garantie que nos produits réussissent et restent équilibrés.

Alors, comment rejeter la demande de quelqu'un tout en gardant la relation intacte ? Je recommande ces pratiques :

• Préparez-vous pour le succès.
• Ne dites pas non trop vite.
• Reformulez la demande.
• Favoriser un climat de contribution.

Préparez-vous pour le succès

Au début d'un projet, il est essentiel que tout le monde s'accorde sur une vision commune du succès du produit (« Pourquoi faisons-nous cela ? ») et sur un ensemble d'indicateurs qui serviront à mesurer les progrès (« Comment saurons-nous si nous le faisons bien ? »). Si vous n'êtes pas d'accord sur ce à quoi ressemble le succès, ce n'est qu'une question de temps avant que des conflits ne surviennent.

Il est utile d'utiliser un cadre pour documenter les objectifs et les associer à quelque chose de mesurable. J'aime utiliser une version lâche du framework HEART de Google, qui organise l'expérience utilisateur en catégories pour le bonheur, l'engagement, l'adoption, la rétention et la réussite des tâches, puis articule les objectifs, les signaux et les mesures pour chacune de ces catégories. Les objectifs correspondent à ce que vous essayez d'atteindre, les signaux décomposent chaque objectif en actions de l'utilisateur et les métriques suivent ces actions pour évaluer vos performances d'une manière quantifiable.

Dans le cadre d'un récent projet d'application grand public, je voulais mener un projet pilote limité pour déterminer si les utilisateurs trouvaient notre prototype utile et souhaitaient continuer à interagir avec lui ; Je me suis concentré principalement sur la catégorie Engagement du cadre HEART. J'ai ensuite dû identifier des signaux et des métriques pour suivre les progrès vers cet objectif :

• Objectif : les utilisateurs souhaitent interagir avec l'application et continuer à l'utiliser.
• Signal : les utilisateurs ouvrent fréquemment l'application.
• Mesure : pourcentage d'utilisateurs qui ouvrent l'application au moins deux fois par jour.

Ce processus d'identification et d'alignement sur les objectifs peut sembler simple, mais ce n'est pas facile. Dans ce cas, cela impliquait des appels avec le client et notre équipe de vente, des recherches indépendantes et plusieurs ateliers d'équipe. Sur la base des informations que j'ai recueillies à partir de cette découverte, j'ai pu présenter le framework HEART terminé lors de la réunion de lancement avec le client. Nous avons parcouru tous les éléments et adapté si nécessaire.

Il est essentiel de s'assurer que toutes les parties prenantes sont impliquées dans le processus de définition des objectifs, et de faire en sorte que tout le monde s'entende sur les signaux et les mesures à suivre élimine le besoin de dire non à plusieurs reprises au fur et à mesure de l'avancement du projet. Il vous donne également des données à pointer si quelqu'un vous approche avec une demande qui ne rentre pas dans les paramètres du plan.

Ne dites pas non trop vite

Même lorsque les principales parties prenantes s'accordent sur ce à quoi ressemble le succès et que la voie à suivre semble claire, une chose est certaine : quelqu'un, quelque part, vous approchera avec une demande imprévue.

Lorsque cela se produit, ne dites pas non trop rapidement. Même si vous êtes certain que la demande est déraisonnable, la rejeter purement et simplement met fin à la conversation et pourrait nuire à la relation. Cela sape également le processus de découverte du produit. En tant que chefs de produit, nous devons avoir une vue d'ensemble, et écouter les personnes qui ne sont pas d'accord avec nous réduit nos angles morts.

Vous pouvez toujours dire non, bien sûr, mais vous devez éviter les réponses instinctives. Celles-ci conduisent à des discussions binaires qui sont le résultat d'une réflexion en noir et blanc, juste ou faux, gagnant ou perdant : soit vous implémentez quelque chose, soit vous ne le faites pas.

Pour évoluer vers des discussions plus efficaces et nuancées, vous devez organiser les demandes en fonction des critères convenus que vous avez établis dans le cadre de votre processus de définition des objectifs.

Au lieu de demander à une partie prenante « Cette fonctionnalité est-elle utile pour vous ? » demander "Quelle est la valeur de cette fonctionnalité pour vous ?" La conversation qui en résulte devrait vous donner les informations dont vous avez besoin pour collaborer sur une liste de « désirs », classés par ordre d'importance. Il est essentiel que ce classement aille de 1 à n, sans permettre à plusieurs éléments de partager la même place dans la hiérarchie. Cela donne à chacun une voix dans le processus de priorisation et vous dispense d'avoir à rejeter les demandes unilatéralement. Certaines demandes tomberont à l'eau lorsque le groupe les rétrogradera au profit de plus importantes.

Recadrer la demande

Une demande qui semble déraisonnable au départ peut donner des résultats positifs avec une réingénierie subtile. Tout d'abord, écoutez ce qui se dit. Écoutez vraiment. Mettez vos hypothèses de côté et essayez de comprendre d'où vient l'autre personne, puis trouvez un terrain d'entente. Si vous creusez un peu plus en demandant « Pourquoi » — pas nécessairement les cinq fois dont vous avez entendu parler ; deux à trois suffiront généralement - vous pourriez découvrir un facteur qui parle d'un objectif commun.

Même une demande parfaitement sensée peut bénéficier d'une plongée plus profonde et d'un peu de recadrage. Je me souviens d'une situation dans laquelle je travaillais sur un outil de business intelligence pour un service de mobilité B2B. Mon client m'a demandé, sans surprise, d'augmenter le nombre d'abonnés. Bien que la motivation pour augmenter le nombre d'abonnés payants puisse sembler évidente, je voulais m'assurer d'avoir une image complète, alors j'ai demandé : « Pourquoi ?

Il s'est avéré que le produit en question approchait de la fin de son cycle de vie, et mon client voulait tirer les dernières gouttes de profit avant de le remplacer par un nouveau produit. Avec ces informations, j'ai recadré la demande en "Comment pourrions-nous augmenter considérablement les revenus à court terme tout en jetant les bases du prochain lancement de produit ?"

En fin de compte, la meilleure solution était de ne pas se soucier du tout du nombre d'abonnés, mais de mieux aligner les prix sur la valeur. Les clients payaient un abonnement mensuel fixe, quelle que soit la fréquence à laquelle ils utilisaient l'outil pour les transactions des passagers. Cependant, plus ils traitaient de transactions de passagers, plus ils tiraient de valeur de l'outil. Les clients allaient des chauffeurs de taxi individuels n'effectuant qu'une poignée de transactions mensuelles aux transporteurs de fret multinationaux - avec des dizaines de filiales et des milliers de véhicules - effectuant des centaines de milliers de transactions mensuelles. Le même abonnement mensuel fixe était trop élevé pour les petits clients et trop bas pour les gros.

En procédant à de petits ajustements de prix, nous avons augmenté nos revenus tout en progressant vers une structure de prix à plusieurs niveaux (basée sur le nombre de transactions) pour le produit qui sera bientôt lancé. Le nouveau modèle a réduit le prix pour la plupart des clients tout en l'augmentant pour les plus gros clients, qui en avaient bénéficié de manière disproportionnée.

En recadrant les demandes de cette manière, vous pouvez créer des situations gagnant-gagnant. La personne qui présente la demande se sent entendue et respectée, et vous obtenez des informations qui peuvent ajouter de la valeur sans faire dérailler le processus de développement du produit.

Encourager un climat de contribution

L'un des plus grands risques de dire non est que les rejets peuvent saper l'esprit d'ouverture et de collaboration que vous essayez de favoriser, tant à l'intérieur qu'à l'extérieur de votre équipe. Les idées inspirent, qu'elles deviennent pertinentes ou non, et la dernière chose que vous voulez faire est d'endiguer le flux de créativité et de communication.

J'ai déjà travaillé avec un ingénieur QA junior qui avait une mine d'idées. À presque toutes les réunions, il posait de multiples questions et proposait des suggestions. Ses solutions n'étaient souvent pas exploitables, et certaines d'entre elles auraient pu être rejetées comme inutiles ou non pertinentes. Mais son engagement et son enthousiasme ont été inestimables. Il s'est totalement investi dans la livraison du meilleur produit possible, et ses contributions ont dynamisé et inspiré les autres. Une telle attitude est contagieuse.

Vous voulez créer un environnement dans lequel les gens se sentent encouragés à partager leurs pensées et leurs idées, et sont récompensés pour cela. Votre équipe doit être motivée par la possibilité d'améliorer les choses au lieu d'être découragée par l'idée d'être rejetée, ignorée ou ridiculisée. La mise en place de quelques pratiques simples peut aider à assurer la sécurité psychologique de votre équipe.

Reconnaissez les idées et les demandes publiquement. Cela renforce la confiance et montre que vous appréciez les suggestions et que vous vous engagez à les prendre en compte. Configurez une boîte de demande, une page Confluence ou un autre forum public auquel toutes les parties prenantes peuvent accéder. Lorsqu'une demande arrive, enregistrez-la et envoyez un message au demandeur pour le remercier de sa contribution.

Je sais que cela peut s'avérer controversé, mais je vais parfois jusqu'à ouvrir le carnet de produit à tout le monde. Cela peut être particulièrement utile pour favoriser l'engagement de l'équipe produit, ainsi que pour permettre aux membres de l'équipe comme les testeurs QA et les concepteurs de noter les choses qu'ils ont rencontrées. Les règles sont simples : n'importe qui peut ajouter à la fin du backlog, et lors des raffinements (ou d'autres réunions hebdomadaires), les membres de l'équipe partagent ce qu'ils ont ajouté et expliquent pourquoi. Seul le chef de produit peut modifier l'ordre des problèmes ou supprimer des éléments. Beaucoup de gens supposent qu'accorder à tout le monde ce niveau d'accès conduira au chaos et à l'anarchie, mais ce n'est pas le cas. J'ai essayé cela dans des organisations de différentes tailles et cela n'échoue que lorsque les gens sont trop timides pour apporter leurs idées.

Une fois que vous avez implémenté une solution ou publié une fonctionnalité, même grossièrement liée à l'une de ces demandes consignées, créditez publiquement le demandeur. Ceci est particulièrement important lorsque la solution n'est pas une réponse claire à la demande d'origine, mais plutôt une version recadrée. Montrer de l'appréciation pour toutes les personnes impliquées dans un succès crée de la bonne volonté, renforce la camaraderie et encourage les gens à continuer à participer.

Peser le pour et le contre de dire non

Si vous prenez le temps de vraiment écouter et de comprendre d'où viennent les parties prenantes, vous aurez rarement besoin de rejeter purement et simplement les propositions. L'écoute active, la communication transparente et le respect mutuel sont des ingrédients clés dans le traitement des demandes qui peuvent initialement sembler problématiques ou hors de portée. La plupart du temps, l'art de dire non n'implique jamais de dire "non".

Il y aura des situations dans lesquelles il s'avérera impossible de trouver un terrain d'entente, et un non direct sera nécessaire afin de protéger le produit et le projet. Dans d'autres cas, vous pourriez être obligé de donner suite à des choses avec lesquelles vous n'êtes pas d'accord. Même si votre travail consiste à protéger l'équilibre entre désirabilité, faisabilité et viabilité, il y a une quatrième dimension à prendre en compte : le pragmatisme. Pour faire avancer les choses, le compromis est essentiel, et parfois cela signifie éviter complètement un non.

La beauté du développement de produits Agile réside dans le fait que sa nature itérative offre de nombreuses opportunités de correction de cap. Après tout, l'objectif est de construire-mesurer-apprendre, et non de débattre-dispute-dérailler.