Le product hacker

Aujourd’hui on parle du product hacker.

Si vous ne connaissez pas encore c’est normal !

Au delà des thèmes sur les techniques agiles ou sur le quotidien du product owner, ce blog est là aussi pour exposer les nouvelles tendances Product.

Ça tombe bien, le product hacking, c’est du lourd et c’est ma spécialité.

Dans ce post je vous explique 

• Qu’est qu’un product hacker ?
• Que fait-il ?
• Quelle est la différence avec un product owner ?
• Pourquoi le product hacker va devenir l’un des jobs les plus prisés dans les prochaines années ?

Allez chercher un café, installez vous confortablement, il y a de la lecture.

TOUT COMMENCE AVEC… LE GROWTH HACKER

La révolution Marketing

Si vous suivi les tendances Marketing, vous avez du entendre parlé du terme de growth hacker qui a émergé il y a quelques années par la voix d’un consultant Marketing américain nommé Sean Ellis.

Pour ceux qui ne connaissent pas, le growth hacking est une discipline qui consiste à mettre en place des hacks Marketing pour booster l’audience ou la croissance d’un service / produit rapidement.

Bien que souvent incompris voire même décrié par ceux qui disent qu’il s’agit juste d’un terme à la mode pour nommer autrement le marketing, le growth hacking est bel et bien une discipline à part entière qui va au delà du Marketing.

Toute la philosophie du growth hacking est basée sur de l’expérimentation rapide à moindre coût. 

Concrètement, un growth hacker est quelqu’un qui expérimente des techniques “out of the box” pour arriver à atteindre ses objectifs de croissance, d’acquisition, de conversion… rapidement.

Use case : 

Disons que vous souhaitez obtenir une liste d’emails de directeur/trice commerciaux pour promouvoir un service X ou Y qui vise cette cible.

En Marketing traditionnel, pour bâtir votre liste de prospects, vous allez utiliser des techniques classiques telles que :

Campagne de publicité Adwords ou Linkedin qui redirige sur une landing page avec un livre blanc gratuit à télécharger en échange de renseigner son adresse email.

• Ça coûte cher (coût de la publicité),
• C’est long (il faut écrire un livre blanc et faire la landing page)
• Ça mobilise du monde aussi…
• Mais ça a le mérite de marcher.

À la place, un growth hacker va se creuser la tête pour essayer d’expérimenter une technique moins chère et beaucoup plus rapide pour obtenir le même résultat.

Exemple d’un growth hack :

• Publier une fausse offre d’emploi très attractive pour un poste de “Directeur commercial” sur un job board de type Indeed.
  • Genre : Recherche Directeur/trice commercial / 100K /an

• C’est borderline
• Ça coute pas cher
• C’est ultra rapide à implémenter (1 heure au max)
• Ça marche aussi bien

Vous allez recevoir des tonnes de candidatures avec CVs et les adresses emails de prospects ultra qualifiés.

C’est ça un HACK ! 

Bon maintenant que vous avez compris le contexte du hack en Marketing, parlons du Product hacker.

C’est pas le même poste mais c’est la même logique.

C’EST QUOI UN PRODUCT HACKER ?

Tel le growth hacker, un product hacker est quelqu’un qui expérimente des techniques “out of the box” pour arriver à atteindre ses objectifs rapidement.

A première vue, on dirait que c’est pareil mais pourtant il y a une GROSSE nuance.

LA BASE : Le Framework AARRR

Si vous êtes familier du Framework AARRR (j’en parle ici), vous savez que ce modèle est massivement utilisé par des boîtes tech pour franchir des étapes clés de la constitution de leur Business.

Chaque étape de ce Framework correspond à une KPI à valider.

• A pour Acquisition

• A pour Activation

• R pour Rétention

• R pour Recommendation (Referral)

• R pour Revenus

Sur ce Framework, le terrain de jeu d’un growth hacker est situé avant tout sur l’Acquisition.

Selon le contexte du produit, il peut aussi intervenir sur l’Activation, le Referral et les Revenus.

En gros, son job c’est de trouver des techniques pour attirer une audience de prospects qu’il va pousser à s’inscrire et à utiliser le produit afin de les convertir en utilisateurs et/ou clients.

Pas d’acquisition avant la Rétention

Seulement voilà,

C’est génial d’attirer du monde pour tester un produit mais pour les convertir il faut valider un postulat de base.

Sinon, les gens partent et vous ignorent.

En d’autre terme, avec un produit moyen ou inutile vous n’avez pas de Product Market fit et donc pas de Rétention.

Le Growth hacker influe sur la cible mais il ne conçoit pas le produit lui même.

Si le produit n’est pas assez bon, il ne peut rien y faire.

QUE FAIT UN PRODUCT HACKER ?

Il est axé Métric : 

Le product Hacker est axé sur un seul objectif : Le Product Market Fit.

Sa Metric c’est la Rétention et parfois même l’Activation selon ce qu’elle signifie dans le contexte du produit.

On pourrait croire qu’en suivant les étapes du framework AARRR, c’est le Growth Hacker qui précède le Product Hacker, pourtant c’est l’inverse.

La metric la plus importante pour la viabilité d’un produit c’est la rétention.

Sans Product market fit et sans rétention, pas de growth hacking.

La rétention est son obsession

Ainsi on pourrait définir le product hacking comme une discipline qui consiste à mettre en place des hacks Produit pour booster la rétention (et activation) d’un produit rapidement.

Ça parait simple comme ça mais pour qu’un utilisateur aime et revienne sur votre produit, il faut plus qu’un bon design et des paillettes.

La rétention s’opère quand une personne qui utilise votre produit expérimente un Aha moment.

C’est le moment, ou la personne réalise quelque chose d’important sur votre produit :

• Il comprend son utilité
• Il devient Fan
• Cela résout parfaitement son besoin
• …

En terme produit, afin d’arriver à amener un utilisateur à expérimenter ce Aha moment il faut trouver les points d’inflexions.

La Killer feature est sa muse.

On en a déjà parlé, mais la Killer Feature ça se trouve pas sous le sabot d’un cheval.

C’est une histoire d’expérimentations.

Le travail préparatoire

Pour expérimenter dans les règles de l’art, vous avez besoins de 2 choses.

• Primo, il faut commencer par définir comment vous définissez votre étape d’Activation ou de Rétention
  • Exemple : Si votre produit est un site de rencontre
    • L’activation, ça peut être de remplir son profil entièrement
    • La rétention, ça peut être de répondre aux messages reçus
      
• Deuxièmement, vous devez définir les métrics qui permettent de mesurer ces signaux.

Sans ces 2 étapes, vous n’avez pas de repères pour expérimenter.

Une fois que vous avez ça, la base est de tester votre MVP ou votre fonctionnalité avec des utilisateurs cibles.

Si vous faites partie des 0,01% des cas et que tout fonctionne comme vous l’avez imaginez du premier coup, alors vous n’avez pas besoin de product hacking.

Pour les 99,99% restants, vous allez devoir avoir recours à des product hacks sous formes de tests.

Les tests représentent son quotidien

Phase de test 1 : Prioriser

• La première étape est de faire un brainstorming pour rassembler un maximum d’idées.

• Puis il s’agit de rassembler toutes les idées dans un backlog et de les prioriser 
  • C’est pareil qu’un product owner avec les US dans un backlog

• Pour les prioriser, il y a plein de paramètres à prendre en compte mais le truc le plus utilisé dans le Growth Hacking qui fonctionne très bien dans le Product Hacking également c’est la méthode ICE
  • I pour Impact
  • C pour Confidence (confiance)
  • E pour ease (simplicité)

En gros, cela permet de trier vos idées ou hypothèses en fonction de celles que vous estimez avoir le plus gros impact avec le moins d’effort à fournir.

• Maintenant que vous avez choisi l’idée à faire, il faut reprendre votre KPI qui compte et lui donner un objectif (valeur) à atteindre grâce à l’exécution de cette idée.
  
• Vous devez vous assurez de rassembler les bonnes conditions afin de mesurer correctement votre hypothèse (sinon le test est invalide) 
  • Environnement (démo ou prod ?)
  • Cible (testeurs internes ou vrais clients ?)
  • A/B test 
  • Outils de mesure (Google Analytics, Mixpanel…)

Phase de test 2 : La conception

• Vous travaillez sur l’exécution de votre hypothèse avec le moins de ressources possible (Développeur, UX designer…)
• Vous livrez 

Phase de test 3 : L’analyse

• Vous rassemblez les données jusqu’à obtenir un niveau de confiance acceptable
• Vous faites le bilan
• Si besoin, vous répétez le process jusqu’à l’obtention de votre objectif metric.

Un product Hacker lance en général plusieurs tests à la fois car il travaille sur le volume.

En effet, son objectif est de chercher le plus de réponses possibles pour comprendre comment arriver à concevoir sa Killer Feature.

Comme l’ensemble des résultats des tests sont souvent voués à l’échec, le volume permet d’apprendre beaucoup plus rapidement sur ce qui marche et ce qui ne marche pas.

QUELLE EST LA DIFFÉRENCE AVEC UN PRODUCT OWNER ?

C’est facile de faire le rapprochement avec un Product owner.

Faire ce raccourci c’est exactement faire la même erreur que ceux qui croient d’un Growth hacker c’est pareil qu’un Digital Marketer.

Je vous explique.

C’est pas le même contexte

• Un product hacker n’intervient pas sur toutes les facettes d’un produit.

Là où le product owner peut très bien travailler sur la partie inscription utilisateur, l’admin d’un produit ou la partie Panier d’un site e-commerce, le product hacker ne travaille que sur la Killer Feature.

Son job n’est pas de concevoir le produit de bout en bout.

Exemples :

• La fonctionnalité “Réservation” de Uber
• La page “Tendances” de YouTube
• La fonctionnalité “Recherche” de Airbnb

Sa seule quête est de bâtir ou d’optimiser le pilier du produit.

Son niveau d’intervention

• Le product hacker peut intervenir en phase de MVP

Exemple :
Aider une startup qui a lancé un produit mais qui peine à activer ou retenir ses utilisateurs

Dans ce cas, son intervention peut décider du sort de la boîte.

S’il réussit, la startup a le potentiel pour devenir un vrai business, “reste plus” qu’à scaler.
S’il échoue, la startup est mal barrée.

• Le product hacker peut également intervenir en phase plus avancée d’un produit.

Exemple : Un produit dont le business est existant mais qui ne convertit pas assez naturellement.

Les utilisateurs n’aiment pas le produit mais sont obligés de l’utiliser car c’est un outil de travail imposé par leurs employeurs

Les utilisateurs ont besoin d’une formation avancée pour comprendre le fonctionnement ou l’utilité

Dans ces 2 derniers cas, son intervention va permettre de diminuer les coûts structurels de la boîte (service client, service commercial, support) et permettre au produit de gagner des avis positifs sur le marché.

Un product hacker qui travaille pendant plusieurs années de façon continu sur un même produit c’est un product owner.

C’est pas le même process

Là où le product owner n’opère que dans la sphère du scrum (ou du Safe), le product hacker est complètement décorrélé de tous process ou méthodologie.

Cela ne veut pas dire qu’il ne pratique pas l’agilité mais il opère dans une sphère beaucoup moins codifiée.

• Pas de rétrospective
• Pas de backlog grooming ou de sprint planning
• Très peu de specs
• Pas forcément de sprint 
• Surtout pas de date de livraison

Même si l’agilité et le scrum en particulier permet de fluidifier le process de conception en entreprise, il reste parfois assez rigide pour exercer des product hacks.

Une équipe type d’un product hacker c’est

• Un développeur fullstack
• Un UX designer

Et encore, parfois, c’est le product hacker qui fait l’UX design.

Contrairement à un product owner, c’est lui même qui teste la fonctionnalité ou les hacks livrés (pas de testeurs).

Son quotidien est différent

Le product hacker n’a pas le temps d’écrire des specs détaillées, de les chiffrer, de les planifier et de participer a tout à un tas de cérémonies d’ouverture, de suivi ou de clôture d’un sprint.

Il est assis à côté de son développeur et de son designer et les cérémonies, planning, tâches à faires se décident assis les uns à côté des autres en continu.

Comme la majorité des hacks vont se terminer en code mort, pas besoin de documenter quoique ce soit.

Comme le test est toujours ciblé sur un cas d’usage précis, le développeur opère sur sa branche et travaille en isolation avec les autres branches du produit.

Le but est tester vite sur un échantillon d’utilisateur.

Les contraintes de qualité et de performance sont minimes.

C’est seulement si le hack à fonctionné qu’un product owner et son équipe peuvent prendre le relai et optimiser la solution (UI, performance…).

C’est pas les mêmes dépendances

Le product hacker n’a pas vraiment de place très précise dans l’organigramme d’une organisation.

Il se place en tant qu’intervenant.

Ça a comme avantage de lui épargner trop de réunions inutiles et de devoir faire le lien avec tous les services en permanence.

On ne prend pas un product hacker pour faire de la politique et gérer les situations internes.

Il n’a pas de rôle de management comme peut l’avoir le product owner.

Pour l’aider à réussir il doit s’affranchir des process mis en place dans l’entreprise.

S’il intervient c’est justement pour trouver des solutions qui n’ont pas été trouvé en interne.

Il doit bien évidemment informer sur ces actions mais un product hacker ne doit pas être bridé dans ses hacks sinon c’est l’échec assuré.

Il est hors sprint

Enfin, comme je l’ai dit avant, il opère en cycle très court et n’est pas synchronisé avec les sprints des autres équipes (au cas où il opère dans une organisation qui utilise scrum).

POURQUOI LE PRODUCT HACKER VA DEVENIR HYPE ?

Vous l’aurez compris, un product hacker est une espèce d’un nouveau genre, une sorte de mutant entre un product owner et un business Analyst.

La raison pour laquelle je pense que c’est un job qui va exploser à moyen terme part d’un constat du marché.

L’omniprésence de l’agile :

Aujourd’hui, la transformation agile en entreprise est entrée dans sa phase mature.

Il y a encore du boulot et des trous à combler mais le PO et son équipe scrum sont devenu un standard dans les boîtes tech.

Le process agile fluidifie la relation entre le client et l’équipe produit en prenant en compte les aléas du métier (changement de priorités, changement d’objectifs, nouveau contexte…).

Pourtant, à l’inverse du Marketing, la partie produit n’a pas encore connu sa révolution.

L‘agilité est juste une révolution du process d’entreprise.

La limite de l’agile :

Grâce aux principes agiles, on fait intervenir tous les acteurs de l’entreprise dans la conception d’un produit.

Pourtant il existe un gros biais.

Exemples :

• Il faut refaire ce tunnel de commande car il n’est pas clair…
• Il faut afficher un menu hamburger à la place d’une tab bar parce que c’est mieux…

En tant que product owner, vous avez certainement vécu ce genre de virage à 180 degrés dans certaines étapes de la conception d’un produit sans avoir d’autres justifications.

Le biais est que bien souvent le client essaie de définir la solution avec vous alors que son job est juste de définir le besoin.

La crise existentielle des équipes produits 

A la fin d’un projet ou d’une livraison, on se félicite.

On est heureux d’avoir participé à un projet bien cadré qui a respecté tout le process agile.

Et puis parfois (souvent), on a des lendemains qui déchantent.

On n’en parle pas, on est occupé à faire de nouvelles choses et on fait semblant de ne pas savoir Mais… 

le produit ne décolle pas.

• C’est le Marketing qui a du merdé dans ses actions.

• Ou peut être que ce sont les commerciaux qui sont nazes…

Et le produit, y’a rien qui cloche ?

• Ben non, il est bien conçu, y’a pas de bugs
• Il respecte toutes les règles métiers
• On l’a fait en agile en plus…

Comment expliquer ces situations ?

A combien s’estiment le nombre de produits bien conçus qui partent aux oubliettes ?

Dans la tech plus que dans n’importe quel autre secteur d’activité, il y a beaucoup de gaspillage.

Il existe un nombre incroyable de solutions qui ne répondent à aucun problème marché et qui ont nécessitées des investissements ÉNORMES.

Cela représente un cimetière de code mord, des kilomètres d’UX qui s’étalent à perte de vue.

Pourtant personne n’en parle…

On continue de s’extasier sur les nouveaux process, les nouveaux outils et les nouvelles technos… jamais sur le bilan commercial des projets. 

La vérité c’est qu’il y a un GROS TABOU sur ce sujet dans notre milieu.

La révolution du Produit

Maintenant que l’on sait enfin concevoir un produit en faisant collaborer les métiers, le product management est à l’aube d’une révolution.

La révolution c’est le Product Hacking.

A part dans de jeunes startups où les fondateurs n’ont pas le choix par manque de moyens, la majorité des entreprises scindent la partie conception produit et lancement produit en 2.

Il y a le produit ou le département technique d’un coté et le Marketing de l’autre.

En apparence, il s’agit de 2 activités différentes, mais pour qu’un produit voit le jour et rencontre son marché, il faut réunir les compétences dans le même rôle ou dans la même équipe.

• On ne peut plus définir des specs d’un côté et définir un test marché de l’autre.

• On ne peut plus lancer une campagne d’acquisition sans l’aide des concepteurs produit.

Le principe d’itération ne peut s’opérer que si les concepteurs sont au coeur de la mise sur le marché.

Scinder ces rôles en 2 équipes différentes créés trop de frictions :

• Les retours d’expérience prennent trop de temps à etre analyser
• Les relais d’informations font perdre la compréhension globale
• Les ajustements produits à faire arrivent trop tard.

• ll monitore lui meme les données produit et les données marché dans un seul tableau
• Il a le pouvoir d’influer sur la sphère campagne Marketing et/ou la sphère fonctionnalité produit pour dynamiser les métrics.

UN GROS PARI

Je l’avoue, le product hacking est une pratique qui est encore beaucoup plus entrepreneuriale que corporate (pour le moment).

Pourtant, je la vois émerger peu à peu sous différents noms dans des entreprises plus conventionnelles.

La différence entre (simplement) créer un produit en suivant des besoins métier et créer un produit et le mettre sur le marché est Énorme.

C’est un role qui requiert une grosse pluridisciplinarité et un expérience énorme !

Malgré tout, la tendance entrepreneuriale et le succès des méthodes growth hacking font de plus en plus émerger des talents ayant des compétences 360 sur le marché.

Il y a clairement des enjeux :

La barrière entre le Produit et le Marketing est de plus en plus fine et les enjeux de réduction de coûts et d’impacts sur les résultats sont colossaux.

Reste à connaitre si c’est les entreprises d’aujourd’hui sont pretes à intégrer des roles qui fusionnent 2 métiers et deux responsabilités distinctes.

Si on prend l’exemple du role du product owner :

• Aurions-nous parié sur la domination d’un rôle qui fait le lien entre la partie métier et technique il y a tout juste 15 ans de cela ?