Créer un produit à succès : Talentsoft, Alexandre Pachulski l'a fait

  • mise à jour : 31 janvier 2019
  • 9 minutes
Article écrit par

Si vous suivez l’actualité tech, vous avez sûrement vu passer récemment des articles sur Alexandre Pachulski et Talentsoft. L’entreprise vient de lever 45 millions et apparaît partout sur le web (ça, ce n’était pas prévu avant l’interview !). Et Alexandre a sorti en octobre son dernier livre Unique(s), abordé dans un bel article ici . Et pourtant, ce ne sont pas ces sujets qui ont aiguisé ma curiosité, et j’annonce d’entrée de jeu que je vais me concentrer sur son Produit. “Depuis le début de Talentsoft, je m’occupe du Produit, donc ça tombe bien”, me rétorque-t-il avec un sourire. Aujourd’hui, Talentsoft, c’est 10 millions d’utilisateurs, 1800 clients, 600 collaborateurs dans plus de 130 pays et en 27 langues. Une paille.

Talentsoft est né en 2007 : 12 ans, à l’échelle de l’écosystème tech, c’est long ! Le Produit a toujours été au coeur de la vision de l’entreprise. Alors, première question toute simple, comment décrirais-tu ton Produit ?

Je peux te répondre à deux niveaux. Un premier niveau, descriptif : Talentsoft est une suite de logiciels intégrée de gestion des talents. Reportons-nous en 2007. Il n’y a aucune intégration des processus RH dans la réalité, et a fortiori dans un outil ! Le recrutement, la formation, la paye, l’évaluation, la revue de salaire : tout est donc géré en silos imperméables.

Donc tu recrutes des stars, mais la manière dont elles sont managées n’est pas ton problème. Tu proposes une formation, mais tu ne sais pas quel impact elle aura sur la promotion, et ainsi de suite.

Je venais du monde du conseil en Ressources Humaines où j’avais accompagné une centaine de clients : Apple, EDF, Gemalto. Et j’avais bien vu que les différentes équipes RH ne travaillaient pas ensemble, que l’expérience des collaborateurs était complètement saucissonnée, qu’il n’y avait pas de big picture.

Mon idée de départ était que le collaborateur devait être acteur de sa carrière et placé au centre de l’outil qu’on voulait créer. Les ressources humaines mettaient en place des processus hyper compliqués, nourris du modèle tayloriste et de notre amour bien français de la centralisation, pour savoir ce que les gens voulaient alors qu’il suffisait simplement... de leur demander.

Mon idée de départ était que le collaborateur devait être acteur de sa carrière et placé au centre de l’outil qu’on voulait créer.

La notion “d’expérience collaborateur” est née dans un second temps de l’histoire de Talentsoft. Ou plutôt, elle a été formulée comme telle dans un second temps, il y a 5 ans, lors de l’essor de l’UX. Nous avons alors beaucoup travaillé le design de l’expérience collaborateur dans le Produit.

Regarde mon talk au Hub Institute, le message central repose sur l’idée que l’unique job des RH est de savoir pourquoi les gens viennent le matin. Et au fur et à mesure de mes recherches, de mes articles de blog, de mes livres, j’ai affiné mon approche et le centre de gravité s’est naturellement déplacé du pain que j’avais identifié chez les RH, à l’entreprise, et au travail. Ma vision, c’est que Talentsoft est une plateforme d’empowerment, on donne ainsi les moyens aux individus de changer les conditions de leur travail et de mettre fin à la gestion morcelée de leurs carrières.

Talentsoft est une plateforme d’empowerment, on donne les moyens aux individus de changer les conditions de leur travail et de mettre fin à la gestion morcelée de leurs carrières.

Donc notre Produit parle à 10M utilisateurs et non à 1800 clients. On est dans du B2C et non du B2B. On s’adresse à nos utilisateurs et non aux RH.

Ce qui m’intéressait dans l’informatique, quand j’ai fait mon doctorat, c’était la possibilité de changer la vie des gens. Lors de la naissance de Facebook, de Linkedin, de Myspace, j’ai tout de suite compris la puissance de l’empowerment. C’est la révolution des amateurs professionnels dont parle Charles Leadbeater. J’ai compris que ce qui se passait en dehors de l’entreprise allait aussi se passer à l’intérieur.

Quand tu lances Talentsoft, le Product Management tel qu’on le connait aujourd’hui était une discipline absente du paysage français. Comment as-tu construit ton produit ?

D’abord, il faut avouer que j’ai clairement perdu du temps. Je n’avais pas toutes les bonnes pratiques dont disposent aujourd’hui les Product Managers. Alors, comme Luc Besson dit qu’il crée les films qu’il veut voir, j’ai créé l’outil dont j’aurais eu besoin, moi, en tant que consultant.

L’avantage compétitif que j’avais, c’était de savoir parler deux langages : le langage des RH et le langage de la tech. A l’époque, c’étaient les développeurs qui faisaient le produit, ce qui amenait parfois des remarques comme “on voit que c’est fait par des ingénieurs”. Ce que cette phrase veut simplement dire c’est qu’il y avait un manque d’empathie pour le pain client. Or moi, j’avais vécu ce pain et j’avais un doctorat informatique qui, même s’il datait un peu, me permettait donc de parler avec les équipes techniques. On sortait de la tour de Babel. Le Product Management, c’est de la traduction.

Aujourd’hui, on peut identifier deux grands types de product managers :

  • ceux qui sont très tournés client, qui connaissent le métier et le besoin du client, et essaient au mieux de l’exprimer à la R&D. Ils sont doués pour animer des communautés, viennent pour certains du marketing et sont tournés vers l’extérieur.
  • ceux qui sont devenus tout de suite PM et se sont spécialisés dans la capacité à faire des US, des epics, qui sont plus geeks et tournés vers les développeurs. Ils sont alors tournés vers l’intérieur.

Les bons product managers sont les deux à la fois. Il leur faut un rayonnement externe et interne. Et sur de l’externe, haut niveau, il y a les Product Strategists.

36812754_426137447867219_1074432231402897408_o-1024x768

Alexandre (tout à droite) et son équipe

Quels sont les principaux challenges que tu as dû relever ? As-tu changé de produit ou pivoté ?

Nous n’avons pas pivoté en tant que tel. En 2013, on a compris le passage du SaaS (Software as a Service) au PaaS (Platform as a Service), et on a donc choisi d’encapsuler ce que les autres faisaient, en rachetant des produits mais uniquement des produits intégrables à notre solution. Ce n’est pas un pivot, mais c’est une prise de décision stratégique forte.

Le socle de départ, c’est le trio : recrutement, évaluation, formation.

Après, nous avons intégré la revue de talent, puis la revue de salaire.

Le premier challenge en 2007, c’est de trouver notre blue ocean et d’être audible alors que le produit n’existe pas. Quand on a créé Talentsoft, il y avait deux boîtes de logiciels RH américains au Nasdaq. Si tu es petit et que tu essaies de faire comme un gros, ça ne marche jamais. Pour un PM, il est impossible de faire des “me too” ou des catch-ups.

Ce qu’il faut avoir en tête quand tu lances ton Produit, c’est qu’il faut commencer par une histoire. D'abord, tu racontes une histoire au marché (c’est la vision) et ensuite, tu bâtis ton produit, et non l’inverse. C’est une erreur fréquente ! Le PM doit s’inscrire dans un temps long. Bâtir un mur, construire l’étage d’une maison ou concevoir une cathédrale, c’est très différent. Le PM doit ainsi avoir un plan à long terme, 2 ans, 10 ans pour créer son produit.

Ainsi, notre histoire, c’était celle de “l’empowerment” : les collaborateurs deviennent acteur de leur carrière. Pour ça, il faut qu'ils construisent un projet professionnel. Quand nous avons créé Talentsoft, nous avons embarqué cette notion de projet professionnel. A l’époque, les ressources humaines n'intervenaient qu'à certaines étapes (recrutement, choix de formations) que le collaborateur "subissait". Le concept de "projet professionnel" conçu par l'employé sur plusieurs années était alors étranger au monde RH, mais aujourd'hui il paraît naturel à tout le monde !

Notre histoire, c’était celle de “l’empowerment” : les collaborateurs deviennent acteur de leur carrière.

Le 2e challenge, quand l’entreprise grandit, c’est de s’en tenir à son histoire tout en étant flexible pour écouter les clients ; suffisamment répondre à leurs besoins pour signer des deals, en tenant le cap. Exemple dans lequel de nombreux lecteurs se reconnaîtront : on veut signer des SSII, et elles nous entraînent vers des fonctionnalités de staffing qui ne sont pas prévues dans le produit. Nous avons énormément de demandes car les SSII sont très nombreuses en France. Le point de convergence avec notre vision était la gestion par projet. Nos fonctionnalités de recrutement pouvaient être adaptées à du staffing. Par contre, la gestion de la facturation n’avait rien à voir avec notre histoire et nous avons donc refusé.

Enfin, le 3e challenge, quand ton entreprise connaît le succès, c’est que la somme des demandes clients est largement supérieure à tes capacités, même quand tu as 600 collaborateurs comme nous. Là, ce n’est plus une question de savoir refuser intuitu personae, c’est un problème de volume. Plus ça va, plus tu rentres dans cet entonnoir où tu dois comprendre les événements clés du film. Il faut couper au montage. Revenir à l’essentiel. Pour un Product Manager, c’est bon de ne pas vivre dans le luxe. L‘innovation frugale, c’est merveilleux.

Un fail qui t’a permis d’apprendre ?

Les fails relèvent souvent du même problème : on tombe amoureux de son produit. J’ai dit plus haut que le Product Management se rapproche de la traduction. Et être amoureux de son Produit n’aide pas à interpréter les messages de façon clairvoyante. C’est tellement facile de perdre le fil entre un vrai pain client (dont la formulation est déjà une traduction de ce qu’il vit), la compréhension que tu en as (2e traduction), ce que tu rapportes à tes équipes (3e traduction) et le produit créé. J’ai vécu plusieurs fails de ce type.

J’étais très fier d’une nouvelle fonctionnalité et j’avais complètement tapé à côté du vrai besoin. J’avais embarqué tout le monde dans une fausse voie, c’est très douloureux. Ainsi, nous avions ajouté un calendrier regroupant tous les events RH saisis dans l’application (les entretiens d’évaluation, les sessions de formation, etc). Avoir un calendrier, tout le monde nous l’avait demandé… et personne ne l’utilisait. Parce qu’en réalité, le problème était pour les équipes de vérifier les conflits avec les rendez-vous business, et non entre les rendez-vous RH entre eux. Nous n’avons pas suffisamment vérifié que l’expression du problème client correspondait à la situation vécue.

Dans un cas similaire, il n’y a, à mes yeux, qu’une seule bonne réponse, c’est d’aller voir le client, d’être transparent par rapport au problème et de lui expliquer tout de suite ce que vous pensez faire pour trouver une solution. Il ne faut pas essayer de noyer le poisson ou de se cacher : “Désolé, je me suis planté, on vient de perdre des mois mais on va recommencer.” Et honnêtement, les clients ne sont pas idiots, ils comprennent. Pour le cas des calendriers, nous avons développé les intégrations dans outlook, gmail et icalendar. Et là, nous avons répondu au bon problème.

Comment as-tu construit les équipes Produit dans le temps ?

Au départ, j’étais seul, puis une personne m’a rejoint, puis quatre qui irriguaient toute la toute la R&D. Nous avons peu à peu scalé jusqu’à avoir un PM par ligne Produit, nous avons alors créé le job de business analyst, puis UX. Il y a trois ans nous avons basculé notre organisation en programmes. Nous avons une soixantaine de personnes au Produit réparties sur 6 programmes : une trentaine de Product Managers, des Business Analysts, des Product Owners, des Product Marketing Managers et des Growth Hackers, ces derniers utilisant des techniques de growth hacking B2C auprès de nos utilisateurs. J’insiste, on s’adresse à nos 10 millions d’utilisateurs et non à nos 1800 clients. Dans chaque programme, il y a plusieurs squads avec un PM par squad.

Depuis le premier jour, nous avons mis en place des practices, car j’avais étudié le cas de Microsoft de près et je voulais anticiper le risque de silos. C’est le modèle prôné par Marty Cagan, des practices transversales avec une culture, des droits et devoirs. Par exemple, sur chaque programme, il doit y avoir 3 à 15 touchpoints clients par semaine. C’est inhérent au job de PM, sinon, ils s’éloignent des clients et là, c’est la catastrophe.

Quels ont été tes mentors ou role models ?

Je dirais Jonathan Ive sur le design. C’est grâce à lui que le design est devenu une science.

Parmi les entrepreneurs, Marc Benioff, PDG de Salesforce, et son CPO Alex Dayon, m’ont beaucoup inspiré sur leur capacité à donner une vision. Il faut lire leurs biographies, elles sont fantastiques. Richard Branson est un modèle car il montre qu’il faut tenter des choses impossibles par passion.

Et au-delà du monde business, je dirais que mes role models sont issus du monde artistique. Bruce Springsteen donne de magistrales leçons de management de talents, par exemple. Il ne s’est pas entouré de stars, mais de gens qui, au contact des autres, se dépassent et ensemble arrivent à créer un son unique qui est devenu une référence.

Jerry Seinfeld manie comme personne l’art de l’histoire. Il a écrit des sitcom de 70 pages de scénario, quand les autres en font 25, avec deux ou trois histoires en parallèle, tout en parlant de tout et de rien. Il a totalement renouvelé le genre alors que les sitcoms de la fin des années 80, Santa barbara et les Feux de l’Amour, présentaient une histoire ultra évidente avec des rebondissements surfaits. Lorsqu’il a sorti ses premiers épisodes, tout le monde lui disait : “il n’y a une trame, ça parle de tout et de rien, ça ne va jamais marcher”. Preuve que les gens ne croient pas aux choses avant qu’ils les aient vues. C’est le premier challenge dont je parlais plus haut, raconter ton histoire alors que tu n’as pas encore le produit : on te dira forcément que ça ne va pas marcher.

Tu as écrit Unique(s) qui explique la singularité de nos talents par rapport à la standardisation induite par l’AI. Quels sont les livres et sources que tu recommandes aux Product Managers pour prendre du recul par rapport au monde tech dans lequel ils vivent au quotidien ?

J’en citerais trois. The innovator’s dilemna de Clayton M. Christensen est extrêmement éclairant. Ça m’aurait énormément aidé de le lire avant de lancer Talentsoft. Autre incontournable : Inspired de Marty Cagan. Et The Rainforest: The Secret to Building the Next Silicon Valley de  Victor W. Hwang et Greg Horowitt. Et puis les biographies de tous les entrepreneurs et artistes que j’ai cités durant notre conversation. Elles te transmettent une incroyable énergie.

La newsletter qui produit son effet

cover_pm-1

La newsletter Product Management

Contenus exclusifs, actualités, humeurs, devenez incollables en Produit