Product Inbox 📬 Backstage #2 - Comment PlayPlay construit son Produit
L'équipe Produit de PlayPlay détaille son organisation et leurs process pour faire du Produit.
Après avoir lu cette édition, ce serait super que tu prennes 30 secondes pour me dire ce que tu en as pensé :)
👉 Comment as tu trouvé cette édition ?
Hello 👋, bienvenue dans cette 2ème édition Backstage de Product Inbox ! On est désormais 10,842 sur cette newsletter. Merci pour ta lecture et ton soutien 💛.
Je m’appelle Timothé et si ce n’est pas déjà fait, tu peux :
Faire décoller ton produit grâce à ⭐️ notre collectif de top CPOs ⭐️
Rendre visible ton produit 💥 sur notre newsletter ou podcast
Me suivre sur Linkedin
Introduction
Je suis super content de te présenter la 2ème édition “Backstage” de Product Inbox dans laquelle je te partage comment les meilleures startups et scale-ups construisent leur produit.
Dans cette édition, je suis hyper heureux de te montrer les coulisses de PlayPlay, une entreprise très impressionnante d’un point de vue Produit. L’équipe Produit de PlayPlay, pilotée par Pauline Marol, a accepté de répondre à mes questions qui portent principalement sur leur process de développement produit et leur organisation.
Un GRAND merci à Pauline, Orlane et Claire pour cette photo ultra détaillée du développement Produit chez PlayPlay et pour leur accueil dans leurs bureaux 💜.
En quelques années, PlayPlay a construit une solution de création de vidéos qui permet à des milliers d’équipes Communication et Marketing de créer des vidéos professionnelles sans aucune compétence technique. En 7 ans, PlayPlay a créé un produit technique et très apprécié, utilisé par plus de 2500 clients dont L’Oréal, SNCF, Booking.com ou Orange.
Aujourd’hui, PlayPlay c’est :
230 collaborateurs au total
2500+ entreprises clientes
14 personnes au Produit
70M$ levés.
Les points principaux à retenir 🧠
Planification Produit sur 2 niveaux : annuelle et trimestrielle.
Beaucoup de temps passé sur le problème en Discovery. Équipe technique y participe. CEO et VP CSM également.
En Discovery, notion d’investissement calibrée et mesurée pour aider à la priorisation.
PlayPlay s’efforce à sortir un “lovable product”, niveau d’exigence ++.
Multiples rituels en place : café Produit (rythme hebdo, présentation Produit au Codir), check-ins (2 fois par mois, réévaluation du prévisionnel Produit)
Politique zéro bug + qualité Produit type “Enterprise”. Activées par des pratiques organisationnelles (squad rotative, communautés de pratique technique) et pratiques culturelles (pair-coding, sessions collectives de recettes, règles de résolution des bugs)
Impact des améliorations Produit mesuré sur 4 piliers (découvrabilité, adoption, usage, feedback)
Utilise l’IA dans le dév’ Produit via un customGPT. Veille Produit et concurrentielle ultra actives via Slack, ateliers + Product Ops à plein temps.
✅ Parties clés
Stratégie & vision produit
1. Comment articulez-vous la vision, la stratégie et la roadmap chez PlayPlay ?
Le développement Produit chez PlayPlay fonctionne sur 2 niveaux :
Un rythme annuel (point A ci-dessous) qui permet de poser les grands enjeux de l’année, de se re-challenger sur la vision et de définir notre stratégie.
Un rythme trimestriel (point B ci-dessous) qui nous permet de nous aligner de manière plus précise sur les opportunités Produit sur lesquelles les équipes vont travailler en discovery et en delivery.
A. La définition de la stratégie annuelle
L’exercice commence pendant l’été de l’année précédente par beaucoup de recherche : enquête utilisateurs, étude du marché, analyse sur le churn et les raisons de deal losts, entretiens utilisateurs menés par le CEO et la VP product, analyses spécifiques sur les tendances dans notre marché du contenus et de la vidéo, etc. À la fin de cette étape, on sort un mega SWOT product qui synthétise toute cette matière.
Puis, dès septembre on utilise ce SWOT et on organise des ateliers en petit comité pour réfléchir aux grands enjeux Produit à venir. Au fur et à mesure des ateliers, on commence à définir des piliers produit et on voit comment ils résonnent en interne. Ces ateliers incluent les différentes équipes business ainsi que toute l’équipe Produit et les leaders de la tech. À la fin de cette étape on a un document qui résume notre vision Produit, les grands enjeux de l’année prochaine et les objectifs qu’on va se fixer (voir ci-dessous) :
Mi-Q4, le Codir construit le plan de l’année à venir pour toute la boite, s’assure qu’il y a une cohérence et des synergies entre la vision produit et le plan Go To Market et valide la stratégie produit. Cette dernière est aussi présentée au board qui doit la valider. À la fin de cette étape on a la stratégie annuelle “définitive” avec des directions claires, les paris sur lesquels on veut investir ainsi que la répartition de l’investissement (combien d’équipes sur quel sujet).
Fin Q4, l’équipe Produit et les Tech Leads travaillent pour affiner cette stratégie en OKR, en opportunités et en un début de planning. Avant les fêtes, on organise une grosse journée pour faire le bilan de l’année et communiquer à toute l’équipe R&D notre mission, vision, stratégie, le plan et l’organisation pour l’année à venir. Cela permet à tout le monde de se projeter et de revenir en janvier prêt à attaquer directement sur ses sujets.
Ce rythme annuel permet de planifier l’année en macro, d’anticiper les défis techniques ainsi que les grosses discovery qui seront nécessaires.
On a beaucoup itéré sur le process de définition d’une stratégie annuelle car notre produit était jeune dans une industrie qui bouge énormément. Pendant les 4 premières années de PlayPlay on a fonctionné essentiellement sur des rythmes trimestriels ou semestriels (voir ci-dessous). Cela avait l’avantage de donner beaucoup de flexibilité (surtout avec des équipes réduites) mais l’inconvénient de ne pas donner assez de contexte long terme aux équipes et de ne pas laisser le temps pour des changements ambitieux dans le produit. Depuis 2 ans, nous avons trouvé le fonctionnement adapté (celui décrit précédemment).
NB : pour la formalisation et la visualisation de tout cet exercice de Stratégie, nous nous sommes appuyé sur ce template Figjam de Product Stratégie.
B. La définition de la roadmap trimestrielle
Tous les 3 mois, nous présentons à quelques leaders de PlayPlay notre proposition de roadmap (avec des opportunités liées à chacun de nos OKRs). Cela nous permet de garder l’alignement sur notre stratégie annuelle. Cela nous laisse aussi la flexibilité nécessaire pour avancer dans une industrie aussi dynamique.
Par ailleurs le reste de PlayPlay a une cadence trimestrielle forte avec des évènements en interne de communication d’objectifs. C’est pratique pour nous de nous caler aussi sur ce rythme afin de bien communiquer en interne sur notre roadmap.
Anecdote : Chez PlayPlay on ne communique pas vraiment de date de lancement des fonctionnalités. On est les champions du “-ish” : on dit “lancement en Q2-ish” ou alors “in the next monthssss”. C’est devenu une blague en interne, quand les gens veulent nous charrier ils ajoute “-ish” à la fin de chaque phrase !Product Discovery
2. Comment est menée la Product Discovery chez PlayPlay ?
La discovery a toujours été une partie forte de notre culture Produit*. On y est très appliqué et notre défaut serait plus d’y passer trop de temps plutôt que pas assez !
On a formalisé un Playbook à suivre pour toutes nos opportunités avec une page Notion qui détaille précisément ce qu’il faut faire. La page propose des templates pour les différentes étapes. Cela permet d’homogénéiser les pratiques entre les différentes équipes, de les faire monter en compétences et d’évangéliser efficacement les bonnes pratiques de Discovery.
On n’a pas de “secret sauce” : on essaie d’appliquer les frameworks classiques en prenant le meilleur de ce qu’on trouve à droite et à gauche. Puis on challenge régulièrement notre process pour l’améliorer.
Les dernières évolutions que nous avons apportées à notre Playbook :
La formalisation de l’étape de définition de l’opportunité suite à la lecture du livre “Discovery Discipline” (co-écrit par Rémi Guyot et Tristan Charvillat)
Nous passons beaucoup plus de temps sur la compréhension du problème parce que les sujets produit sur lesquels nous travaillons sont plus complexes avec une roadmap de plus en plus innovante : on a ajouté la partie golden nuggets et on a formalisé le fait d’inclure l’équipe technique dès cette étape avec un document qu’on appelle “Technical DOD”. Celui-ci permet de lister les zones de frictions techniques et de rédiger un éventuel « ADR » (Alternative Dispute Resolution) dans le cas où plusieurs options techniques structurantes sont en jeu.
Depuis 1 an, on intègre beaucoup de fonctionnalités “powered by AI” dans notre produit et on a dû adapter notre étape de recherche de solution. La compréhension et le test des technologies d’IA devient autant (voire plus) important que le design !
Toutes les opportunités apparaissent dans une page Notion ce qui nous permet d’avoir une vue globale des différents sujets en parallèle et de leur stade de développement.
D’un point de vue plus culturel, on a deux spécificités :
Notre CEO ainsi que nos VP Product et VP CSM sont très investies dans la discovery. Ils participent activement à la construction du produit (depuis plus de 5 ans). Soyons honnêtes, les sujets les plus stratégiques sont nos principaux sujets d’échanges. Mais on peut aussi y placer des discussions plus micros, comme l’UI ou le wording par exemple.
L’équipe Produit suit un rituel hebdomadaire avec ces 3 parties prenantes, nommé “le café produit”. Tous les jeudis matins, l’équipe produit choisit un sujet et vient en parler avec ces membres du Codir. Le sujet présenté peut être à un stade d’opportunité, de problème ou de solution. Tous les participants sont formés à notre playbook discovery et savent intervenir à ces différents stades de réflexion.
*Si vous voulez en savoir plus, nous avons parlé de notre Playbook Discovery dans un long article et un podcast.
Développement Produit
3. Comment votre équipe évalue-t-elle les chantiers Produit, suit-elle la vélocité, et sait quand quelque chose est hors scope ?
La vélocité n’est pas vraiment un enjeu chez PlayPlay et on la suit parmi beaucoup d’autres indicateurs pour évaluer la santé de notre delivery.
Ce qui est important pour nous c’est de :
Faire un beau produit qui a de l’impact et qui remplit nos critères de qualité - on parle de “lovable product” (voir ci-après)
Définir l’investissement raisonnable que nous voulons avoir sur chaque fonctionnalité et de s’y tenir au maximum. Les notions de prédictabilité et de maîtrise de notre investissement sont plus importantes que la notion de vélocité.
Pour ce qui est du 2ème point, voici comment on s’organise :
Dès la discovery, nous réfléchissons à l’investissement raisonnable que nous voulons avoir sur cette opportunité (notre ”appétit”). C’est une notion très importante qui nous amène à faire des choix dès la recherche de solutions. Pour y parvenir, nos Tech Leads sont intégrées à toutes les étapes de la Discovery et des POCs techniques peuvent être réalisés en cas besoin. La solution finale qui est retenue doit être en accord avec l’investissement validé.
Lors de la préparation de la delivery, Product Manager et Tech Lead de la squad découpent le projet en lots livrables en production. Pour chaque milestone, un cadrage précis est réalisé et un chiffrage (une estimation du coût de développement) est avancé par la squad qui va développer la fonctionnalité.
On utilise systématiquement le framework MOSCOW. Cela nous permet de construire des fonctionnalités en démarrant par le fonctionnel MUST, puis on ajoute le SHOULD et enfin on termine (quand il nous reste du budget !) par le NICE TO HAVE.
Cette organisation nous donne une grande souplesse dans notre roadmap car elle nous permet d’arrêter l’investissement sur un projet après chaque milestone sans perdre 100% du projet.
Par exemple, si on a défini un appétit de 6 semaines sur une opportunité mais que le projet prend un peu de retard on est capable de s’arrêter à 6 semaines en ne livrant finalement “que” le fonctionnel MUST.
3) On a mis en place un rituel appelé “check-in” : toutes les 2 semaines le binôme PM / Tech Lead a un point formel avec le Head of Engineering et la Lead PM. Ce point permet de suivre l’avancée des projets, de réévaluer l’atterrissage prévisionnel du projet et éventuellement d’arbitrer sur un scope fonctionnel plus réduit que ce qu’on avait prévu afin de maintenir l’objectif d’investissement. Ils permettent de garder le contrôle sur les sujets. Par ailleurs ces “check-ins” ont le bénéfice de faire monter en compétences le binôme PM / Tech Lead en créant un vrai coaching sur la gestion de leur delivery et de leur équipe.
NB : Bien entendu, comme toutes les équipe tech, il y a aussi des projets sur lesquels on se trompe complètement sur le chiffrage et sur lesquels on ne peut pas réduire magiquement le scope fonctionnel 😅.
4. Comment est adressé le sujet de la qualité et des bugs dans votre delivery ?
Chez PlayPlay, on vend un produit sur le haut du marché, à des clients Enterprise. Nous sommes donc très exigeants sur la qualité de notre produit. C’est pour cette raison qu’on a fait le choix d’appliquer la politique zéro bug depuis plusieurs années et qu’on a introduit plusieurs pratiques pour nous en donner les moyens.
A. Des pratiques organisationnelles
Mise en place d’une squad “qualité” rotative. Chaque squad dédie 1 sprint à la qualité à tour de rôle. Pendant ce sprint, la squad arrête tous ses autres sujets Produit et se concentre sur le traitement des bugs, la gestion des incidents, la surveillance des alertes en production et l’assistance aux clients qui sont bloqués via notre Chat (c’est un peu un support de niveau 3). Cette équipe est donc très réactive pour dépiler le backlog de bugs, investiguer des sujets de fond et garantir une grande qualité de service pour nos utilisateurs.
NB : En plus de la qualité, cette équipe a d’autres responsabilités et “protège” les autres équipes de toutes les autres sollicitations internes qui sont inévitables et qui viendraient perturber le bon déroulement de la delivery normale : traitement des demandes exotiques de nos chargées de compte, améliorations de nos outils internes, mini évolutions design et produit, assistance des équipes business sur des projets, etc.
On a une Product Manager qui travaille à temps plein sur ces sujets et prépare ce backlog. Les squads viennent, le temps d’un sprint, agir dans ce backlog plutôt que dans leur backlog Produit habituel. Le planning de rotation des squads est établi à l’avance pour que le “sprint qualité” arrive de manière la plus pratique possible par rapport à leur sprint classique.
Anecdote : ce principe de “responsable” qualité existe depuis les tous premiers jours chez PlayPlay. Quand on était 15 dans un open space nous avions acheté une peluche qui était sur le bureau de la développeuse chargée de la qualité (c’était un panda en peluche très moche). Au fur et à mesure de notre croissance on a eu 2 développeuses puis une squad entière sur ce périmètre. La peluche a gardé son empreinte : on parle de pandi-squad, pandi-backlog et pandi-PM !Investissement assumé dans les communautés de pratiques techniques pour contrôler la dette technique. Chaque développeuse prend une journée par quinzaine pour travailler sur des sujets de communauté technique. Les communautés sont créées autour d’un besoin spécifique pour une durée déterminée. Elles sont animées par un “capitaine” et doivent définir des objectifs et un impact précis. Elles partagent leurs avancées tous les mois avec l’ensemble de l’équipe produit et technique. Exemple d’objectifs atteints par la communauté de pratiques techniques sur un semestre :
Des équipes dédiées aux sujets techniques qui sont mobilisées en fonction des chantiers techniques de fond (ex: migration vue3 ou chantiers sur le rendu vidéo). On les appelle des “missions commandos”. Pendant un temps défini, certaines développeuses sélectionnées avec soin quittent leur squad Produit pour rejoindre cette initiative technique. Par exemple en 2023, nous avons lancé 2 missions commando Front-End et 3 missions commandos Back-End.
B. Des pratiques culturelles
Dans les squads, les développeuses fonctionnent en binôme et appliquent le pair-coding une grande partie du temps. Cette action a un grand impact sur la qualité du code car il permet de réduire les bugs by design
En plus des tests de la QA engineer et des développeuses, des sessions collectives de recette sont organisées avec les PM, les designers et des personnes externes au projet (oeil neuf !)
Anecdote : on appelle ces séances collectives de testing des “recette parties” parce qu’historiquement on était tous autour d’une table, on apportait les chouquettes et on mettait de la musique. Maintenant ce sont de séances de travail bien classiques, souvent avec beaucoup de monde à distance mais on a gardé le nom de “recette party” dans l’invitation !Les bugs P1, P2 identifiés avant la mise en production doivent être corrigés pour autoriser le déploiement. Les bugs P3 doivent être corrigés idéalement avant le déploiement ou dans un délai maximum de 1 mois après le déploiement.
Les bugs remontés en interne (ou par les clients) qui seraient liés à une fonctionnalité de l’équipe revient dans le domaine de responsabilité de cette équipe pendant un certain temps après le déploiement.
La Tech Lead de la squad est responsable du stock de bugs ouverts dans son périmètre et objectivée sur cet indicateur (parmi d’autres).
5. Comment mesurez-vous les succès / impacts des fonctionnalités déployées ?
La mesure du succès se fait à 2 niveaux chez nous :
Au niveau local, avec la mesure du succès de chaque fonctionnalité qu’on lance
Au niveau global, avec le suivi de nos métriques OKR qui permettent de suivre l’impact de notre roadmap.
A. Le succès d’une fonctionnalité
Pour reprendre un terme mentionné plus haut, notre objectif n’est pas de lancer une fonctionnalité mais un “lovable product” qui répond aux critères suivants :
Son usage est conforme à ce qui était défini lors de la phase de delivery
Son usage ne génère pas de frictions
Les clients aiment la fonctionnalité (retours qualitatifs de nos équipes CS ou questionnaire de satisfaction dans le produit)
Les demandes d’itérations sur le produit de la part des utilisateurs sont marginales (ou jugées non prioritaires par l’équipe produit)
L’équipe technique considère que le code est propre, finalisé et scalable.
Voici comment on y travaille :
1. En amont des développements, on définit :
Quel est l’usage actuel (sur PlayPlay ou en dehors de PlayPlay)
Quel est objectif à atteindre et le résultat mesurable attendu
Une liste de questions auxquelles on souhaite répondre via l’analyse post-lancement.
À la fin des développements, on crée les tableaux de bord pour suivre la fonctionnalité sur nos 2 outils d’analytics (Zoho et Heap).
Après plusieurs semaines et jusqu’à 2 mois après le lancement, on mène une analyse post-lancement qui couvre 4 piliers : découvrabilité, adoption, usage, feedback.
Découvrabilité : on analyse la performance du plan de communication réalisé, le nombre d’utilisateurs qui ont découvert la fonctionnalité
Adoption : on analyse l’efficacité UX de la fonctionnalité, ainsi que l’adoption/rétention de la fonctionnalité au sein de notre base client. On détermine s’il y a des critères saillants (typologie de compte, profils, typologie de vidéos)
Usage : on identifie comment la fonctionnalité a été utilisée. Se posent ces questions :
Quelles options ont été sélectionnées ?
Quelles valeurs ont été choisies ?
Sont-elles différentes des valeurs par défaut ?
On observe aussi les powers users de la fonctionnalité et les meilleures vidéos créées par nos clients concernés par la fonctionnalité.
Feedback : on active les différentes sources de feedback client (Product Board, équipe chat, équipe des chargées de compte, équipes Sales) afin de connaitre l’avis des clients et/ou de potentielles itérations à faire.
A l’issue de cette analyse exhaustive qui prend la forme d’une présentation de 20 à 30 slides (oui oui, chaque analyse post-lancement est un projet de recherche en soi), on définit si la fonctionnalité a atteint un état de Lovable ❤️. Si ce n’est pas le cas, on planifie les itérations nécessaires.
Ces analyses post-lancement sont vraiment fortes dans notre culture produit. On investit du temps pour comprendre l’impact de nos produits, les usages de nos clients et s’assurer qu’on crée des produits “lovable” qui méritent de rester dans le produit. Les Product Managers travaillent en binôme sur ces analyses post lancement pour limiter les risques de biais de confirmation dans les analyses. Notre Lead PM est coach data et se rend disponible pour toute l’équipe. Elle accompagne aussi les plus juniors.
Anecdote : Ces analyses post-lancement étaient déjà présentes dans la première version de notre Playbook dès 2019. A l’époque on formalisait ça dans un template Notion avec 4 questions. On a bien évolué depuis !B. L’impact de notre roadmap
Depuis qu’on a réussi à mettre en place une vraie structure OKR, le suivi de l’impact est beaucoup plus simple. On a créé des dashboards qui permettent de visualiser ces métriques et leur évolution dans le temps. Parfois le lancement d’une fonctionnalité se voit directement avec un point d’inflexion fort sur une ou plusieurs courbes. Parfois c’est plus progressif ou il faut plusieurs fonctionnalités pour débloquer un nouvel impact. Dans tous les cas, ces dashboards nous permettent de relier nos roadmaps à un impact chiffré. Ils sont présentés tous les trimestres à toute l’équipe Tech et Produit
Spécifique à PlayPlay
6. Y a-t-il quelque chose d'unique dans la manière dont le Produit envisage le développement Produit ?
A. L’utilisation de l’IA dans le développement Produit
On n’innove pas que dans le produit mais aussi dans notre approche du produit ! En tant que produit fortement impacté par la révolution de l’IA générative, c’était très important pour nous de nous acculturer à l’IA et de l’activer au maximum.
Fin 2023 on a lancé un petit groupe qui a pris le sujet pour identifier tous les cas d’usage où l’IA pourrait nous faire gagner du temps et créer des prompts associés à ces usages (voir illustration ci dessous). On a ensuite organisé une journée d’offsite avec toute l’équipe pour (entre autre) tester tous ces prompts et générer une adhésion globale. Puis notre PM expert ChatGPT a mis tout ça dans le cerveau d’un customGPT qu’on a baptisé Whalee. Depuis, l’équipe s’en sert pour gagner du temps à différentes étapes du workflow produit !
Anecdote : chez PlayPlay, les équipes ont des animaux totem, celui de l’équipe Produit est la baleine et c’est comme ça qu’est venu le nom de Whalee pour ce custom GPT ! (jeu de mot entre Whale et WALL-E, le robot !)B. L’importance de la veille Produit
On a une culture de veille très active. On est tout le temps à l’affût de nouveautés produit et technologique dans un écosystème de création de contenus qui est extrêmement vaste et dynamique.
Au delà de l’équipe produit, toute l’organisation est encouragée à partager des infos sur des concurrents existants ou sur de nouveaux concurrents identifiés (par ex. dans un call avec un prospect) sur un canal Slack dédié ce qui nous permet de garder un très bon niveau de conscience sur ce qui se passe sur le marché et sur l’émergence de nouveaux concurrents.
Au sein de l’équipe Produit, chacun a sa routine de veille selon les enjeux de sa squad (veille spécifique dans un contexte de disco) et est également encouragé à faire de la veille continue pour maintenir un bon niveau de connaissance marché. On se partage nos apprentissages en asynchrone sur Slack ou plus occasionnellement lors d’ateliers dédiés (voir ci-dessous)
Enfin pour compléter l’exercice, notre Product Ops Manager s’investit plus sur une veille généraliste avec à la fois l’analyse plus précise de certains concurrents ou des analyses stratégiques avec les nouveautés clés du marché et de nos top concurrents sur les derniers mois. Le tout est centralisé sur Notion et peut ensuite être activé par l’équipe Produit grâce à plusieurs systèmes de tag qui permettent facilement d’identifier des concurrents selon les besoins :
Des tags de “tiering” : ils permettent d’identifier la proximité du concurrent à PlayPlay en se basant sur les points communs et écarts entre notre proposition de valeur et la leur. Les tiers 1 sont nos concurrents les plus directs tandis que les tiers 3 sont nos concurrents les plus éloignés
Des tags thématique assez macro pour identifier les use cases adressés par le concurrent, le marché ou encore l’utilisation ou non d’une techno IA
Des tags fonctionnalités assez micro qui permettent de rapidement trouver des concurrents pour un benchmark lors du développement d’une fonctionnalité
Merci à toute l’équipe Produit de PlayPlay et en particulier à Pauline, Orlane et Claire pour leur participation à cette édition 💜. Pour en apprendre plus sur PlayPlay, RDV sur leur site ou leur page Linkedin.
💫 Qu'est-ce que Stellar ?
J’ai cofondé Stellar pour accompagner les dirigeants de startups à faire de leur Produit un moteur de croissance inarrêtable.
Et pour activer cette croissance, on a créé :
Un collectif de 15 CPO des meilleures boîtes tech (Zenly, Yousign, BlaBlaCar)
Des formats d’intervention rapides (moins d’une semaine)
Des solutions concrètes à actionner dans la foulée.
Résultats : vous améliorez vos metrics business, votre vitesse d’exécution et la qualité de votre Produit.
Nous avons accompagné 40 clients depuis notre lancement (dont Zeliq 🇫🇷, Edusign 🇫🇷, Fountain 🇺🇸, Tennders 🇪🇸, Predict4health 🇫🇷).
Notre ambition : vous faire atteindre vos objectifs business et positionner votre produit en leader de son marché.
Envie de travailler ensemble ?
Pour me soutenir :
Si l’édition t’a plu, ce serait super que tu la partages 🙏
Timothé