"Nous avons jeté les plans à la poubelle" : le fondateur d'Unframe explique comment atteindre 100 millions de dollars sans produit sur étagère
Le PDG et cofondateur d'Unframe, Shay Levi, explique comment l'abandon d'une planification rigide au profit de la résolution de problèmes clients spécifiques a permis à l'entreprise d'atteindre 100 millions de dollars de TCV en un an.
Shay Levi lors de l'enregistrement de l'épisode. Photo fournie par "Le podcast de Guy Katsovich"
Lorsque Shay Levi, PDG et cofondateur d'Unframe, a fondé l'entreprise, lui et ses partenaires avaient un plan de travail parfaitement organisé. Lors d'un événement en direct du "Podcast de Guy Katsovich", auquel ont également participé Amit Karp (associé directeur chez Bessemer Venture Partners), Barak Schoster (associé directeur chez Battery Ventures), Yanai Oron (associé directeur chez Vertex Ventures Israel) et Guy Katsovich (partenaire et fondateur du fonds Fusion), il a partagé la façon dont la réalité a bouleversé ces plans et à quoi ressemblent les départements de développement de demain.
"Lorsque nous avons fondé Unframe, nous étions sûrs que nous arriverions sur le marché avec cinq bonnes solutions, et que les clients choisiraient simplement ce qui leur convient", se souvient Levi. "Nous pensions que tout serait relativement clair. En pratique, c'est l'inverse qui s'est produit. Ce que nous avions préparé à l'avance ne les intéressait pas. Une compagnie d'assurance est arrivée avec un problème d'assurance, une société immobilière avec un problème immobilier, et chacune savait déjà ce qu'elle devait résoudre. Après quelques mois, nous avons jeté la liste et nous avons compris que notre produit ne serait pas l'une des cinq solutions que nous avions choisies. Le produit serait la capacité de construire pour chaque client ce dont il a réellement besoin."
"Comme le menu d'un restaurant chinois"
Cette approche n'était pas à l'abri des inquiétudes. "Dans l'une des conversations que j'ai eues lors de la phase d'amorçage, on m'a dit : vous allez être comme le menu d'un restaurant chinois, mille plats et personne ne sait quoi commander", se souvient Levi. "On m'a décrit le risque exactement. Une entreprise qui ne choisit pas un seul produit risque de s'éparpiller entre des centaines de demandes différentes et de ne rien construire qui puisse être répété pour une autre organisation. Mais les clients nous avaient déjà dit qu'ils ne voulaient pas choisir dans un menu, ils voulaient que nous résolvions leur problème. La question n'était donc plus de savoir s'il fallait rester avec les cinq solutions que nous avions préparées, mais comment construire quelque chose de différent pour chaque client sans repartir de zéro à chaque fois."
Selon lui, la clé était de décomposer le problème en couches d'infrastructure : "Ce que nous avons compris, c'est que la solution peut être différente, mais que tout ce qui se trouve en dessous n'a pas besoin d'être reconstruit. La compagnie d'assurance et la société immobilière ont reçu des choses différentes, mais derrière elles, les mêmes composants se répétaient : la connexion aux données de l'organisation, les autorisations, le contrôle et la manière d'amener la solution à un travail réel. Chaque fois que nous construisions quelque chose pour un client, le système s'améliorait également pour le client suivant. C'est ainsi que nous avons essayé de transformer la personnalisation, d'un élément ponctuel en un produit reproductible."
Les fondateurs d'Unframe. Photo : Unframe
Derrière Unframe se trouve une équipe qui travaillait déjà ensemble dans une entreprise de logiciels qui a grandi à grande échelle. L'entreprise a été fondée par Levi, Larisa Schneider (directrice des opérations) et Adi Azaria (vice-président R&D). Tous trois ont travaillé auparavant chez Noname Security, dont Levi était cofondateur et qui a été vendue à Akamai il y a environ deux ans pour environ 450 millions de dollars. Unframe construit des solutions d'IA personnalisées pour les organisations, connectées à leurs données, flux de travail, autorisations et systèmes existants, en utilisant des composants technologiques réutilisables. L'entreprise a déjà dépassé une valeur totale de contrat (TCV) de 100 millions de dollars environ un an après le lancement du produit.
50 000 contrats en PDF et la différence avec Noname
Levi précise la différence fondamentale entre les deux entreprises. Alors que chez Noname Security, le point de départ était un produit vendu à de nombreuses organisations, chez Unframe, le processus commence à chaque fois par le problème apporté par le client. "Chez Cushman & Wakefield, par exemple, le problème était la gestion d'environ 50 000 contrats de location commerciale stockés dans des fichiers PDF. Chaque contrat était rédigé différemment, avec des clauses, des dates et des conditions qui devaient être vérifiées manuellement. Nous avons construit pour l'entreprise un système qui lit les contrats, en extrait les informations pertinentes et les connecte à ses flux de travail. Ce n'était pas l'une des cinq solutions que nous avions préparées au début du voyage, mais elle reposait sur les mêmes composants déjà construits pour d'autres clients."
Lorsqu'on lui a demandé par Yanai Oron comment gérer des centaines d'applications sans devenir une collection de projets, Levi a répondu : "Le problème est plus similaire qu'il n'y paraît à celui d'une entreprise de logiciels classique. Là aussi, des demandes différentes arrivent de clients différents, et le travail consiste à identifier lesquelles d'entre elles indiquent un besoin commun qui devrait être intégré au produit. La différence est qu'ici, le dénominateur commun se trouve sous les solutions, et n'est pas toujours visible pour l'utilisateur lui-même. Lorsque nous ajoutons quelque chose à la plateforme, cela ne reste pas chez un seul client. Cela peut également améliorer d'autres solutions. Tant que la majeure partie du travail entre dans la couche commune et ne reste pas comme quelque chose de ponctuel, des centaines d'applications ne créent pas nécessairement des centaines de produits distincts."
Clôture de contrats d'entreprise en un mois et demi
En réponse à la question d'Amit Karp sur la préparation du marché, Levi a expliqué qu'aujourd'hui, les organisations arrivent beaucoup plus préparées : "Au début, elles s'attendaient à ce que nous leur disions où insérer l'IA. Aujourd'hui, c'est presque l'inverse. Les organisations ont déjà cartographié leurs problèmes, elles arrivent avec une liste organisée et savent exactement ce qu'elles veulent atteindre. Parfois, vous entrez dans une pièce et vous avez l'impression qu'elles attendaient juste que quelqu'un s'en occupe et commence à travailler. Nous arrivons à une situation où de gros contrats sont conclus en peu de temps. C'est quelque chose que je n'avais jamais connu."
À la question d'Oron sur la capacité à conclure un contrat et à lancer une solution en quelques semaines dans des organisations d'entreprise, Levi a précisé : "Il faut faire la distinction entre un contrat conclu et une situation où toute l'organisation utilise déjà le système. En un mois et demi, on peut parvenir à un accord, commencer à travailler et lancer une première solution dans un environnement limité. Ensuite vient l'étape de l'expansion : plus de départements, plus d'utilisateurs et plus de processus. Ce n'est pas que toute l'organisation change en deux semaines, mais on peut atteindre la première valeur beaucoup plus rapidement qu'auparavant."
Barak Schoster s'est demandé quelle était la partie difficile du processus, et Levi a précisé que la réponse est la confiance : "Une grande organisation peut construire par elle-même, travailler avec un cabinet de conseil, choisir un fournisseur existant ou simplement ne rien faire. Lorsqu'une startup arrive et dit : laissez-moi entrer dans vos processus et je vais résoudre cela, ce n'est pas trivial. Ils doivent croire que vous comprenez le problème, que la solution fonctionnera et que vous serez là même après la mise en œuvre. Une fois que cette confiance est créée, tout peut avancer beaucoup plus rapidement."
Faut-il enterrer les petits produits SaaS ?
En réponse à la question de Guy Katsovich sur l'avenir des produits SaaS classiques, Levi a rassuré : "Je ne me précipiterais pas pour enterrer Salesforce, SAP ou ServiceNow. Si la meilleure chose qu'une organisation puisse faire de son temps est de construire son propre Salesforce juste pour économiser la licence, elle a un autre problème. De tels systèmes sont profondément ancrés dans l'organisation, détiennent des données et des processus, et ils ne sont pas déracinés si rapidement. Mais pour les produits plus petits, qui servent un département ou un besoin très spécifique, cela peut déjà arriver. Un client peut dire : vous avez construit ces deux processus pour moi, maintenant remplacez aussi le système supplémentaire et faites-le exactement comme j'en ai besoin."
Selon lui, les grands systèmes ne disparaîtront pas, mais leur rôle changera : "Au début, vous ne les déracinez pas. Vous construisez les processus qui vous manquent autour d'eux. Avec le temps, il se peut que de plus en plus de travail se déplace vers une autre couche, et le grand système restera principalement l'endroit où les données sont stockées. Il passe d'un produit dans lequel l'utilisateur travaille toute la journée à une sorte d'ancien système d'enregistrement qui se trouve à l'arrière-plan. Ce n'est qu'à un stade beaucoup plus tardif qu'une organisation pourrait se demander si elle en a encore besoin."
Ce tournant soulève également une question concernant la nécessité des départements de développement internes dans les organisations traditionnelles. "J'y ai pensé à l'époque où nous travaillions avec l'une des plus grandes entreprises de consommation au monde", a partagé Levi. "Je me suis demandé pourquoi une entreprise dont le produit n'est pas un logiciel a un département de développement. Lorsqu'elle doit construire un bureau, elle fait appel à un entrepreneur, et lorsqu'elle a besoin de transport, elle ne crée pas une compagnie de bus. Alors pourquoi l'hypothèse est-elle apparue que chaque organisation doit maintenir une équipe qui construit elle-même chaque système interne ? Il se peut qu'il y ait des choses qui sont directement liées au produit et à son avantage concurrentiel et qui devraient être gardées à l'intérieur. Mais de nombreuses entreprises construisent encore et encore les mêmes tableaux de bord, processus d'approbation et connexions entre les systèmes. Il n'y a aucune raison pour que mille organisations commencent tout ce travail à partir de zéro."
Selon lui, l'hypothèse selon laquelle chaque entreprise doit maintenir un grand département de développement n'est plus une évidence. Et lorsqu'Oron lui a demandé ce qu'il se dirait au début du voyage, il a conclu : "Écoutez plus tôt ce que les clients apportent avec eux. Nous sommes arrivés avec des réponses, et ils sont arrivés avec des problèmes. Une fois que nous avons compris que notre valeur n'est pas de choisir pour eux dans une liste, mais de construire autour de ce qui est déjà important pour eux, toute l'entreprise a changé. Il nous a fallu quelques mois pour jeter ce que nous avions préparé à l'avance. Avec le recul, c'est la décision qui nous a permis de commencer à construire le vrai produit."
Dans l'épisode complet, Levi parle également de la transition de CTO à PDG, de la pression dans le parcours entrepreneurial pour la deuxième fois, et des endroits où l'expérience précédente ne l'avait en fait pas préparé à ce qui est arrivé ensuite.
