Expliquer le growth engineering à ma grand-mère

Comment expliquer un métier technique à n'importe qui, en particulier le growth engineering.

J’ai réécrit cet épisode un an après sa première publication. Il était confus, partait dans tous les sens, et, surtout, me cringeait à un stade terminal. C’était nécessaire.

Ce que j’essaye d’expliquer, avec tous ces symboles, c’est le growth engineering et généralement, c’est pas clair. L’ambition de cet épisode, c’est que ça le devienne.

Pourquoi expliquer le growth engineering ?

Je pose les fondations des articles qui vont suivre

Voici un de mes premiers cours de maths en prépa, dispensé par Johann Wattiez, mon professeur. Le contenu n’a pas d’importance ici, ce qui compte c’est ce que j’ai souligné.

Tous mes cours en prépa, ont commencé par des définitions.

TOUS.

Lorsqu’on voit ça pour la première fois, on est tenté de l’interpréter comme la lubie d’un prof un peu solitaire. Puis la prépa avance, et on comprend.

On comprend que plus l’édifice intellectuel dans lequel naviguer est complexe, plus il est important d’avoir des définitions claires.

Or, l’ambition de cette newsletter, c’est justement de construire un petit “édifice intellectuel” autour du growth engineering. Voilà pourquoi il me semble primordial de donner quelques définitions.

C’est la première raison pour laquelle j’envoie ce premier mail, mais pas la seule :

  1. Je vais donner des clés aux personnes qui travaillent dans la tech pour expliquer leur métier.

  2. Je vais expliquer plus spécifiquement aux growth engineers comment décrire le leur.

  3. Enfin, j’espère que certains, en me lisant, se découvriront un intérêt pour le growth engineering et envisageront d’en faire leur métier.

Je dois apprendre à expliquer clairement mon métier

Je viens de faire le bon petit samaritain en disant que j’écrivais cet épisode pour le bénéfice des lecteurs. Ce n’est pas faux, mais je l’écris avant tout pour mon propre bénéfice, car j’ai du mal à expliquer clairement ce que je fais (vraiment beaucoup).

Or, une carrière, ça occupe beaucoup de place dans une vie :

Donc si on n’arrive pas à clairement l’expliquer, ni à susciter le moindre intérêt chez les personnes auxquelles on l’explique, on peut se sentir légèrement dénigré :

  • Pour ma grand-mère, je fais de l’ordi

  • Pour le Français lambda, je suis ce mec

  • Pour (une partie de) la tech, je fais du scraping et je suis growth hACkEr

La dure réalité est que je ne peux pas en vouloir aux gens de ne rien comprendre à mon travail. Quand je l’expliquais, je pondais des trucs comme ça (sic) :

yes, vite, la palme du cringe

Bref, je devais de toute urgence trouver un moyen de m’exprimer clairement. Pour mon propre bénéfice — pour ma survie sociale (lol).

Mais je crois aussi que ce serait utile aux entreprises.

Les entreprises doivent connaître le growth engineering

Prenons l’exemple de l’outbound.

Certes, faire un peu de lead gen et envoyer des emails n’a rien de compliqué.

En revanche, lorsqu’on veut exploiter une multitude de signaux d’intent, scorer les leads en fonction des signaux qu’on a détectés, ne les contacter que lorsqu’ils passent un certain seuil de score, etc. le sujet devient résolument plus complexe.

Une entreprise peut vite se retrouver noyée dans les workflows et les outils si elle ne sait pas qu’il existe des profils en mesure de l’aider (growth engineers dans ce cas précis) et sa croissance risque de stagner.

Les clés pour expliquer un métier technique

Rentrons dans le vif du sujet. J’aborde ici quelques conseils glanés au fil de mes lectures et de mes expériences personnelles. Ça me semble être les plus importants.

Mieux vaut des explications trop simples que pas assez

Au moment d’expliquer un sujet qu’on comprend très bien (comme nos métiers), on a deux options :

  1. simplifier nos explications pour que tout le monde comprenne

  2. les compliquer pour montrer à quel point on est intelligent

Le problème c’est qu’on a peur de trop simplifier nos explications. On se dit que les explications simples sont pour les gens simples.

Voilà pourquoi on choisit souvent la deuxième option. On va à l’inverse de la simplicité pour prouver notre intelligence. Mais ce faisant, paradoxalement, on prouve tout l’inverse.

Je l’ai compris grâce à la vidéo du dessus (entre 13:58 et 17:20).

Mais ne pas faire d’efforts de simplifications n’est pas seulement bête : c’est égoïste.

En compliquant les choses, on impose à l’auditoire de faire le travail de compréhension, de tri et de filtrage de l’information qu’on s’est refusé de faire pour eux — pas cool.

C’est d’ailleurs valable à l’oral comme à l’écrit. Je vous recommande ces deux lectures pour enfoncer le clou :

  • Write Simply, de Paul Graham (oui, je suis cliché au point de citer Paul Graham oui)

  • Writing Better, de Julian Shapiro (un de mes écrivains en ligne préféré cette année)

Mais parfois, simplifier la réalité ne suffit pas. Il faut la déformer.

Il faut parfois déformer la réalité et mentir pour être compris

Parfois, j’essaye d’imaginer ce qui ce serait passé si on m’avait expliqué l’électricité de cette façon au lycée (ou pire, au collège) :

On n’aurait jamais compris quoi que ce soit à l’électricité.

Et pourtant Veritasium est un bon pédagogue et il fait des efforts de simplification dans sa vidéo. Mais la réalité, même simplifiée, est encore trop dure à appréhender pour des enfants.

Donc on leur ment.

Est-ce une mauvaise chose ? Je ne pense pas. Le mensonge n’est pas trop éloigné de la réalité et leur permet de se familiariser avec le concept pour l’approfondir ensuite.

Donner des exemples

Nos profs nous l’ont rappelé à tous quand on apprenait à disserter à l’école. Tout ce qu’on avançait devait être illustré d’un exemple.

À l’époque c’était, certes, parce que l’exemple apportait un premier élément de preuve, mais aussi parce qu’il aidait à se représenter ce qu’on expliquait (lorsqu’il était bien choisi).

C’est également vrai lorsqu’on explique un métier. Donner un exemple concret d’une tâche ou d’un projet qu’on a mené à bien aide toujours.

Raconter une histoire

Expliquer un métier se fait à deux. L’explication sera d’autant plus simple que l’interlocuteur comprend vite.

Or, toutes choses égales par ailleurs, l’interlocuteur comprendra plus vite s’il est concentré plutôt que s’il ne l’est pas.

On en vient à mon point : un bon moyen de capter l’attention d’une personne et de le maintenir concentrée est de lui raconter une histoire.

Donc raconter une histoire, indirectement, simplifie les explications.

Un outil très puissant à utiliser le plus souvent possible

Imaginez essayer d’expliquer la théorie de la relativité générale à une assemblée de profanes.

Pour y parvenir, ce serait une erreur de sortir de grandes équations rébarbatives (et c’est pourtant ce que feront la plupart des gens qui comprennent un peu de quoi il retourne).

Mais il existe une méthode bien meilleure qui, en peu de mots, permet à n’importe qui de se saisir du sujet dans les grandes lignes. Cette image :

Une nappe tendue sur laquelle on a posé des billes plus ou moins lourdes.

Le voilà l’outil le plus puissant pour venir à bout d’une explication compliquée : l’analogie.

Elle ramène l’auditoire dans un cadre de pensée familier. Il suffit d’y projeter les concepts qui leur sont inconnus sur des objets qu’ils ont l’habitude de manipuler. Et ce sont ces objets qu’on fera danser dans les explications, pas les vrais concepts.

Expliquer le growth engineering

Le moment d’expliquer le growth engineering est arrivé. C’est le fruit de nombreux essais, principalement à l’oral, avec des personnes très différentes.

Je le fais souvent de la même manière :

  1. J’explique ce que je fais en une phrase

  2. J’étaye d’un exemple (personnel ou non) pour les curieux

  3. Et, s’il faut, je rentre carrément dans la théorie pour les encore plus curieux

En une phrase

Je code et j’automatise pour les équipes marketing.

C’est la mise en œuvre de mon premier conseil (mieux vaut des explications trop simples que pas assez).

Après, si je suis parfaitement honnête, mon explication lacunaire s’ensuit généralement d’un : “mais, concrètement, tu fais quoi ?”

Et dans 95% des cas, je ferais mieux de m’arrêter là et de ne pas m’expliquer davantage car les gens en savent suffisamment pour comprendre, et suffisamment peu pour qu’une espèce de mystère puisse planer (une situation souvent souhaitable).

Dans le cas où je suis contraint d’en dire plus néanmoins, je raconte une anecdote.

L’anecdote AirBnB

Au début, en 2008, personne ne connaissait AirBnb. Il fallait absolument qu’ils trouvent de premiers utilisateurs et fassent croître la market place.

Alors les growths de l’équipe se sont mis à réfléchir.

Ils ont constaté qu’il existait déjà Craigslist pour poster des annonces en tout genre, y compris pour des appartements. Ils savaient également que Craiglist générait beaucoup de trafic.

C’est là qu’ils se sont dits que ce serait une bonne idée que toutes les annonces publiées sur AirBnb le soient aussi sur Craigslist. Non seulement elles seraient plus visibles, mais, en plus, une partie de l’énorme trafic de Craiglist serait redirigé vers AirBnb.

Alors, ils ont créé un bouton pour que les utilisateurs puissent publier leurs annonces sur AirBnb et sur Craigslist simultanément.

Évidemment, ça a très bien marché et le nombre d’utilisateurs d’AirBnB a beaucoup augmenté.

On appelle les growth à l’initiative de ce genre d’expériences des growth engineers, car créer le bouton de multi-publication a demandé des compétences techniques (coder, en l’occurrence).

Fin de l’anecdote. J’ai utilisé plusieurs des conseils du dessus :

  1. J’ai simplifié, car il ne s’agit pas juste de “créer un bouton”

  2. J’ai donné un exemple — celui d’AirBnB

  3. J’ai raconté une histoire avec un très cliché “Au début, en 2008” (aka “Il était une fois”)

Malgré tout, mes interlocuteurs me disent parfois :

“Ok, chouette. Mais toi tu ne bosses pas chez AirBnbB donc tu fais quoi ?”

Et là je n’ai plus le choix, je dois rentrer un peu plus dans les détails.

Méthode scientifique et exemples perso

En fait, le travail du growth consiste à appliquer la méthode expérimentale à la croissance d’une entreprise :

  • émettre une hypothèse une hypothèse de croissance

  • élaborer un protocole pour la vérifier

  • réaliser le protocole

  • regarder ce que dit la data

  • conclure : “est-ce que ce qu’on a fait a permis à l’entreprise de croître ?

Le truc, c’est que, dans la tech et les startups, il arrive que les expériences à réaliser soient techniques et complexes.

Un simple growth ne suffit plus : il faut un growth engineer i.e un growth avec des compétences techniques avancées (quelqu’un qui sache coder, automatiser, configurer, etc.).

Comme je te le disais, c’est ce que je fais et voici quelques-uns de mes projets passés :

  • Une entreprise qui vendait une solution de cybersécurité voulait savoir quand des personnes venaient d’être embauchées à des postes de cybersécurité justement. C’était le signe qu’elles pourraient peut-être leur vendre leur solution et croître. Je les y ai aidés.

  • Une entreprise voulait envoyer des mails à ses anciens clients pour leur vendre de nouveaux produits. Ça allait vraiment aider leur croissance. Pour y parvenir, il a fallu remettre beaucoup d’ordre dans leur base de données clients. Je les y ai aidés.

  • Une entreprise voulait savoir lorsque ses prospects revenaient visiter leur site. Ça signifiait qu’ils étaient chauds et qu’avec un peu d’aide des commerciaux, on pouvait facilement les transformer en client. Il suffisait de détecter les retours sur le site. Je les y ai aidés.

  • Une entreprise qui vendait une solution d’hébergement de vidéos voulait développer une solution pour permettre en plus d’enregistrer lesdites vidéos. Ça leur permettrait de convaincre leurs prospects d’utiliser la solution d’hébergement. Avec un ami, je les y ai aidés.

Les deux dernières expériences ont été couronnées de succès, la première, pas vraiment 🌝

Cette fois, j’ai utilisé trois autres de mes conseils :

  1. Encore une fois, j’ai donné des exemples (les 3 missions que j’ai réalisées)

  2. J’ai simplifié, notamment la teneur des missions

  3. J’ai utilisé une analogie, celle de la méthode scientifique qui est en fait au cœur de la définition du growth (ce n’est pas moi qui l’invente). On dresse ainsi le parallèle entre growth engineer et scientifique.

Si après cette troisième explication, ce n’est toujours pas clair, ou si mon interlocuteur veut toujours en savoir plus → freestyle.

TL;DR

  • Expliquer le growth engineering est important :

    • pour moi parce que je suis infoutu d’expliquer clairement ce que je fais

    • pour vous lecteurs qui vous trouverez peut-être une nouvelle vocation

    • pour les entreprises qui doivent savoir qu’il existe des profils techniques en marketing

  • 5 conseils pour expliquer un métier technique :

    • Faire trop simple, plutôt que pas assez

    • Mentir et déformer la réalité s’il le faut

    • Donner des exemples

    • Raconter une histoire

    • Utiliser des métaphores et des analogies

  • Expliquer le growth engineering :

    • Il s’agit de coder/automatiser pour les équipes marketing

    • Raconter l’anecdote d’AirBnB et du multi-posting sur Craigslist

    • Le growth est l’application de la méthode scientifique à la croissance d’une entreprise. Quand l’expérience à réaliser est très technique, on la confie à un growth engineer.

    • Saupoudrer le tout d’exemples de projets personnels.

  • Pas besoin d’utiliser toutes les techniques. Par exemple, pour expliquer le growth engineering, il me semble inutile de mentir.

À plus 🖖 

Reply

or to participate.