Après 3 ans et 3 startups, j’ai compris la vraie valeur d’un Product Manager

“There are some people you just can’t help” — Tiny Buddha

En sortant d’école de commerce, j’étais perdue, je ne me reconnaissais pas dans les choix de carrière qui m’étaient proposés. Je visualisais ce que je voulais mais je n’arrivais pas à mettre de terme sur le poste que je recherchais. Je n’avais que des mots en tête : tech, innovation, autonomie, communication, réflexion, stratégie, startup.

En parcourant des centaines d’offres, celles qui se rapprochaient le plus de mon idéal étaient des offres de fullstack developer, de dev ops ou de lead back end. Je renonçais à postuler quand je voyais ces listes d’acronymes énigmatiques décrivant des compétences que je ne possédais pas (C++, JS, PHP…)

J’ai donc oublié cette vague idée en me disant que le métier de mes rêves ne devait certainement pas exister et je suis devenue commerciale (on dit “sales” dans le milieu) dans une startup parisienne. Grâce à cette expérience et à de belles rencontres, j’ai fini par me rendre compte qu’il existait bien un poste qui cochait toutes les cases de ma wishlist : celui de Product Manager !

J’exerce ce métier avec plaisir depuis maintenant 3 ans.

Après avoir parlé avec d’autres PM de notre communauté je me suis rendue compte que nous sommes tous tombés sur la voie du produit par pur hasard.

Aujourd’hui de plus en plus de personnes participent à l’essor de notre métier. Des formations spécialisées et des ressources émergent (voir à la fin de l’article, ma sélection) et améliorent la visibilité de ce nouveau métier.

J’aimerais moi aussi participer, à mon échelle, en éclaircissant certains aspects mystérieux qui pourraient bloquer un potentiel PM talentueux de franchir le cap.

Un chef de produit n’est pas un chef de projet

Quand j’ai été embauchée pour la première fois en tant que junior Product Manager, je ne savais pas du tout en quoi consistait concrètement ce métier. J’ai appris en regardant mes deux managers travailler.

J’ai, dans un premier temps, pensé à tort que l’objectif principal du PM était de faire en sorte que les développeurs délivrent en temps et en heure des fonctionnalités qui marchent dans tous les cas d’utilisation .

On consacrait 90% de notre temps à cet objectif.

• On se creusait le cerveau pour trouver des méthodologies pour motiver les développeurs à être plus efficaces : SCRUM, Kanban… On essayait d’animer de la façon la plus joviale possible tous nos rituels d’équipes. On changeait de méthodologie tous les 6 mois, ce qui était très chronophage car il fallait changer d’outil de gestion de projet, mener une conduite du changement et réapprendre à travailler et à s’organiser.
• On passait de longues heures à rédiger en détail des spécifications pour expliquer aux développeurs le comportement exact de chaque amélioration qui devait passer en développement.
• On testait de fond en comble les nouvelles fonctionnalités mais aussi tout le reste de l’application pour nous assurer qu’ils n’aient pas créé de régressions.
• On s’acharnait à reproduire tous les bugs rencontrés par nos clients pour trouver leur cause et mâcher le travail de résolution aux développeurs dont le temps est précieux.

Les autres 10% restants étaient mis à profit de la création de la “roadmap” ou feuille de route. Une liste de fonctionnalités étalées dans le temps qu’on s’engageait à compléter en un trimestre.

Pour élaborer cette liste, on réunissait l’équipe produit et l’équipe tech dans une pièce pendant une demie journée avec des post-it et un tableau blanc. Le comité exécutif nous donnait une liste d’OKR (objectif / résultats) à atteindre pendant ces 3 mois. En se basant sur ces objectifs, on listait des fonctionnalités qu’on pensait pouvoir sortir et qui allaient certainement nous permettre d’atteindre les résultats espérés. Chaque feature de la liste était ensuite estimée à la louche par les développeurs. Nous, PM, on priorisait les fonctionnalités en fonction du potentiel impact que chacune allait avoir sur l’atteinte de l’objectif et du coût de développement. Et voilà, notre feuille de route était prête et le comité exécutif était très content de regarder nos slides et de se dire qu’on allait réussir à atteindre les résultats fixés sans problèmes.

La réalité de l’exécution est toute autre. Après 2 ans, j’ai réalisé qu’on n’avait jamais réussi à suivre cette roadmap. J’ai compris que le temps de développement d’une fonctionnalité est nettement plus important que le temps de design ou de spécification. Du coup, on était embarqué dans un cercle vicieux où, pendant que les devs codaient, nous on écrivait des pages de specs fonctionnelles pour préparer les features qui devaient être développées après. On prenait de plus en plus d’avance et les développeurs, de plus en plus de retard. On ne faisait que créer du stock qui devenait obsolète assez rapidement. Tout le monde était frustré. Les clients se plaignaient car leur logiciel ne correspondait pas à leurs besoins opérationnels, les autres équipes était desespérées de voir qu’on était incapable de tenir les délais annoncés pour la sortie d’une fonctionnalité. Dans notre équipe, devs, PM et designers étaient tout aussi démoralisés car on n’avait l’impression de ne pas avancer car le backlog (ce fameux stock de fonctionnalités en attente de développement) ne diminuait pas.

En quittant cette première expérience, j’ai réalisé que cantonner le chef de produit au rôle de chef de projet ce n’était pas du tout la meilleure façon d’exploiter la valeur qu’il peut apporter à une entreprise.

La gestion de l’équipe et du développement nous prenait tellement de temps et d’énergie qu’on en a oublié d’apprendre à connaître nos clients. La roadmap était créée en une demie journée, sans considérer leurs besoins. Les décisions étaient basées sur des objectifs business. On n’a jamais apporté de solutions aux problèmes que nos utilisateurs rencontraient. On a exploité nos ressources à mauvais escient et la satisfaction client, un de nos indicateurs clés, n’a fait que diminuer en 2 ans.

Un chef de produit résout des problèmes

Mais avant de résoudre les problèmes il faut les comprendre

Les produits les plus inspirants du marché ont été construits de la même façon. Les Product Manager de ces entreprises là ne passent pas du temps à coordonner des équipes de développeurs, à résoudre des bugs ou créer des fonctionnalités en se basant sur des suppositions. Ces chefs de produit là passent l’essentiel de leur temps sur le terrain pour comprendre le plus possible leur utilisateurs, et c’est comme ça que les meilleures idées émergent.

J’ai commencé à comprendre ça la première fois que j’ai assisté à une conférence d’un Product Manager de Blablacar. Il racontait qu’un jour, avec toute son équipe, ils s’étaient donnés une mission : ils avaient chacun pioché un point de départ et un destination au hasard en France et devaient s’y rendre uniquement en covoiturage. Ils ont réalisé que le plus difficile dans cette mission a été de se rendre au point de départ parce que les conducteurs n’étaient jamais exactement là où ils se trouvaient.

Ils ont décidé d’ajouter sur l’écran principal des résultats de recherche un élément visuel pour aider le passager à évaluer la distance du point de rendez-vous par rapport à leur adresse de départ. Cette fonctionnalité permet à l’utilisateur, en un coup d’oeil, d’optimiser le choix de son trajet.

Cette idée ne serait jamais ressortie si le problème de base n’avait pas été identifié. Et ce problème n’aurait pas été identifié si les PM de BlablaCar étaient restés dans leur bureau.

Les clients sont les seuls à savoir ce dont ils ont besoin et ce qu’ils ressentent au moment où ils utilisent notre produit.

Notre rôle de chef de produit est de réussir par tous les moyens à les comprendre le plus possible.

Blablacar a de la chance car ils ont un produit B2C accessible. Même si, encore une fois, ils ne peuvent pas physiquement se mettre à la place de leur client, ils peuvent plus facilement reproduire les conditions dans lesquelles ils utilisent leur application pour comprendre au mieux leurs besoins sur le moment.

Tous les produits ne sont pas dans ce cas de figure. Parfois, il faut se creuser la tête pour essayer de comprendre le plus possible ses utilisateurs et dans la majorité des cas, la seule solution est de passer beaucoup de temps à leurs côtés. Il faut les écouter, les observer et leur poser des questions.

Quand j’appelle des clients ou que je vais à leur rencontre, j’imagine que je suis face à ma meilleure amie, dans un bar. Un jour, elle m’a parlé de ses problèmes de couple, elle m’a dit qu’elle voulait quitter son copain assez rapidement dans la discussion. Or, en lui posant quelques questions, je me suis rendue compte que son problème principal n’était pas son copain mais son travail. La solution qu’on a trouvé ensemble pour soulager ses problèmes était donc très différente de la première solution envisagée. Elle a quitté son travail, elle a trouvé un poste dans la même ville que son copain et ils sont toujours ensembles.

Les clients vont, comme ma meilleure amie, souvent directement à la solution. La valeur du PM est de réussir à faire ressortir le besoin profond de son utilisateur afin que le champ des solutions possibles pour y répondre soit beaucoup plus large.

Les chef de produit ne connaissent pas LA bonne solution

Une fois que le problème est cerné, il faut le solutionner. Là encore, le rôle du PM n’est pas de sortir de son chapeau la bonne solution pour un problème donné. Les meilleurs chefs de produits savent qu’ils n’ont pas cette réponse. Par contre, ce que savent faire c’est de s’entourer des meilleures personnes et de leur poser les bonnes questions pour aboutir à une liste de solutions potentielles. La discussion avec des experts permet de lister des idées.

Chaque idée se base sur une liste de croyances qu’on a sur nos clients. Ces croyances ne sont pas forcément vraies. En fait c’est là toute la valeur qu’un chef de produit peut avoir. En prenant du recul pendant la discussion où fusent les idées de tous les côtés, il est capable d’en extraire les suppositions qui sont émises à propos du comportement et du besoin des clients.

Chaque supposition doit alors être scrupuleusement validée ou invalidée en la testant auprès de nos clients. Il ne faut pas attendre d’avoir un prototype abouti pour tester les hypothèses émises lors de l’élaboration d’une solution. Le product manager, accompagné d’un product designer peut être inventif et trouver d’autres idées pour valider les suppositions le plus rapidement possible pour affiner la solution finale et faire en sorte qu’elle corresponde réellement au besoin des utilisateurs.

Ce qui m’amène à vous parler de l’entreprise où je travaille actuellement : LiveMentor. Nous proposons une formation certifiante en ligne pour les entrepreneurs ou salariés qui ont besoin de se former à des compétences précises pour avancer dans leur projet. Notre produit est une plateforme sur laquelle nos clients peuvent

• retrouver leurs cours en ligne
• bénéficier des conseils de leur mentor attitré en asynchrone via une messagerie ou en synchrone lors de coaching en visio
• participer à des webinars collectifs, atelier lors desquels ils peuvent mettre en pratique les compétences acquises.

Depuis que je suis arrivée chez LiveMentor, notre product designer et moi même consacrons une majorité de notre temps à mettre en œuvre cette méthode empirique pour construire notre produit. Nous voulons être sûrs que chaque fonctionnalité qui sera développée répondra à un besoin de nos clients.

En rencontrant de nombreux entrepreneurs en formation, j’ai compris qu’ils ont besoin de sentir qu’ils ont un parcours de formation adapté à leur objectif personnel. Il existe une multitude de solutions pour répondre à ce besoin.

En faisant une session avec nos experts pédagogie composée de mentors, plusieurs idées ont émergée, notamment une, qui est de séparer le premier questionnaire d’onboarding auquel répondent nos clients avant d’entrer en formation, en deux chemins : un pour les créateurs d’entreprises et un pour les personnes en reconversion professionnelle.

Avant d’ancrer cette idée dans la pierre, nous avons décidé de valider cette segmentation. Est-ce que tous les entrepreneurs qui entrent en formation se reconnaissent dans l’un ou l’autre des chemins ?

Nous avons donc créé un Typeform avec ce questionnaire. La première question à laquelle l’entrepreneur doit répondre est celle ci :

En fonction des réponses, on pourra valider ou invalider notre hypothèse et adapter notre solution.

Conclusion

Cette méthode empirique de conception de solution est très longue. Chez LiveMentor, on utilise la majorité du temps de nos Product Manager pour créer des fonctionnalités qui répondent à un besoin réel. Aujourd’hui, je passe une majorité de mon temps avec nos clients et experts métiers sur le terrain. Je ne crée plus de stock en spécifiant des fonctionnalités qui ne sortiront peut-être jamais. Je passe plus de temps à concevoir la roadmap qu’à faire en sorte que les développeurs la délivrent et je sais, chaque matin en me levant, que j’apporte de la valeur à notre entreprise.

Derniers conseils pratiques

J’ai découvert grâce à Alexandre Dana la méthodologie Lean qui nous a permis de drastiquement améliorer la vélocité de notre équipe produit. Je conseille fortement le livre de Régis Medina, “Learning to scale”, à toutes les équipes produit qui souhaitent améliorer leur vitesse de delivery. Cela vous permettra de libérer du temps aux PM pour qu’ils concentrent leur énergie là où ils apportent réellement de la valeur.

J’ai besoin de continuer à apprendre sur mon métier chaque jour. Chez LiveMentor, la pédagogie dans nos veines et nous faisons souvent appel à des mentors. Je souhaite remercier le nôtre, Anthony Adam qui nous aide à améliorer notre méthodologie de conception à vitesse grand V. Je conseille à tout le monde peu importe la séniorité d’appeler à l’aide dès que vous en avez besoin. Parfois il suffit de quelques échanges avec la bonne personne pour faire un bond de géant.

Et pour finir, une liste non exhaustive des ressources pour en apprendre plus d’experts du product management sur ce métier si mystérieux et pourtant si excitant !

• La bibliothèque de ressources de The Product Crew, par Mehdi Ayouche
• La formation Noé, par Maïa Metz
• Le podcast Product Squad par Axel Sooriah
• La série d’article de Steve Anavi (et de façon général le compte medium de Qonto est très inspirant niveau produit)
• (Un des) Talk de Rémi Guyot sur la simplicié
• Un article d’un Product Lead chez Stripe qui donne des conseils pour réussir sa carrière en product management
• Et enfin, la vidéo qui m’a beaucoup inspirée à écrire cet article : Teresa Torres qui nous parle de product discovery