.avif)
Osman Sheikhnureldin est le responsable de l’ingénierie GTM chez Clay, ce qui fait de lui la personne qui dirige l’ingénierie GTM dans l’entreprise qui en a fait un titre de poste. En interne, on l’appelle l’ingénieur des ingénieurs GTM. Avant Clay, il a passé des années comme opérateur de croissance dans des startups comme Virtru et Shelf. Chez Rippling, son dernier poste avant de nous rejoindre, il a utilisé Clay pour tester une machine d’envoi à froid qui expédiait 200 000 courriels chaque semaine. Au tout début de Clay, il a poussé le produit au point de le casser deux fois, ce qui a convaincu notre co‑fondateur, Varun, de l’inviter à bord.
Certains pensent que GTM Engineering se résume à du Outbound, mais Osman voit cela comme une petite partie du travail. Le vrai défi, c’est d’identifier ce qui freine la croissance d’une entreprise, puis d’éliminer ces obstacles grâce à l’automatisation et à de meilleures données, plutôt qu’en augmentant les effectifs. Osman nous a présenté les GTM Play qu’il a mis en place chez Shelf et Rippling, la façon dont son équipe repère les goulets d’étranglement chez Clay, et pourquoi ils créent leurs propres outils DIY avant que le produit ne les rattrape.
Top 1 % est notre série qui explore en profondeur les opérateurs qui transforment le go‑to‑market. Regardez la version vidéo avec Osman Sheikhnureldin et inscrivez‑vous aux prochains livestreams pour découvrir les épisodes avec des experts GTM de sociétés comme Brex et Depthfirst.
Un·e ingénieur·e GTM en devenir
La carrière d’Osman a commencé, comme il faut, par un e‑mail à froid. Au lycée, en première, il lisait Hacker News et TechCrunch, fasciné par ceux qui transforment leurs idées en entreprises. Il a contacté le fondateur d’une petite startup de gestion de conférences en Virginie et a rejoint l’équipe comme développeur Rails.
Mais presque personne n’utilisait le produit. Osman est passé du développement logiciel au SEO et au marketing pour attirer plus de clients. Il s’est vite passionné pour la croissance et la boucle de rétroaction qui transforme le trafic en essais, puis en clients. Ensuite, il a rejoint une startup plus mature, où il s’est spécialisé dans l’optimisation du taux de conversion, en influençant différents moments du parcours client pour augmenter le chiffre d’affaires.
Quelques années plus tard, il a rejoint Shelf, une startup de gestion de connaissances en série B. C’est là qu’il a découvert Clay pour la première fois. Le cold Outbound de Shelf ne donnait pas de bons résultats, alors l’entreprise a fait appel à Jordan Crawford, qui dirige l’agence GTM Blueprint. « Je pense que Jordan est l’une des personnes les plus intelligentes de l’écosystème Clay », déclare Osman.
Jordan a utilisé Clay pour identifier des entreprises dont les avis signalaient que les clients recevaient de mauvaises informations, le problème exact que Shelf résout. Cela dépasse de plusieurs niveaux le ciblage ICP basé sur les personas auquel Osman était habitué, et il a tout de suite apprécié la puissance de Clay.
Une GTM Play sur Shelf : transformer les mauvais avis en liste de prospects
La gestion des connaissances prête à l’emploi, donc ses meilleurs Prospect sont les entreprises dont les clients reçoivent sans cesse de mauvaises réponses. Par exemple, une compagnie aérienne dont les avis dénoncent que les agents téléphoniques donnent des frais de bagage différents de ceux affichés sur le site. Jordan a utilisé Clay pour analyser les avis publics à la recherche de plaintes sur des informations erronées ou incohérentes, a classé ces entreprises dans une liste et a rédigé des Outbound qui reprennent les mots mêmes des évaluateurs.
Faire des tests sur la machine Outbound de Rippling
Après ses premières expériences en startup, Osman a rejoint Rippling. Leur approche Outbound consistait à envoyer plus de 200 000 e‑mails à froid chaque semaine. Peu d’entreprises adoptent une telle rigueur scientifique, et la culture de mesure de Rippling est restée avec Osman ; elle influence encore aujourd’hui la façon dont il pilote les choses chez Clay.
Son mandat à l’époque était d’offrir des outils en libre-service et de permettre l’expérimentation pour l’équipe growth. Mais l’ingénierie fonctionnait en sprints de deux semaines, et les petites idées de campagne non testées perdaient naturellement les batailles de priorisation face aux travaux d’infrastructure. Clay est devenu son contournement. Parce que la plateforme se branche sur les systèmes déjà utilisés par l’entreprise, Osman pouvait modifier one élément de la machine de Rippling sans demander à quiconque de la reconstruire.
L’expérience dont Osman se souvient le mieux était une campagne de cartes‑cadeaux restaurant pour les travailleurs à distance. La mettre en place avec la stack habituelle de Rippling aurait nécessité que les ingénieurs créent de nouveaux Pipeline et du code sur‑mesure, puis intègrent un service externe pour répertorier les restaurants. Cela représente un ou deux sprints d’ingénierie. Avec Clay, tout s’est assemblé beaucoup plus rapidement, en une seule table.
GTM Play chez Rippling : une carte‑cadeau DoorDash pour les télétravailleurs
Lorsque les bureaux ont rouvert pendant la pandémie de COVID‑19, l’équipe a ciblé les personnes qui travaillaient à domicile, loin du siège de leur entreprise. L’e‑mail proposait une carte‑cadeau DoorDash et citait un vrai restaurant près du Prospect plutôt que de pousser quelque chose de générique. Pour réussir, il fallait connaître la ville de la personne, les sites des bureaux de l’entreprise, vérifier qu’elle habitait trop loin pour faire le trajet, et identifier un restaurant local à mentionner.
De l'utilisateur avancé de Clay à responsable de GTM Engineering
Le parcours d’Osman pour rejoindre Clay a commencé par le faire tomber. À l’époque, les tables plafonnaient à 50 000 lignes ; à l’échelle de Rippling, cela impliquait de les nettoyer manuellement pour que tout fonctionne. Il a découvert les API internes du produit et les a utilisées pour supprimer les lignes en masse. Il y a environ trois ans, alors que Clay était encore à ses débuts, une expérience a accidentellement mis tout le produit hors service. Cela a déclenché une discussion avec Varun, qui s’est terminée par son Lead de notre équipe d’ingénierie GTM.
Son équipe arrive toujours en tête des classements d’usage chaque année dans Clayback, notre récapitulatif façon Spotify Wrapped. Elle teste tout en interne et prend de l’avance sur le produit principal, en laissant de la place pour échouer et créer des choses qui ne seront pas forcément évolutives. Ce qu’elle apprend guide ce qui est livré aux autres équipes.
Ce qu’ils font actuellement se répartit en deux axes :
- Le premier, ce sont les outils pour les commerciaux, construits autour de Terra, l’application interne que l’équipe a développée pour les vendeurs de Clay. Clay dispose maintenant d’un MCP, une connexion qui permet aux outils d’IA d’extraire directement les réponses de vos données Clay. L’équipe intègre cela à Terra, afin que les commerciaux puissent poser des questions sur leurs comptes et obtenir des réponses sans quitter l’application.
- Le second est les boucles de rétroaction fermées. Quand l'IA rédige les Outbound, Osman veut que le système apprenne de chaque e‑mail, identifie ce qui booste les taux de réponses et de prises de rendez‑vous, et intègre ces enseignements dans les prompts et le contexte du workflow. Le même principe s’applique à tout ce qu’ils créent : on trace l’événement et le résultat, puis on boucle l’information pour que le système s’améliore en continu.
Le cadre d’Osman pour choisir ce qu’on construit
Osman a rejoint Clay en sachant que son équipe pouvait accomplir beaucoup et en cherchant un moyen de décider immédiatement quoi faire. Sa réponse commence par throughput, c’est‑à‑dire le nombre de Lead qui traversent réellement l’entonnoir, pas ceux qui y entrent. Le volume que son équipe peut réellement faire bouger dépend de la façon dont les Lead circulent dans l’entonnoir et où ils se perdent, par exemple un formulaire trop long ou un suivi envoyé trop tard.
Identifier ces points de décrochage se résume à trois habitudes :
- Cartographiez le système. Il a tracé chaque étape, du début à la fin, qu’elle soit humaine ou automatisée, pour identifier ce qui fait réellement avancer le travail.
- Suivez les personnes à l’intérieur. Osman a discuté avec les représentants et les a observés travailler. La friction apparaît dans les étapes que les gens trouvent difficiles et dans les tâches manuelles qui leur font perdre du temps.
- Vérifie les données. Il a combiné ce que les gens lui ont dit avec sa propre analyse, car les chiffres montrent où les Lead s’accumulent ou s’échappent discrètement.
Une fois les goulets d’étranglement identifiés, un filtre détermine ce qui doit être construit en premier : problèmes composés.
Ce sont des problèmes intégrés au système, où une seule correction aide plusieurs parties de l’entonnoir en même temps. Un exemple : la façon dont nous segmentons et notons les Lead et les Compte. La segmentation donne à chacun dans l’entonnoir un cadre commun pour le ciblage et le message, et elle indique aussi quels Compte comptent le plus. Avant de pouvoir attribuer un Score, Osman devait d’abord identifier ce qui distingue un Compte excellent d’un Compte moyen ; il a résolu cela avec un exercice simple dans Clay.
Une action GTM Play chez Clay : profilez vos meilleurs clients pour en dénicher de nouveaux.
Osman a consulté un tableau Clay de nos meilleurs clients par ARR et a enrichi leurs données, en vérifiant la répartition des effectifs par fonction et la stack technologique. L’échantillon de comptes à six chiffres était trop petit pour être statistiquement significatif, alors l’équipe s’est appuyée sur des tendances. L’une d’elles était claire : vos meilleurs clients ont généralement au moins 10 % de leurs effectifs dans les ventes ou le GTM en général. Le recrutement est une décision très réfléchie, donc un dixième de l’effectif dédié aux ventes montre qu’une entreprise mise sur le GTM, exactement le pari que Clay soutient.
Construire des flux de travail et des produits conçus autour des équipes commerciales
Les équipes en contact avec les clients ont traditionnellement considéré les RevOps comme des gardiens des données et des processus. L’équipe d’Osman s’efforce de ne pas être perçue ainsi. Les personnes qui dialoguent avec les clients toute la journée sont créatives et savent souvent construire, donc le rôle consiste à les outiller plutôt qu’à les freiner.
Cependant, il choisit les retours à prendre en compte selon deux règles simples :
- Ne priorisez jamais sur la base d’une seule personne, car une demande isolée n’est pas une tendance.
- Parallèlement, certaines personnes sont des cas atypiques dont la méthode de travail est très efficace. Parfois, il vaut mieux amplifier ce qu’elles font plutôt que de le réduire.
C’est cette réflexion qui a poussé l’équipe à créer son interface représentant, et qui rend Osman enthousiaste à propos de MCP in Clay, qui fonctionne sur Audience où les données Snowflake et Salesforce se rejoignent. Les représentants peuvent exploiter ces données sélectionnées, y ajouter de l’Enrichissement ou leurs propres recherches IA, puis envoyer un e‑mail.
Construire des MVP bricolés pour l’équipe GTM
L’équipe produit de Clay échange en permanence avec les clients, et quand une fonctionnalité est mise en ligne, elle a déjà été testée en conditions réelles avec des bêta‑clients. En interne, l’équipe d’Osman est le client zéro. Mais parfois, ils n’attendent même pas le produit final. Créer d’abord une version bricolée a du sens pour plusieurs raisons :
- GTM n’attend pas. L’équipe poursuit des objectifs de pipeline ambitieux et recrute de nouveaux vendeurs chaque trimestre, donc manquer un cycle complet de lancement de produit n’est pas une option.
- Hacky suffit. Une version interne n’a besoin de prendre en charge que les flux de travail de l’équipe, pas tous les utilisateurs de Clay, donc on peut se permettre quelques raccourcis sans grande conséquence.
- La rapidité vient de l’indépendance. Construire hors de l’infrastructure principale élimine les sprints et les luttes de priorisation ; on peut attendre de scaler jusqu’à ce que l’idée soit réellement validée.
Le meilleur exemple, ce sont les agents de compte, aujourd’hui chez Clay, dont le précurseur Osman a intégré dans l’interface rep pendant les fêtes de Noël. Il s’attaquait à un problème que chaque vendeur connaît : le contexte nécessaire à votre travail est éparpillé dans différents systèmes.
- Les enregistrements d’appels se trouvent dans un seul outil.
- Les données CRM se trouvent ailleurs.
- Les conversations s’accumulent dans Slack
- Les données produit résident dans Snowflake
- Les recherches ad hoc se perdent dans les fils Claude et ChatGPT.
Sa réponse était un concept appelé « account state », un projet technique qui a condensé tout ce contexte en un seul objet JSON, contenant tout ce qu’il faut savoir, que vous soyez en phase de Prospect ou de renouvellement. Les agents ont passé les données au peigne fin pour créer le profil de chaque Compte, ses Signal, ses risques et les personnes clés, et l’équipe s’en est servie en interne pendant plusieurs mois.
L’équipe produit les rencontrait une à deux fois par semaine pendant le développement de la vraie fonctionnalité, pour recueillir les retours sur la version interne. Cette collaboration a donné l’une des meilleures fonctionnalités des agents de compte.
Les gens appréciaient la version interne, mais se demandaient comment être sûrs que l’information était fiable et non inventée, et l’équipe d’Osman a relayé cette préoccupation. Ainsi, les agents de Compte citent leurs sources, en indiquant si un point de donnée provient d’un enregistrement d’appel ou d’un champ Salesforce.
La CLI, et faire en sorte que le GTM ressemble à de l’ingénierie logicielle
Osman mise sur le CLI et développe sur Clay avec n’importe quel agent de codage. La première raison : la vitesse, car on crée de nouveaux workflows en tapant et en lançant des prompts, sans passer par une interface. La deuxième : l’impact sur une équipe qui grandit.
Osman veut que les connaissances de l’équipe soient codées, pas simplement transmises de bouche à oreille. C’est pourquoi ils tiennent un dépôt partagé de compétences et d’outils accessible à tous. Il souhaite que les nouvelles recrues n’aient plus à fouiller dans Slack ; elles ouvrent le dépôt, voient ce qui a été construit, comprennent les décisions prises, et retrouvent chaque compétence et workflow versionnés au fil du temps.
« Cela nous aide à faire un pas de plus pour que le GTM ressemble davantage à de l’ingénierie logicielle », déclare Osman.
.png)
.avif)
.avif)
.avif)
