Les titres de Product Owners et Growth Hackers ont-ils encore un sens en 2017 ?

Les titres de Product Owners et Growth Hackers ont-ils encore un sens en 2017 ?

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.

 

1 Comment Les titres de Product Owners et Growth Hackers ont-ils encore un sens en 2017 ?

  1. Alex Davis

    Good job! C’est très vrai que ça change toujours! Mais plus ça change, plus que ça reste pareil. 😉

    « 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. »

    Perso, j’ai toujours connu le growth au sein d’une équipe multi-fonctionnel. Une personne growth travaillant seul va difficilement avoir du succès. J’ai fréquemment refusé des offres d’emploi parce que l’employeur voulait essayer le growth avec l’embauche d’une seule personne. Ensuite, s’ils voyaient des résultats, ils allaient embaucher plus de gens. C’est rares qu’ils vont voir du succès parce que c’est impossible de trouver une personne analyste/développeur/marketing/produit. Ensuite, si ces ressources ne sont pas dans la même équipe, l’itération se fait lentement et il y a des conflits de ressources.

    Une chose qui est certaine par conte (et dont tu as touché), il y a plusieurs types de growth hackers. Dans mes équipes multi-fonctionnel, on se considérait tous des growth hackers. Je faisais le product management et l’analyse, d’autres faisait le back-end et les outils et il y avait un designer qui faisait du front-end. Les équipes variaient entre 3 à 6 personnes. Question d’avoir une équipe auto-suffisante comme une équipe agile de SCRUM.

    Comme tu dis, aujourd’hui, ce que nous percevons c’est des titres qui apparaissent pour chacun des ses rôles. Tu sembles tous les identifier à l’exception du growth engineer et le front-end growth. Le premier est une personne hyper technique qui peut faire le rôle de growth marketer, mais peut monter des BD et des serveurs pour les tests A/B les plus complex. Cette personne est normalement très à l’aise avec la data. Le deuxième est une personne UI/UX pense à la conversion dans ses designs et peut les intégrer lui même avec du JS/CSS.

    Une autre nuance à faire sont les différences régionaux. Le growth est un terme très utilisé à SF, mais très peu de gens connaissent ça à NY ou Montréal. C’est plus des « technical marketer » et des « digital marketer ». Bref, quand on se cherche un emploi, il faut utiliser 5 synonymes différents. lol

    Le product manager, quant à lui, éxiste depuis longtemps et a souvent été le product owner au sein d’une équipe SCRUM. Ce qui change depuis quelque temps, c’est que les PM commencent à se soucier des métriques beaucoup plus. J’ai observé qu’autrefois, ils se préoccupaient plus des données qualitatives et moins des quantitatives. Les notions de rétentions et de « engagement » sont devenues importantes. Ils se concentrent moins sur livrer des nouvelles fonctionnalités et plus sur offrir quelques features essentiels qu’on ne peut pas se passer. (en parti grâce à l’optimisation et les tests)

    Josh Elman ( Twitter, Facebook Connect, Zazzle, LinkedIn, RealPlayer) est venu faire un discours dans mon bureau cet été et nous a partagé ses expériences de product manager des >10 dernières année. Ce qu’on observe c’est que le rôle est un peu différent dans chaque équipe. Mais avant tout, il touche à tous les points que tu as énuméré dans ton article ci-haut. Pour les curieux, je recommande de lire son article de Medium de 2013 sur le rôle du Product Manager: https://medium.com/@joshelman/a-product-managers-job-63c09a43d0ec#.fg1h4gzn1

    Reply

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *