10 raisons pour un développement de produit réussi
Il y a exactement un an, j'ai été invité à la Craft Conference à Budapest où j'ai parlé des 10 principales raisons de l'échec des équipes produit. J'ai principalement évoqué pourquoi tant d'équipes sont si peu efficaces et, malgré toutes les affirmations contraires, la plupart des organisations ne sont toujours pas vraiment « agiles », car elles fonctionnent encore selon le principe de la cascade. Cette année, j'ai donc été à nouveau invité à la conférence pour parler de la façon dont travaillent les meilleures équipes que je connaisse. Cet article est un résumé de mon intervention.
Après ma première présentation, plusieurs personnes m'ont contacté pour me demander plus d'informations. Mis à part leur conseiller de lire mon livre ou de participer à un workshop , je n'avais pas l'impression de pouvoir leur donner une réponse satisfaisante. Cela m'a inspiré à réfléchir plus précisément aux principales caractéristiques des équipes produit exceptionnelles . J'ai donc élaboré mon top 10 personnel.
Découverte et livraison continues
Tout comme j'ai décrit les dix plus grands problèmes du modèle en cascade, j'ai également décrit les dix caractéristiques des équipes performantes en matière de Continuous Discovery et Delivery (également appelé Dual Track Agile, Discovery Sprints ou Delivery Sprints). Quels sont donc les facteurs de succès pour un développement produit réussi ?
1. Équipes produit habilitées
Le facteur le plus important est le concept absolument fondamental des équipes produit solides. Mais qu'est-ce que cela signifie concrètement ?
Tout d'abord, il est essentiel que l'équipe existe sur le long terme dans cette configuration et que les membres ne soient pas déplacés comme des pions sur un échiquier. Si les équipes doivent innover, elles ont besoin de temps pour mieux se connaître, comprendre la technologie, les clients et le contexte métier.
Deuxièmement, la chimie entre les membres de l'équipe est également déterminante. Cela signifie qu'ils doivent suffisamment bien se connaître et se respecter pour que chaque membre se sente assez à l'aise pour oser proposer des idées et motiver continuellement les autres à donner le meilleur d'eux-mêmes.
Troisièmement, une équipe devrait disposer d'une certaine diversité de compétences, généralement composée de la gestion de produit, du design d'expérience utilisateur et du développement. L'analyse de données et la recherche utilisateur en font souvent partie également.
Enfin, il est avantageux que tous les membres de l'équipe travaillent ensemble au même endroit – même si ce n'est pas un sujet simple pour beaucoup d'entreprises. Le product manager, le product designer et les développeurs (ou au moins le responsable de l'équipe de développement) devraient avoir leurs bureaux côte à côte. Malheureusement, ce n'est pas toujours réalisable, mais on peut au moins essayer. Et pour être clair, ce ne sont pas les équipes individuelles situées à différents endroits qui posent problème. C'est lorsque les membres d'une même équipe sont géographiquement séparés que cela a un impact négatif sur la vélocité et surtout sur l'innovation.
2. Vision et stratégie produit
Pour avoir des équipes produit véritablement autonomes et responsabilisées, les membres de l'équipe doivent bien comprendre le contexte business. Cela commence par une vision produit claire et convaincante, ainsi que par le chemin pour y parvenir : la stratégie produit.
La vision produit décrit le monde que nous souhaitons créer dans les deux à cinq prochaines années (généralement un peu plus longtemps pour le matériel).
La vision produit doit être inspirante. Une bonne vision produit est l'un de nos outils de recrutement les plus efficaces et motive les gens à venir travailler chaque jour. Une vision inspirante attire les talents, car ils veulent participer à quelque chose de significatif.
La stratégie produit est la séquence de produits que nous voulons livrer sur le chemin vers la réalisation de la vision. Ce serait une mauvaise stratégie de vouloir satisfaire toutes les parties prenantes avec une seule release. À la place, nous avons une liste priorisée de marchés, de zones géographiques ou de personas, et nous nous concentrons sur l'adéquation entre le produit et le marché concerné.
Plus on a d'équipes produit, plus il est important d'avoir une vision et une stratégie unifiées, afin que chaque équipe puisse prendre les bonnes décisions.
Le plus important, c'est que la vision produit soit inspirante et que la stratégie produit soit définie de manière délibérée.
3. Résultat métier
La deuxième partie du contexte métier dont une équipe autonome et habilitée a besoin pour prendre de bonnes décisions est un ensemble d'objectifs métier priorisés. Le système OKR (Objectives and Key Results) est conçu exactement pour cela.
Les OKR reflètent une liste de problèmes métier spécifiques que l'équipe doit résoudre. Cependant, ce ne sont pas des fonctionnalités. Les fonctionnalités ne sont que des solutions potentielles à des problèmes. Livrer une fonctionnalité ne rend pas une équipe performante ; c'est la résolution du problème réel qui compte.
Les deux principes derrière ces méthodes de gestion de la performance sont :
1) Les équipes sont plus performantes quand on leur donne des problèmes à résoudre par elles-mêmes, plutôt que de leur imposer des solutions.
2) L'équipe est évaluée sur les résultats, pas sur la production. Livrer des fonctionnalités sur une roadmap, c'est de la production ; résoudre un problème métier, c'est un résultat.
4. Un compétent chef de produit
Malheureusement, la plupart des développeurs n'ont jamais eu l'occasion de travailler avec un product manager compétent. Ceux qui ont eu cette chance sont aussi ceux qui insistent pour toujours avoir une telle personne dans leur équipe. Et pire encore, beaucoup de développeurs ne savent même pas exactement ce que le product manager est censé apporter à l'équipe.
Imagine les choses de la façon suivante : pour qu'une équipe produit puisse résoudre de vrais problèmes business, il ne suffit pas qu'une solution fonctionne techniquement ou que le client l'adore. La solution doit aussi fonctionner pour ton entreprise – et c'est souvent le plus difficile.
Réfléchis à ce que cela signifie. Imagine que tu travailles pour Uber ou AirBnB et que tu dois te confronter aux lois complexes, aux groupements d'employeurs et aux syndicats. Ou prends eBay, qui a dû faire face à des restrictions considérables pour être classé comme place de marché plutôt que comme site e-commerce. Ou Tesla, qui a dû clarifier des questions de responsabilité concernant l'Autopilot. Chaque entreprise a sa propre liste d'obstacles à surmonter :
Obstacles juridiques, financiers, liés aux ventes et aux prix, à la marque et au marketing, à la protection des données, à la sécurité, aux conditions de partenariat, etc.
Malheureusement, la seule personne qui comprend tout cela est le dirigeant, et dans ce cas, on peut comprendre pourquoi il a tant de mal à donner à l'équipe le pouvoir de prendre elle-même les bonnes décisions.
Il y a trois façons dont une équipe peut fonctionner. La première, c'est que le dirigeant ou un autre responsable décide de tout. La deuxième, c'est qu'un product manager organise une grande réunion et discute de tout avec l'ensemble de la direction (« Design By Committee »), ce qui produit généralement de mauvais résultats. La troisième possibilité, c'est que le product manager fasse son travail, se confronte aux obstacles et les transmette aux membres de l'équipe pour qu'ils puissent élaborer eux-mêmes la solution au problème.
Combine cela avec une bonne compréhension de la technologie et une connaissance approfondie des utilisateurs et des clients, et tu peux espérons-le comprendre pourquoi c'est un travail difficile mais absolument essentiel pour une équipe produit, surtout si l'équipe doit bénéficier d'un niveau d'autonomie significatif.
5. Solutions par la collaboration
« Collaboration » ne doit pas être un simple mot à la mode ici. Je veux simplement dire que les trois domaines – produit, design et développement – devraient travailler ensemble pour résoudre un problème, plutôt que le product manager transmette des « exigences », le designer emballe joliment le tout et les développeurs écrivent le code qu'on leur demande. La raison en est que, dans les bonnes solutions, technologie et fonctionnalité se nourrissent mutuellement. La technologie rend certaines options de design possibles, tout comme le design influence le choix de la technologie. Et les décisions de design influencent la fonctionnalité – et inversement.
Technologie, design de l'expérience utilisateur et fonctionnalité sont étroitement liés. Les bonnes solutions naissent d'un va-et-vient constant, d'un échange permanent entre ces trois domaines.
C'est aussi la raison principale pour laquelle les équipes qui travaillent au même endroit sont fondamentalement toujours plus performantes que celles qui ne le font pas.
6. Product Discovery : Apprentissage rapide
Les excellents produits dépendent beaucoup de la capacité d'une équipe à tester rapidement de nombreuses idées. Nous voulons séparer le plus vite possible les bonnes idées des mauvaises. La Product Discovery comprend toute une série de techniques qui nous aident à découvrir rapidement quelles idées sont géniales et lesquelles le sont moins. Certaines idées sont vraiment excellentes, d'autres moins. Certaines sont risquées, d'autres coûteuses. Parfois nous avons besoin de preuves, d'autres fois de simples indices.
Les gens décrivent cela de manières très différentes. Certains s'en tiennent à l'expression « fake it before you make it », ce qui signifie « faire semblant jusqu'à ce que ça marche ». D'autres soulignent qu'il faut construire des choses qui ne sont pas scalables. L'essentiel est d'apprendre vite et de minimiser le gaspillage (Waste).
Faire construire et lancer un vrai produit par une équipe de développement pour tester une idée est à peu près la méthode la plus lente et la plus coûteuse pour apprendre quelque chose.
7. Se concentrer sur les risques principaux
Lors de la Product Discovery il y a quelques points importants à prendre en compte.
Tout d'abord, nous devons nous concentrer sur les quatre risques principaux :
Valeur – est-ce que quelqu'un voudrait acheter ou utiliser ce produit ?
Utilisabilité – est-ce que les clients comprendraient comment l'utiliser ?
Faisabilité – nos développeurs peuvent-ils construire le produit avec la technologie, le temps et les compétences de l'équipe dont ils disposent ?
Parties prenantes – toutes les personnes impliquées dans l'entreprise sont-elles d'accord avec la solution proposée ?
La Product Discovery est la recherche de bonnes réponses à ces quatre questions. Une fois que nous les avons trouvées, nous disposons des preuves nécessaires et sommes confiants que l'équipe de développement peut mettre en œuvre et livrer une solution de qualité et évolutive.
8. Le rôle du MVP
Le concept du Minimum Viable Product est l'un des concepts les plus importants dans le développement de produits, et pourtant c'est aussi l'un des concepts les plus souvent mal utilisés et mal compris.
Généraliser est toujours risqué, mais je vais me mouiller et affirmer qu'un MVP ne devrait jamais être un produit. Chaque fois que j'ai rencontré une équipe qui avait construit un MVP en y consacrant beaucoup de temps et d'argent, j'ai pu lui montrer ensuite comment elle aurait pu obtenir le même apprentissage avec des coûts bien moindres et beaucoup moins de gaspillage.
Un MVP est donc une expérimentation – un test. Généralement, c'est une sorte de prototype. Souvent c'est un prototype destiné à l'utilisateur, mais parfois c'est aussi un prototype avec des données réelles ou il est utilisé pour des études de faisabilité. Et parfois c'est un mélange de tout cela. Dans tous les cas, ce n'est toujours qu'une petite partie du développement d'un produit réel.
9. Product Delivery : Aucun compromis sur la release
Il ne s'agit pas pour moi de dire aux développeurs comment ils doivent développer et publier leurs logiciels. Bien au contraire. Un problème qui survient lorsqu'une équipe de développement doit créer le MVP, c'est qu'elle se sent souvent obligée de publier un logiciel dont elle n'est pas convaincue. Elle ne se trouve pas vraiment pleinement derrière. Il y a peut-être des problèmes de fiabilité, de scalabilité ou de performance, mais le product manager répète sans cesse : « Ce n'est qu'un MVP, détendez-vous ! »
Je dis simplement qu'on ne devrait pas faire de compromis quand il s'agit de logiciels dont les clients dépendent pour maintenir leur activité. Il existe de nombreuses bonnes techniques de Product Discovery pour tester les MVPs, qui protègent nos clients, notre chiffre d'affaires, notre réputation et nos collaborateurs.
Alors utilise tes meilleures pratiques et ne publie des produits que lorsque tu as une confiance totale dans ce release.
10. Être obsédé par le client
Ce dernier point va dans une direction un peu différente. Dans presque chaque entreprise où je me rends, on me dit à quel point on aime ses clients. C'est généralement une partie des valeurs ou de la mission de l'entreprise. Le dire est facile, mais agir vraiment en conséquence est beaucoup plus difficile.
Je m'en rends compte assez rapidement quand je discute avec une équipe. Comment l'équipe gère-t-elle un problème avec un client ? Quelle urgence y accorde-t-elle ? L'équipe entre-t-elle en contact avec le client pour mieux le comprendre si nécessaire ? Les membres de l'équipe connaissent-ils les clients par leur nom ? Quelle relation entretiennent-ils avec eux ? Les clients leur tapent-ils plutôt sur les nerfs ou sont-ils peut-être même considérés comme des collègues ?
La meilleure façon d'éveiller une véritable empathie et un engagement envers le client est que les membres de l'équipe (surtout les développeurs) entrent directement en contact avec lui.
J'espère que cela t'aidera à mieux comprendre ce qui fait la grandeur des équipes produit.
Ce texte provient du blog de Marty Cagan et a été traduit en français par nos soins.
Outcome vs. Output
=> Comprendre le Minimum Viable Product (MVP)
