Quelques années plus tôt, j’ai travaillé pour une autre entreprise internationale. Nous utilisions des outils produits par des équipes aux US. Je me rappelle encore du lancement d’une nouvelle version d’un de leurs outils sous le nom de code NorthStar. Moi qui étais habitué à des numéros de versions très codifiés, x.y.z où chaque lettre avait une signification particulière, j’ai regardé ça d’un œil suspicieux dans un premier temps.

Et puis je me suis rendu compte que tout le monde parlait du projet NorthStar. Il y avait tout un récit pour expliquer pourquoi il était fait, qu’est-ce qu’il allait apporter. C’était en réalité une superbe opération de promotion, et ça fonctionnait, au-delà des équipes techniques.

Dans le passé j’ai eu du mal avec le fait de promouvoir un projet, de le vendre. Je considérais que le résultat parlait de lui-même. La qualité, l’utilité d’un outil, ou d’une application se voyait, n’avait pas besoin d’être vendu. Au contraire, trop en faire rendait le discours suspect.

Individuellement, beaucoup de techs ont cette manière de penser, n’aiment pas se mettre en avant et considèrent que leurs résultats parlent d’eux-mêmes. La population Dev est par nature sceptique et fait davantage confiance dans les faits logiques et les données, que les beaux slides et les discours.

Et pourtant, loin de rentrer dans la catégorie des publicités mensongères, savoir vendre son travail, c'est aussi une façon d’apporter de la clarté sur les objectifs visés. A qui il s’adresse, quelle est la valeur attendue. Vous ne pouvez pas reprocher aux personnes de ne pas comprendre votre travail si vous n’avez pas fait l’effort d’en parler.

A ce stade de ma carrière je dirais que ce n’est pas un sujet sur lequel je me sens encore très bon et je retravaillerai sans doute cet article à l’avenir. Mais je me devais d’en faire un chapitre ici, car le “tech marketing” est un levier fort pour créer de l’impact dans une organisation.

From startup to scaleup

Sur Malt, en tant que co-fondateur, j’ai connu le passage de 3 à 700 personnes.

Sur une petite équipe, c’était assez évident de voir la valeur du produit et de le comprendre. Le Produit marche ou pas, les utilisateurs s’inscrivent et l’utilisent, ou pas. On ne mesure pas la disponibilité ou la qualité du logiciel. Si l’application n’est pas disponible, tout le monde le voit.

Bref, lorsque nous étions une startup, je ne faisais pas la promotion du produit parce qu’il fonctionnait bien et que cela tombait sous le sens.

Mais sur un produit plus complexe, c'est devenu un vrai sujet, car un certain flou sur l’activité de l’engineering apparaît avec la croissance.

Le flou

C’est un exercice très difficile de faire vieillir un produit, bien plus que de le créer. Chaque décision a des conséquences. Chaque nouvelle fonctionnalité apporte de la complexité. Les contraintes sont de plus en plus fortes avec la croissance, sur la sécurité, la robustesse, l’efficience.
Dire qu’une application est disponible ne veut plus rien dire. Est-ce que le paiement fonctionne ? Est-ce que le moteur de recommandation fonctionne ?

Pour faire face à tout cela, pour faire un produit toujours plus abouti, il faut des équipes larges, mais cela vient avec un coût en termes de communication et de coordination.

Pourquoi c’est si long de construire cette “petite” fonctionnalité ?
Pourquoi a-t-on besoin d’autant de personnes sur l’équipe X, la sécurité, l’ops etc… ?
Je viens de voir qu’on avait construit la feature Y, à quoi ça sert ? Est-ce qu’on travaille vraiment sur les bonnes prios ?
A quoi servent tous les feedbacks qu’on remonte ? Qui travaille là-dessus ?

Vous avez sans doute reconnu quelques-unes de ces phrases. Avec la croissance, vient un certain flou.

Ce flou est préjudiciable à la confiance que l’on porte à l’équipe produit. Qui dit confiance, dit aussi investissement. L’investissement dans le produit se fait si on comprend ce qu’on va y gagner, ou ce qu’on pourrait perdre.

C’est nécessaire pour l’entreprise d’expliquer comment elle dépense son argent, comment elle investit et avec quel résultat. Encore une fois, dans une boite Produit c’est évident qu’il faut une équipe produit. Mais quel est le bon niveau d’investissement ? Pourquoi ne serait-on pas 50% de moins par exemple ?

Et je vous laisse imaginer ce qu’a pu donner l’exemple récent de Twitter qui a fait partir pour près de 80% de son effectif. “Si eux l’ont fait, c’est que ça marche”.

La clarté

Notre rôle en tant que tech leader, c'est d’enlever ce flou, et d’apporter de la clarté. J’aime bien parler “d’extraire le rapport signal bruit”.

Prenons des exemples :

• Parmi tous les chantiers possibles, vous avez choisi de travailler sur les chantiers A et B. Pourquoi ? Comment sont-ils reliés avec la stratégie de l’entreprise ? Il s’agit de mettre en place une culture orientée data.
• Une fois un choix fait, comment faites-vous pour rassembler les bonnes personnes et s’assurer que tout le monde comprenne cette priorité ? C’est, entre-autres, une question de leadership.
• Le chantier réalisé, comment vous assurez-vous qu’il ait de l’impact, qu’il soit utilisé ? Il y a un enjeu de distribution.

Pour orchestrer tout cela, j’aime bien regarder du côté du marketing et notamment du product marketing qui peut grossièrement se résumer en 2 grandes étapes : Discovery, Distribution.

• La discovery, c’est la phase d’exploration pour déterminer ce qu’il faut construire.
• La distribution, c'est les méthodes pour apporter votre produit aux utilisateurs.

C’est exactement ce qui peut nous servir en interne, au sein de l’équipe produit, comme en externe, à travers les autres équipes de l’entreprise, voire au-delà.

Market Research

Le parallèle entre la Discovery technique et le “market research” est assez évident et j’aime bien m’inspirer de ces techniques pour identifier les besoins “utilisateurs”.

Par exemple, le Market Research consiste à étudier le marché via des sondages, des interviews, du shadowing (observation d’utilisateurs) ou de la Data. Ce sont de très bons outils à réutiliser côté tech.

Ces outils ont aussi l’avantage en interne de préparer le “Storytelling”, une autre technique de marketing pour favoriser l’attachement et l’adhésion.

Story Telling et Press Release

Le storytelling nécessite de simplifier le propos, de vulgariser. Tout le monde ne comprend pas la tech, et même au sein d’une équipe large, les enjeux peuvent être complexes à expliquer. Il faut simplifier. Je parlais d’apporter de la clarté, c’est impossible d’apporter de la clarté si les projets lancés ne peuvent être expliqués simplement à des personnes qui ne travaillent pas dessus. La tech doit sortir de sa posture de spécialiste et au contraire être abordable.
J’insiste là-dessus, les grandes initiatives tech doivent pouvoir être expliquées à n’importe qui dans l’entreprise.

Un outil utilisé par le Product Marketing pour s’assurer que tout le monde comprenne l’objectif visé, c’est le “press release”. Une “press release” consiste en début de projet à écrire un texte court, voire un tweet tel qu’il serait écrit au moment de la fin du projet. Il doit être court, compréhensible, impactant. Ce tweet va fixer l’ambition et l’impact attendu pour les x prochains mois.

Product Knowledge et distribution

Si le Market Research et le Storytelling préparent la phase de distribution, le travail est loin d’être fait. On a tous connu des projets très bien réalisés, mais pas utilisés, pas compris, pas trouvés. La distribution, c'est l’ensemble des actions destinées à promouvoir votre produit, l’apporter aux utilisateurs. Ce n'est pas “juste” des Product Tours.

De bonnes méthodes de distribution, c'est ce qui fait que Teams a gagné la bataille contre Slack.

Bref, une bonne distribution, c'est la différence entre un projet “okissh” et un excellent produit.

Rapporté à l’Engineering ceci regroupe tous les mécanismes nécessaires à faire connaître et à comprendre comment utiliser votre produit. Cela inclut : la documentation technique, les portails de développement, les formations, les newsletters, les démos.

Par exemple, pour le projet Singapore présenté plus haut, nous avons totalement revu notre portail de documentation interne et introduit de nombreux guides “Getting started”. Le projet est en cours, mais chaque semaine nous organisons une session d’une heure pour présenter les nouveautés (ou difficultés) et améliorer le portail de documentation. Les personnes du projet Singapore sont en constant support sur les équipes qui en ont besoin.

Outcome, pas output

Enfin dernier point, le Tech Marketing c’est savoir communiquer sur ces réussites, savoir célébrer ce qui a marché et ce que cela a apporté.

Mais il est important dans cette communication d’insister sur les impacts, les résultats, pas uniquement les réalisations. Il faut parler en termes de gain : temps de cycle, revenus financiers, taux de disponibilité etc… La confiance que l’on cherche à construire dans une équipe engineering passe par ces gains, pas par les moyens. Les moyens doivent bien sûr être expliqués, notamment pour être adoptés. La sortie du projet X est nécessairement importante. Mais ce qui crée la confiance dans le temps, ce sont les gains du projet X, pas le fait que le projet X soit sorti.

Questions

Est-ce que vous communiquez sur les modifications d’architecture, les évolutions technologiques de votre produit ?

Diriez-vous que la tech est comprise au sein de l’entreprise ?

Quelle est la dernière fois qu’un projet technologique a été cité dans une communication au sein de votre entreprise ?

Ressources

• Product Marketing
• Press release in product management within Amazon
• Best practices for developer documentation