Les mythes sur la gestion de produit démystifiés
Beaucoup d’articles ont récemment été publiés par des designers sur la gestion de produit dans la Silicon Valley. Ça commence à me rendre un peu folle, alors je vais écrire un court essai brouillon de mon point de vue. J’ai été designer, responsable design, CEO de startup, chef de produit et General Manager responsable d’équipes pluridisciplinaires. J’ai donc quelques éclairages à apporter.
Mise en garde ! J’habite à Palo Alto/San Francisco depuis plus de 20 ans et j’ai travaillé dans de bonnes entreprises (Yahoo à l’époque, Linkedin, Zynga et d’autres) avec d’excellents chefs de produit. Mon point de vue est donc influencé à la fois par l’endroit et par la chance.
1. La gestion de produit est un métier récent dans la tech.
Les gens, je me suis lancée sur les internets en 1995 et il y avait déjà des chefs de produit dans les logiciels. La conception web était toute neuve, brillante, et la moitié des entreprises avaient des chefs de produit, l’autre moitié des producteurs, et beaucoup avaient des chefs de projets. Mais à l’époque de l’euphorie de 1999, tout le monde ici avait des chefs de produit.
Want more from The CPO Club?
Sign up for a free membership to complete reading this article:
Have an account? Log In
2. Les chefs de produit ne savent pas ce qu’ils font
Non, VOUS ne savez pas ce qu’ils font. Eux, ils savent ce qu’ils font, ils font tout.
J’ai été manager de restaurant. J’ai embauché, licencié, accueilli les clients, veillé à leur satisfaction, fait la comptabilité, travaillé avec le chef sur le plat du jour, l’ai écrit sur l’ardoise dehors, et acheté des pubs dans la presse locale. Et quand le commis n’était pas là, je coupais les légumes et, souvent, mes doigts. Oh, et quand le plongeur ne venait pas… vous voyez le tableau. C’est exactement ce que fait un chef de produit.
Ils ont leur mission principale : assurer l’adéquation produit/marché, surveiller et faire croître les indicateurs, et coordonner les équipes pour cet objectif. Mais les meilleurs, ceux avec qui j’ai travaillé épaule contre épaule, font tout ce qu’il faut pour maintenir le produit en bonne santé et le renforcer. Si cela signifie modifier une interface sous PPT parce que le designer est parti à 17h et que l’ingénieur a besoin de matière, il le fera. Si cela signifie aller chez Costco acheter des bières pour la soirée de lancement, elle le fait. Si cela signifie paramétrer des Google Ads parce que le marketing n’a pas le temps pour son produit, il le fera. Si cela signifie apprendre le SQL… vous voyez.
3. La gestion de produit, c’est presque comme le design UX.
Si seulement ! Eh bien, le métier serait bien plus facile si ce n’était que ça.
Les designers se montrent condescendants quand on ne fait pas la différence entre design d’interaction et architecture de l’information. Mais que savez-vous vraiment des chefs de produit ?
On parle des chefs de produit comme s’ils étaient une seule et même chose, mais il en existe trois types : l’ingénieur, l’analyste business et l’UX.
Le chef de produit à saveur « ingénierie » est souvent un ancien ingénieur, très utile pour collaborer avec les équipes techniques sur des sujets complexes comme la recherche ou les systèmes de recommandations.
Le chef de produit « analyste business » est l’optimiseur par excellence. Maître de l’A/B testing, du SEO et du growth hacking.
Le chef de produit à orientation UX excelle à trouver l’adéquation produit/marché. Il se concentre sur la fonctionnalité et l’expérience utilisateur, et est compétent sur l’onboarding, l’aide et les messages d’erreur.
Dans la Silicon Valley, on les surnomme souvent les “Product People”. On le dit généralement sur un ton admiratif. Les Product People comprennent vraiment leur marché et les humains qui le composent, et tiennent à créer le bon produit, celui qui prospérera. Ce sont des profils rares capables de concilier besoins business et attentes utilisateurs pour des produits à succès.
Les Product People s’opposent souvent aux designers parce qu’ils sont comme des frères et sœurs. Ils s’intéressent aux mêmes sujets. Ils peuvent se disputer pendant des heures sur la position de la navigation ou la forme d’un bouton.
Mais ils occupent des postes différents avec des intérêts certes proches mais pas identiques. Le Product Person est en forme de « T » : concerné autant par l’utilisateur que par le business, il/elle se bat parfois pour ce bouton de validation car il/elle pense au taux de clic. Ce n’est qu’une petite partie des responsabilités qu’il/elle gère, avec l’acquisition, la rétention, la prochaine refonte logicielle et l’analyse des indicateurs.
Le designer UX ou Product Designer (parfois appelé Interaction Designer) est un spécialiste qui se concentre sur la conception de l’interaction et de l’interface. Le designer va bien plus loin dans le détail du design (et c'est important) mais perd parfois de vue le rôle du design dans le contexte global de l’entreprise. Il peut défendre l’utilisateur au détriment de la santé de l’entreprise (ce qui ne devrait jamais arriver). Une entreprise qui ne survit pas n’apporte de valeur à personne. Si vous avez déjà dû annoncer à un client la fermeture de son produit favori, vous savez à quel point c’est dur.
Les chefs de produit analystes business sont souvent perçus comme rébarbatifs ou pénibles par les designers, et ceux d’ingénierie sont considérés comme incompréhensibles. C’est dommage, car les algorithmes gagneraient à être plus centrés utilisateur et le quali et le quanti, c’est comme le beurre de cacahuète et la confiture.
Même si les chefs de produit ont des expertises et compétences différentes, ils prennent rarement des titres spécialisés. Contrairement à un interaction designer ou à un designer UI, un PM n’a pas le luxe de ne pas faire la partie du travail qu’il ne maîtrise pas. Si vous êtes Product Person et qu’il faut s’occuper de ses KPIs, il faut s’y mettre.
4. Les chefs de produit ne se soucient pas du process (ou adorent Agile/Lean/Waterfall)
J’ai entendu beaucoup de gens se demander où se trouvent les conférences de gestion de produit. Il y en a quelques-unes récentes, mais historiquement les chefs de produit s'intéressent bien plus à leur secteur de marché qu’aux processus. Cela signifie qu’ils assistent à des conférences sur la recherche, le local, ou les objets connectés. La plupart obtiennent leurs méthodes de travail auprès de leurs ingénieurs et designers, et sont prêts à s’adapter à ce qui maintient leur équipe heureuse et productive.
La méthode Lean change ça dans une certaine mesure, mais d’après mon expérience, ce sont les disciplines de service qui sont obsédées par le processus, tandis que les chefs de produit sont prêts à adopter ce qui fonctionne.
5. Le chef de produit est le PDG du produit.
Honnêtement, celle-ci ne me dérange pas. Pas parce que le rôle de PDG et celui de chef de produit sont identiques, mais parce que peu importe ce qui se passe ou qui a fait l’erreur, vous, en tant que chef de produit, en êtes responsable. Comme un PDG. Votre prime disparaît quand Google lance un concurrent, votre poste disparaît si vous vous trompez de marché ou si vos ingénieurs ont mal estimé. Peu importe qui commet l’erreur, c’est à vous de la corriger.
À la différence du PDG, le chef de produit n’a pas le pouvoir de licencier. Ainsi, même s’il a la responsabilité de s’assurer du succès du produit, il collabore avec des ingénieurs et des designers qui ne lui sont pas hiérarchiquement rattachés. Il doit donc user de persuasion et d’influence pour orienter le travail. Ce sont d’excellentes compétences à développer si vous souhaitez un jour devenir PDG sans être un microgestionnaire. Malheureusement, certains chefs de produit utilisent l’unique pouvoir qu’ils ont, celui sur les décisions finales du produit, pour essayer de contrôler leur avenir.
Un bon chef de produit dirige ses équipes, un mauvais impose ses choix.
Cependant, puisqu’il ne conçoit ni ne code le produit, le mauvais chef de produit se retrouve souvent à devenir largement inutile pour l’équipe dont il a pourtant tant besoin. Et comme cette équipe manque souvent de données ou d’une vraie compréhension du marché (différente de la compréhension utilisateur), le produit échoue.
Les bons fixent une vision et des objectifs, inspirent, soutiennent et coordonnent, et mesurent les indicateurs pour apprendre et affiner le produit. Parfois, même ainsi, ça rate. Et c’est encore votre faute.
Bref
Je me souviens qu’en 2002, quand je travaillais chez Yahoo à la tête d’une grande équipe de designers, une designer d’interaction ne supportait pas le chef de produit avec qui elle collaborait. Elle ne comprenait pas pourquoi ce chef de produit venait sans arrêt, lui demandait de changer des choses, s’inquiétait des retards (et il y en avait. Des retards, oui.) Tout ce qu’elle voulait, c’était qu’on la laisse tranquille pour concevoir ses maquettes.
Puis nous avons changé la disposition des bureaux, et les designers ont été intégrés à leurs équipes produit. Lors d’un entretien individuel, elle m’a dit, « Mon Dieu, j’ai tellement de peine pour cette chef de produit. Tout est de sa faute. Les gens lui crient dessus toute la journée. » Elle a alors décidé d’essayer de lui simplifier la vie, d’écouter réellement ses besoins au lieu de lui dire ce qu’elle devait faire. Et aussi d’essayer de livrer à temps.
Je n’ai jamais oublié cela, même quand c’est moi qu’on engueulait, tenue pour responsable de chiffres sur lesquels je n’avais pas toujours la main, à cause des forces du marché. J’ai compris que lorsqu’il y a conflit, il y a sans doute un manque de compréhension. Et la compréhension conduit à l’empathie.
Designer, faites preuve d’empathie. Faites un peu de recherche utilisateur. Invitez votre chef de produit à déjeuner. Demandez-lui quels sont ses rêves, comment il ou elle est rémunéré(e). Demandez-lui quels sont ses plus grands défis. Demandez-lui quel était le meilleur designer avec qui il ou elle a collaboré. Peut-être découvrirez-vous que son métier est difficile, et que vous y contribuez. Peut-être trouverez-vous un moyen de réussir ensemble.
Allez faire un câlin à votre chef de produit.
Ce billet, par Christina Wodtke a été publié initialement sur Medium.
