Comment Fountain a ajouté 10 M$ d'ARR en 12 mois en accélérant ses lancements produit

Fountain est un éditeur américain de logiciels RH fondé en 2015 et soutenu très tôt par Y Combinator. La boîte a d'abord construit un ATS (logiciel de suivi des candidatures) pensé pour les travailleurs de terrain, un segment souvent oublié par les logiciels RH classiques conçus pour les employés de bureau. Avec le temps, Fountain est devenu le système de référence du recrutement en volume dans la logistique, le retail, la restauration et l'économie des petits boulots, au service de boîtes qui doivent recruter des milliers de travailleurs de terrain chaque mois.

En 2022, Fountain comptait environ 200 salariés et avait levé plus de 200 M$ sur plusieurs tours, dont une grosse Série C. Mais la boîte arrivait à un tournant stratégique. Son ATS cœur de produit était solide, mais collant dans le mauvais sens : les clients en changeaient rarement, ce qui rendait l'expansion difficile. En parallèle, la vélocité Produit en interne avait fortement ralenti, à cause de la complexité de l'orga, de la dette technique et d'une culture qui s'était éloignée de l'expérimentation.

Dans ce contexte, Fountain a racheté Clevy, une startup française de chatbot RH cofondée par Salim Jernite. Salim a rejoint Fountain avec une mission claire : retrouver de la vitesse, relancer l'innovation et ouvrir de nouvelles sources de revenus grâce à des lancements produit plus rapides. J'ai rencontré Salim Jernite, Chief Product Officer de Fountain, pour parler de la façon dont il a monté une usine à produits qui a lancé huit produits en 12 mois et ajouté 10 M$ d'ARR.

Disclaimer : les choix d'organisation et les solutions techniques partagés dans cette newsletter ne sont pas faits pour être copiés-collés tels quels. Garde toujours en tête le contexte de ta boîte avant d'adopter quelque chose qui marche ailleurs ! 😊

‍

Créer vite un levier en shippant avant de demander la permission

Quand Salim est arrivé chez Fountain, la boîte avait l'inverse d'une culture du ship. Les roadmaps s'étalaient sur 18 mois, les équipes étaient grosses et lentes, et « on ne peut pas faire ça » était devenu la réponse par défaut. Plutôt que de chercher à changer le système avec des decks d'alignement ou une refonte de l'orga, Salim s'est concentré sur une seule chose : le levier.

Il a repéré deux initiatives à fort impact, demandées en interne depuis des années mais jamais livrées. Au lieu de remonter par le management, il a discrètement réuni une petite équipe et les a construites en sous-marin. L'une de ces features, une traduction en temps réel dans l'interface du produit, a été shippée en trois semaines, sur une codebase que l'équipe ne connaissait même pas.

Le but n'était pas la perfection. C'était la preuve. La preuve que la vitesse était encore possible. La preuve que les clients répondraient. La preuve que livrer permettait de passer les résistances internes plus vite que n'importe quel débat.

Une fois la feature en ligne, la dynamique interne a changé du jour au lendemain. Les équipes Sales l'adoraient, le customer success la poussait, et le CEO avait une preuve concrète que la vélocité Produit pouvait revenir. Dire non coûtait désormais plus cher que soutenir l'équipe.

Salim a ensuite résumé cette approche très simplement :

« On n'a pas demandé la permission. On a shippé, et une fois que ça a marché, plus personne ne pouvait discuter », Salim Jernite

Cette première victoire ne portait pas sur le revenu. Elle portait sur la crédibilité. En shippant d'abord et en expliquant ensuite, Salim a créé le levier politique et organisationnel nécessaire pour voir plus grand. Il a obtenu un accès direct au CEO, moins d'interférences du middle management, et la possibilité de proposer une transformation bien plus ambitieuse.

‍

Faire de l'innovation une usine à produits reproductible

Après avoir prouvé que la vitesse était possible, Salim a proposé quelque chose de radical : arrêter de traiter les lancements produit comme des projets ponctuels et commencer à les traiter comme un process industriel. Plutôt que de tout miser sur une seule roadmap, il a conçu un modèle d'usine capable de produire de nouveaux produits en continu.

Au cœur de ce modèle, un cycle de vie strict de neuf mois. Chaque produit suivait la même structure : trois mois de discovery, trois mois de bêta et trois mois pour atteindre la disponibilité générale. Chaque trimestre, un nouveau produit entrait en discovery. Chaque trimestre, un autre produit arrivait au lancement. Ça créait un pipeline où plusieurs produits avançaient toujours en même temps, à des stades différents.

La discovery était menée par le design, pas par l'engineering. Les designers passaient des semaines à parler directement aux clients, à cartographier leurs irritants et à prototyper des solutions avant d'écrire la moindre ligne de code de production. Le critère pour avancer était clair : au moins quatre clients devaient s'engager à acheter le produit s'il sortait.

Ça retirait énormément de risque. Quand l'engineering entrait en jeu, l'équipe savait déjà qui allait acheter, pourquoi, et combien ces clients étaient prêts à payer.

Le modèle d'usine créait aussi de l'élan. Les équipes ne restaient plus bloquées à débattre sans fin des priorités. Tout le monde savait où en était chaque produit dans le pipeline et à quoi ressemblait le succès à chaque étape.

Salim a décrit l'effet clairement :

« Une fois l'usine lancée, tout s'est cumulé. On shippait plus vite, on apprenait plus vite, et on a arrêté de perdre du temps sur des idées qui ne se vendraient pas »

‍

Concevoir des squads pour la vitesse, pas pour le confort

Un des choix les plus contre-intuitifs de Salim a été de garder des squads volontairement petites et en partie partagées. Une squad type comptait un lead engineering senior, deux ingés backend et un ingé frontend. Le product management, le design et la QA étaient répartis sur plusieurs squads au lieu d'être entièrement dédiés.

Cette organisation allait à l'encontre de beaucoup de bonnes pratiques de scaling, mais elle forçait une priorisation impitoyable. Les équipes ne pouvaient pas se cacher derrière le process ou le sureffectif. Si quelque chose ne comptait pas, ça ne se faisait tout simplement pas.

La clé, c'était la séniorité. Ces squads étaient composées d'ingés expérimentés capables de décider seuls et d'assumer des arbitrages. Ils optimisaient d'abord pour pouvoir faire une démo, pas pour la perfection de l'architecture.

Cette approche a permis des cycles d'itération extrêmement rapides. Dans certains cas, les équipes ont shippé des produits prêts pour la démo en moins d'un mois, les ont affinés en direct avec les clients, puis ne les ont consolidés qu'après la validation commerciale.

La contrainte était voulue. Des ressources limitées créaient du focus. Le focus créait de la vitesse. La vitesse créait de l'apprentissage.

Ça facilitait aussi le passage à l'échelle. Quand la demande explosait, Salim pouvait ajouter des squads sans repenser toute l'orga. Chaque squad suivait le même modèle de fonctionnement, les mêmes jalons et la même définition du succès.

‍

Co-concevoir avec les clients jusqu'à ce qu'ils deviennent acheteurs

Un pilier essentiel de l'usine à produits de Fountain, c'était la co-conception. Les clients n'étaient pas interviewés une fois puis oubliés. Ils étaient intégrés au développement produit dès le premier jour.

Pour chaque nouvelle initiative, l'équipe recrutait un petit groupe de design partners. Ces clients avaient une vraie douleur, une vraie urgence et un vrai budget. Ils participaient à des sessions régulières, relisaient les prototypes et façonnaient la roadmap produit en temps réel.

Ça créait deux effets puissants. D'abord, la qualité produit augmentait nettement. Les équipes ne devinaient pas ce dont les opérationnels de terrain avaient besoin ; elles construisaient avec eux. Ensuite, les utilisateurs bêta devenaient des ambassadeurs.

Au moment du lancement, un produit avait déjà des clients prêts à signer. On ne demandait pas aux Sales de vendre une roadmap hypothétique. On leur remettait un produit avec des clients de référence, des case studies et de l'usage réel.

Dans certains cas, Salim a signé lui-même les premiers deals pour lever les frictions et prouver la demande. Une fois que le produit était clairement vendable, les équipes Sales suivaient vite.

Cette approche a transformé la bêta : d'un centre de coûts, elle est devenue un moteur de revenus. Chaque bêta avait un objectif commercial clair, et le succès se mesurait en bons de commande signés, pas en scores NPS.

‍

Aligner les lancements avec le go-to-market dès le premier jour

Shipper un produit n'a jamais été considéré comme la ligne d'arrivée. Pour Salim, un produit n'existait vraiment qu'une fois que le reste de la boîte pouvait le vendre avec assurance.

Le product marketing et la growth étaient impliqués des mois avant le lancement. Pendant que l'engineering travaillait sur la bêta, l'équipe go-to-market préparait le positionnement, le pricing, les landing pages, les decks commerciaux et la formation interne. Chaque lancement arrivait avec un « kit produit » complet, prêt pour les Sales, le marketing et le customer success.

Ça éliminait un écueil classique du SaaS B2B : d'excellents produits que personne ne sait vendre. Chez Fountain, les lancements étaient des moments synchronisés dans toute la boîte.

L'impact s'est vu tout de suite. Les taux de conversion se sont améliorés, les cycles de vente ont raccourci, et les nouveaux produits ont généré du revenu plus vite que les anciennes features ne l'avaient jamais fait.

« Si les Sales ne peuvent pas le vendre dès le premier jour, le produit n'est pas fini », tranche Salim

‍

Quand la vitesse bat la stratégie : le pari du produit i-9

Tous les produits ne sortaient pas d'une roadmap soigneusement planifiée. Une des plus grosses victoires de Fountain est partie d'un pari réactif.

Un gros client a prévenu Fountain qu'il changeait de prestataire pour la conformité i-9, une procédure de vérification d'emploi obligatoire aux US. L'opportunité était énorme, mais Fountain n'avait pas de produit.

Au lieu de lancer un long process stratégique, Salim a agi. Il a étudié la réglementation, lu les plaintes des clients, s'est associé à un fournisseur de moteur externe et a demandé à une équipe de quatre personnes de construire une démo en trois semaines.

Le produit était incomplet, mais crédible. Il a fait entrer Fountain dans l'appel d'offres face à des acteurs bien installés. À mesure que les exigences se précisaient, l'équipe a grossi, comblé les manques et shippé à un rythme soutenu.

Fountain a remporté le deal. En quelques mois, le produit tournait à très grande échelle et devenait l'une des lignes de revenus à la croissance la plus rapide de la boîte.

La leçon était claire : la vision compte, mais la vitesse et la confiance comptent parfois plus. Quand l'opportunité est assez grosse, l'élan peut justifier de tordre la roadmap.

‍

L'erreur : attendre trop longtemps avant de remettre en cause des hypothèses cassées

La plus grosse erreur partagée par Salim ne portait pas sur l'exécution, mais sur le timing. Le ralentissement de Fountain ne s'est pas fait du jour au lendemain. La vélocité Produit a baissé petit à petit, à mesure que les équipes grossissaient, que les process se rigidifiaient et que la peur de tout casser augmentait.

Pendant trop longtemps, ces signaux ont été acceptés comme normaux. Les délais à rallonge, une culture engineering négative et l'excès de process se sont installés avant que la direction ne réagisse vraiment.

Au moment où elle a agi, la boîte avait déjà perdu de l'élan et des opportunités de revenus.

La leçon clé : ne pas attendre une crise pour questionner les hypothèses de base. Quand les équipes disent plus souvent « c'est impossible » que « on essaie », quelque chose est déjà cassé.

Réparer ça demande plus que des réorgs ou de nouveaux frameworks. Il faut une preuve visible que la vitesse est encore possible, et des leaders prêts à soutenir la livraison plutôt que le consensus.

• Shipper une victoire incontestable peut déclencher plus de changement dans l'orga que des mois de réunions d'alignement.
• Traiter le développement produit comme une usine crée de la vitesse et de l'apprentissage qui se cumulent d'un lancement à l'autre.
• De petites squads seniors font mieux que de grosses équipes quand la vitesse et la responsabilité comptent le plus.
• La co-conception transforme les clients en acheteurs et retire l'essentiel du risque go-to-market avant le lancement.
• Un produit n'est pas fini tant que les Sales ne peuvent pas le vendre avec assurance, avec le bon discours et les bons outils.
• Les roadmaps stratégiques doivent savoir plier quand des opportunités rares et à fort levier se présentent.
• La dette culturelle et la dette technique grossissent en silence, mais se cumulent aussi vite que la vélocité Produit.