Les plus attentifs d’entre vous l’ont certainement remarqué, la hype autour des titres de Product Owners et Growth Hackers semble passée, ces termes étant de plus en plus remplacés par Product Manager pour les uns, et Growth Marketer, Head of growth ou encore Technical Marketer pour les autres.
Simple effet de mode ?
En réalité, non. Il s’agit dans les deux cas de se démarquer des dérives observées dans ces métiers, et de mettre en avant l’évolution que ces rôles ont subis ces dernières années.
Growth Hacker : à peine apparu, déjà disparu ?
A l’époque héroïque du Growth Hacking (il y a 2/3/4 ans), le growth hacker était un personnage seul, au profil mixte dev/data/produit/marketing, qui expérimentait des choses rapidement (souvent avec un certain succès) pour faire croître une entreprise (une startup en général).
Mais ce terme de “Growth Hacker” connaît déjà un déclin car il a subi de plein fouet 3 phénomènes :
- L’arrivée massive de profils peu qualifiés, s’improvisant growth hackers avec pour seuls bagages la connaissance de quelques outils d’automatisation et de scrapping.
- La désillusion qu'a engendré la rencontre entre des dirigeants qui attendaient des “tours de magies” et ces profils peu qualifiés
- L’évolution du rôle. En effet, il est rapidement apparu qu’un process de “Growth” avait tout à gagner à être fait en équipe, s’intégrant avec les dévs, l’ux, le marketing, la data, et le métier.
On est donc rapidement passé du “touche à tout seul dans son coin” à des profils, certes toujours multi-compétences, mais moins solitaires, et avec des “teintes” différentes selon les préférences et l’origine des personnes :
- Le “Growth Marketer”. Il s’agit en général d’un marketer maîtrisant le lean startup, comprenant l’importance d’une démarche test and learn, ayant l’envie de parler à la data et la tech et ayant une forte curiosité pour les nouveaux outils marketing
- Le “Head of Growth” ou “Growth Strategist” . C’est celui qui va pouvoir s’attaquer aux “meta-sujets” de growth : business model, process, organisation, moteurs de croissances, stratégie data, etc …
- Le “Technical Marketer” : Lui va surtout s’intéresser aux outils, aux solutions techniques aux problèmes marketing, à la récolte et l’utilisation de la data, etc … Il connait un ou plusieurs langages de programmation (front et/ou mobile), connaît des outils d’automatisation marketing, les tag managers, se connecte facilement aux APIs, s’occupe parfois de la SEO, …
- Le “Data Marketer” : Lui, sa spécialité, c’est la data marketing : il connaît à la fois les outils analytics, de dataviz et a souvent des bonnes bases de data science ou de statistiques. Il se débrouille en Python ou en R et, bien sûr, possède une forte culture marketing et startup.
- Et … Le “Product Manager”. Et oui. Car il ne faut pas oublier qu’une bonne croissance commence par un bon produit. Certains growth hackers ont donc la tentation de revenir aux “fondamentaux”. Enrichissant au passage le métier de PM avec leur côté “full stack” et leurs habitudes hautes fréquences héritées du GH.
Bien sûr, la frontière entre tous ces métiers est floue, et il n’est pas rare que certaines personnes cumulent 2 voir 3 de ces rôles. Et ces titres vont certainement encore bouger, car la mutation est toujours en cours.
En ce début d’année 2017, même si la démarche “Growth Hacking” ne s’est jamais aussi bien portée, on voit que le titre de “Growth Hacker” devient trop imprécis et connoté.
Product Owner…
…un demi métier ?
Rappelons d’abord qu’à l’origine, le rôle de “Product Owner” est né avec scrum, et a donc été dès le départ pensé PAR des dévs, POUR des dévs.
Le point positif : il a permis aux développeurs de mieux maîtriser leur travail et de se protéger des perturbations inutiles. Et en bref, il a permis aux projets IT d’aller dans la direction voulue, dans des bonnes conditions.
Mais cette direction voulue est-elle la bonne ? La stratégie produit est-elle judicieuse ? Les macro-priorités sont-elles pertinentes ? De quelles features ont vraiment besoin les utilisateurs ?
Ces questions, le rôle de PO ne vous donne aucun rituel, aucune technique, aucune méthode pour y répondre.
Et ne comptez pas sur le “Scrum Guide” ou la certification “Scrum Product Owner” pour vous aider à affronter ces questions. Ce volet du métier est complètement ignoré. Comme le dit une collègue :
“C’est comme si on te faisait une formation sur 50% de ton job et qu’on te disait : maintenant vas y et ne fais plus comme avant!”
Nous avons donc ici un titre qui définit un rôle incomplet.
Ce qui n’est pas le moindre de ses défauts.
Product owner = passe plat ?
Autre problème : le PO, tel que pensé par Scrum, a une propension à devenir le proxy entre les devs et le reste du monde. Il ne protège plus seulement les dévs des demandes directes et impromptues, il devient souvent LEUR SEUL LIEN avec le monde non-technique (users, marketing, métier, …).
Un lien qui, dans les cas extrêmes, n’a pas d’accès direct aux utilisateurs non plus ! N’importe quel “Lean Startuper” vous le dira : couper ainsi les dévs de l’extérieur est une abomination.
Cela fait entrer l’entreprise dans plusieurs cercles vicieux.
D'abord, le développeur, ainsi éloigné des clients finaux et des enjeux stratégiques et marketing, devient incapable de comprendre de quelle manière ce qu’il développe va être utile aux utilisateurs et à son entreprise.
Il perd en motivation, est obligé de déplacer toute sa force créative vers la technique (avec les risques de sur-conception que cela implique, et le gâchis que cela représente au niveau fonctionnel), et il a tendance à penser que le PO lui fait développer des choses qui n’ont aucun sens.
Le PO, de son côté, aura l’impression de passer son temps à expliquer des choses évidentes (par écrit en plus).
Coupé des enjeux comme il est, le dev devient donc également incapable de pré-valider lui même son travail, entraînant des allers-retours aussi évitables qu’exaspérants, ou pire encore : un alourdissement des process de spécifications des User Stories, qui deviennent de plus en plus précises et documentées, faisant intervenir de plus en plus de personnes.
Bref.
Entre autres problèmes, cette situation entraîne une sur-spécification et une sur-validation, qui ne laisse pas assez de temps au PO à consacrer à ce qui fait pourtant sa plus grande valeur ajoutée : déterminer dans quelle direction emmener son produit.
PO ou PM ?
C‘est donc en général pour se démarquer de ce travail principalement “passe-plat / validateur” que de nombreuses personnes remplacent leur titre de PO par celui de PM.
En effet, le terme “PM” fait en général penser à d’autres tâches (en plus ou en remplacement des tâches habituelles de PO) :
- Il est en charge (ou au moins challenge) la stratégie produit
- Il s’informe sur la stratégie marketing, la challenge, et y participe à sa manière
- Il s’informe sur la concurrence,
- Il comprend et challenge le business model, le pricing, etc …
- Il est en contact poussé avec les utilisateurs finaux et sait comment tirer un maximum de valeur de ces échanges
Pour conclure sur le PO
Dans les faits, la frontière entre PO et PM est mince puisqu’un PO avec un minimum de liberté aura tendance à pencher vers le PM, par la force des choses.
Mais ces manques et ces dérives ont nuit à l’image du terme “PO”.
Et ce désamour pour le titre de PO (au profit de PM) risque de s’accentuer en 2017.
