Product Inbox đŹ Backstage #4 - Comment Partoo construit son Produit
L'équipe Produit de Partoo détaille son organisation et leurs process pour faire du Produit.
Hello đ, bienvenue dans cette 4Ăšme Ă©dition Backstage de Product Inbox ! On est dĂ©sormais 12,046 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 âïž
Me suivre sur Linkedin
đ„ł Gros Ă©vĂ©nement Produit en vue (grĂące Ă Userpilot)
Pour la 4Úme année consécutive, Userpilot organise son Product Drive Virtual Summit.
Pour cette édition, 10 speakers de renom sont programmés : Marty Cagan, April Dunford, Wes Bush, Maja Voje, Anthony Pierri, Ben Williams, Dan Olsen, Christian Idiodi, Ant Murphy, David Pereira.
Vu les speakers conviĂ©s, tu imagines bien qu'un paquet de sujets d'actu seront creusĂ©s en live : Product Operating Model, scaler un SaaS sans Ă©quipe Sales, GTM pour produits IA, Product Strategy et plein dâautres.
Bonus : Wes Bush, le fondateur de Productled.com tiendra un talk le 8 octobre dans les bureaux de Userpilot Ă Dublin (si jamais vous ĂȘtes dans les parages đ).
La bonne nouvelle ? L'événement est 100% gratuit.
Le Product Drive Virtual Summit a lieu les 8 et 9 Octobre prochain.
Perso, je serai de la partie (immanquable).
Tu veux réserver ta place ?
Introduction
Je suis super content de te prĂ©senter la 4Ăš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 te dévoile les coulisses de Partoo, une entreprise que je commence à bien connaßtre aprÚs avoir reçu Savinien, leur CPO, à 2 reprises sur Clef de voûte (tu peux découvrir les épisodes ici et ici).
Et si je trouve cette scale-up fascinante, câest parce quâelle est un exemple Ă beaucoup dâĂ©gards, en plus dâavoir Ă©tĂ© longtemps bootstrappĂ©e (rarissime en France).
Alors jâai eu envie de creuser la façon dont Partoo fait du Produit. Et leur Ă©quipe a gentiment acceptĂ© de rĂ©pondre Ă mes questions qui portent principalement sur leur process de dĂ©veloppement produit et leur organisation.
Un GRAND merci à Savinien, Eugénie, Matthias, Marin et Anouchka pour cette photo ultra détaillée du développement Produit chez Partoo.
Partoo, câest une plateforme collaborative qui permet aux entreprises ayant plusieurs points de vente de mieux interagir avec leurs clients. Pour ça, la scale-up a dĂ©veloppĂ© plusieurs produits :
Un produit de Presence Management pour gérer la visibilité en ligne
Un produit de Review Management pour gérer la reputation
Un produit de Feedback Management pour gérer la satisfaction
Un produit de Messages pour gérer la conversion
Des applications Web et Mobile
Aujourdâhui, Partoo câest :
33M⏠dâARR (bootstrapped)
400 collaborateurs au total
30 personnes au Produit
112,000 utilisateurs
1,500 clients
4 produits
Pour en savoir plus sur Partoo, clique ici. Et ils recrutent.
Et pour plus dâhistoires sur les coulisses des meilleures Ă©quipes Produit EuropĂ©ennes, ne manque pas les prĂ©cĂ©dentes Ă©ditions Backstage de Product Inbox sur Maze, PlayPlay et Pennylane.
Les points principaux Ă retenir đ§
Les OKRs sont utilisés sur 3 niveaux : entreprise, département, individuel
Organisation Produit a peu évolué. 4 Tribes décomposées en Impact teams. Lead PM et EM pilotent chaque Tribe. Chaque Impact team = 1 PM + 3 devs minimum.
Chaque Designer travaille avec 2 Ă 3 Impact teams
20% d'idées top down au total. Priorisation des idées via RICE
Tùches "Tech" représentent entre 20% de 50% de la roadmap. Politique zéro bug : 7 jours pour résoudre tout bug qualifié par la QA
Design : prototype non valide si 80% des utilisateurs n'ont pas réussi à naviguer correctement dessus
Stack outils, quelques exceptions : Storybook, Survicate
4 rituels Produit : Product Weekly, Product Breakfast, Product Dej, Product Party Manager
Utilisation de l'IA pour Discovery, Rédaction, Analyse de données
Principe important chez Partoo : la culture de la simplicité
â
Parties clés
Organisation & Structure dâĂ©quipe
Utilisez-vous les OKRs et dans quelle forme ?
Chez Partoo, lâĂ©quipe Produit utilise les OKRs Ă la fois Ă lâĂ©chelle collective et individuelle, structurĂ©s sur une base trimestrielle pour aligner leurs efforts avec leur stratĂ©gie globale.
OKRs collectifs
Au niveau de lâentreprise : Chaque trimestre, le COMEX dĂ©finit des OKRs d'entreprise qui reflĂštent leur stratĂ©gie globale. Exemple dâun OKR entreprise : âGĂ©nĂ©rer > 100k⏠via le lancement dâun nouveau produitâ
Au niveau des dĂ©partements : chaque dĂ©partement, y compris les Sales, le Customer Support, la Tech, les Ops et les RH, Ă©tablit des OKRs qui contribuent Ă atteindre les OKRs globaux de l'entreprise. Dans le dĂ©partement Tech (nldr : incluant le Produit), les OKRs sont dĂ©finis non seulement par Tribe mais aussi par mĂ©tier (engineering, data, product management, QA et design). Au sein de lâĂ©quipe Produit, les OKRs sont dĂ©finis par la Lead PM, les Engineering Managers, les Product Managers, les Leads Devâ et les dĂ©veloppeurs.
Exemples dâOKRs des Tribes :
"0% of mobile active users post on multiple platforms"
"3 live beta tests for a product have been performed"
"0 service desk tickets following Messages Import/Export refacto"
Exemples dâOKRs mĂ©tiers :
"Define a strategy to facilitate central/local collaboration"
"Central/Local vision has been illustrated through a prototype"
"Looker Studio connector has been released"
"Conduct Release quality analysis on 100% of Q3 releases"
OKRs individuels :
Chaque membre du personnel dĂ©finit des OKRs avec son manager pour le trimestre Ă venir, permettant un dĂ©veloppement personnel et professionnel alignĂ© avec les objectifs plus larges de l'Ă©quipe et de l'entreprise. Les OKRs individuels sont un mĂ©lange d'OKRs aspiratifs (visant des objectifs ambitieux) et d'OKRs dâengagement, assurant l'atteinte d'objectifs spĂ©cifiques et mesurables.
Exemples dâOKRs individuels :
"Conduct Root cause analysis on 70% of high-priority/critical Service desk bugs (tracked on Notion)"
"Coordinate Tribes efforts on app settings migration to new design (migration plan, teams alignment & commitment)"
"Create an interactive prototype of the Messages product that has been tested by minimum 30 persons at Partoo"
Au sein de lâĂ©quipe Design, chaque trimestre le Lead Product Designer et le Product Designer font le point sur les OKRs du trimestre passĂ© et sâalignent sur 3 Ă 4 OKRs pour le trimestre Ă venir.Â
Au-delĂ de permettre un suivi rĂ©gulier des progrĂšs et dâidentifier les challenges, la dĂ©finition dâOKRs stimule la motivation du Product Designer en donnant un sens Ă ses tĂąches quotidiennes et en montrant comment elles contribuent Ă des objectifs plus larges. Câest aussi lâopportunitĂ© parfaite de fixer des objectifs ambitieux qui encouragent les Ă©quipes Ă sortir de leur zone de confort et Ă dĂ©velopper de nouvelles compĂ©tences.
Comment vos équipes sont-elles organisées ? Cela a-t-il changé au fil des années ?
L'organisation de lâĂ©quipe Tech & Produit a trĂšs peu Ă©voluĂ© au fil des ans. Elle sâest bien agrandie mais conserve la mĂȘme structure organisationnelle. Actuellement, lâĂ©quipe est structurĂ©e en 4 Tribes. Chaque Tribe possĂšde une mission spĂ©cifique qui contribue au dĂ©veloppement continu du produit.
Chaque Tribe a sa propre mission et domaine de responsabilitĂ© qui soutient un aspect clĂ© de lâapplication. Cette structure permet Ă chaque Tribe de se concentrer sur des objectifs spĂ©cifiques, tout en collaborant Ă©troitement avec les autres Tribes pour assurer la cohĂ©rence et l'intĂ©gration du produit.
Le Lead PM et l'Engineering Manager de chaque Tribe travaillent de concert pour piloter les initiatives de leur Tribe. Ils veillent à ce que les équipes soient alignées sur la vision globale de l'entreprise et facilitent la collaboration entre les différentes Impact teams.
Au sein de chaque Tribe sont inscrites plusieurs Impact teams. Chaque Impact team comprend un PM et au minimum 3 développeurs, dont un Lead Developer. Cette configuration garantit que chaque équipe dispose de l'expertise et des ressources nécessaires pour mener à bien ses projets.
Cette organisation en Tribes et Impact teams permet Ă lâĂ©quipe Produit de Partoo de rester agile, d'innover rapidement et de rĂ©pondre efficacement aux besoins changeants des utilisateurs et du marchĂ©.
Les Ă©quipes Produit & Design font-elles partie de la mĂȘme organisation ? A qui les PM reportent ? Cela a-t-il changĂ© au fil des annĂ©es ?
LâĂ©quipe Design fait partie intĂ©grante de lâĂ©quipe Produit : chaque Product Designer est assignĂ© Ă une Tribe diffĂ©rente et travaille avec les 2 Ă 3 Impact Teams qui la constituent. Le Product Designer travaille ainsi en collaboration avec 2 Ă 3 Product Managers (chaque Tribe est composĂ©e de 3 PMs). Le reste de lâĂ©quipe Design (Motion Design, Marketing) est intĂ©grĂ© Ă lâĂ©quipe Produit mais nâa pas de rapport direct avec les Product Managers.
Lâorganisation nâa pas particuliĂšrement Ă©voluĂ© au fil des annĂ©es, hormis le nombre de Product Designers qui a augmentĂ©. Au tout dĂ©but, un seul Product Designer Ă©tait prĂ©sent et travaillait pour les 2 Impact Teams constituant lâĂ©quipe Produit. Aujourd'hui, 3 Product Designers sont rĂ©partis dans les 3 diffĂ©rentes Tribes. Chaque Product Designer est garant de son projet Web & Mobile, câest-Ă -dire quâil doit concevoir une mĂȘme solution pour les 2 appareils, et ainsi collaborer avec les PM Web & Mobile.
Planification Produit
Quelle % dâidĂ©es (approximatif) arrive âtop-downâ et quel % arrive âbottom-upâ ?
Chez Partoo, les Ă©quipes ont la possibilitĂ© dâexprimer leurs idĂ©es. Chaque Ă©quipe a lâopportunitĂ© de faire des Discovery sur les sujets qui lui semblent les plus pertinents sur la base des insights reçus mais Ă©galement sur la base des interviews (et/ou shadowing) qui sont rĂ©guliĂšrement menĂ©s par les Ă©quipes. Lâensemble des sujets sont ensuite scorĂ©s en suivant la mĂ©thode du RICE (Savinien en parle dans notre Ă©pisode de Clef de voĂ»te), ce qui permet dâalimenter les roadmaps dâune maniĂšre objective. Bien entendu, il peut arriver que certains sujets soient descendants (âtop-downâ) pour rĂ©pondre Ă des besoins stratĂ©giques. Mais ils reprĂ©sentent moins de 20% de la totalitĂ© des sujets.
Comment votre équipe évalue-t-elle les chantiers Produit et sait lorsque quelque chose est hors scope ?
Les insights provenant des Ă©quipes internes et des clients sont d'abord attribuĂ©s Ă une Tribe spĂ©cifique. Ces insights, créées sur JIRA ServiceDesk, se dĂ©versent dans Notion oĂč est rĂ©alisĂ©e l'attribution.
Ensuite, chaque Lead PM rĂ©partit sur un rythme trimestriel ces insights (dans Notion) entre les diffĂ©rentes Impact team de sa Tribe. Cela permet d'Ă©viter la rĂ©ception d'insights hors du champ d'action de son Ă©quipe. De plus, en triant les insights, chaque Product Manager met en lumiĂšre les principales thĂ©matiques des problĂšmes rencontrĂ©s par les clients. Ă partir de ces informations, une courte Discovery est rĂ©alisĂ©e, en s'appuyant non seulement sur les insights, mais aussi sur des benchmarks et des interviews rĂ©alisĂ©s au prĂ©alable. Une fois cette Discovery Ă©tablie, la problĂ©matique identifiĂ©e peut ĂȘtre attribuĂ©e Ă une nouvelle Ă©quipe en fonction des spĂ©cialitĂ©s de chacune dâentre elles.Â
Comment, en tant que Product Leader, équilibrez-vous les ressources entre le travail sur de nouveaux produits et la maintenance/les bugs ? Y a-t-il une rÚgle générale ou un systÚme ?
LâĂ©quipe Produit aborde cet Ă©quilibre de 2 maniĂšres :
Une planification stratégique :
Lors de la dĂ©finition de la roadmap produit, le Lead PM et l'Engineering Manager travaillent ensemble pour s'assurer que les Ă©quipes priorisent des tĂąches "Tech". Cela comprend des initiatives telles que les refactos et le clean du code, qui sont essentielles pour amĂ©liorer la qualitĂ© globale du produit. Ce type de tĂąches reprĂ©sente entre 20% et 50% de la roadmap Produit en fonction des pĂ©rimĂštres de lâorganisation. Cette intĂ©gration proactive de tĂąches techniques dans la roadmap garantit que la maintenance ne deviennent pas un fardeau secondaire, mais une partie intĂ©grale du cycle de dĂ©veloppement.
Une politique "zéro bug" :
Pour maintenir la qualitĂ© de lâapplication Partoo, lâĂ©quipe a mis en place une politique rigoureuse nommĂ©e âzĂ©ro bugâ il y a deux ans. Selon cette politique, tout bug qualifiĂ© par lâĂ©quipe QA, et ajoutĂ© au backlog, doit ĂȘtre rĂ©solu dans un dĂ©lai de 7 jours. Cela nĂ©cessite que chaque Ă©quipe alloue du temps dans ses sprints pour la maintenance. Lâobjectif Ă©tant dâaborder les problĂšmes le plus rapidement possible et dâĂ©viter quâils ne s'accumulent.
Ces approches permettent Ă lâĂ©quipe Produit de maintenir un Ă©quilibre sain entre l'innovation et la maintenance tout en sâassurant que le produit reste Ă la fois compĂ©titif et fiable.
Design
Qui assiste aux Design Reviews ? Qui les anime ? à quelle fréquence ?
Chez Partoo, le Design est validĂ© en plusieurs Ă©tapes :Â
Tout dâabord, les flows & wireframes sont rĂ©alisĂ©s par le duo Product Designer & Product Manager. Puis le parcours est validĂ© techniquement par le Lead Developer en charge du projet, ainsi que le Lead Product Designer, le Lead Product Manager et le CPO. Ce procĂ©dĂ© permet dâassurer Ă lâĂ©quipe quâelle rĂ©pond Ă la problĂ©matique initiale tout en construisant un parcours simple, intuitif et techniquement rĂ©alisable.
Une fois lâUX validĂ©e, le Product Designer passe Ă lâĂ©tape de maquette, conçue rapidement grĂące aux composants du Design System. Ces maquettes sont challengĂ©es par le Lead Product Designer, mais aussi par le Product Manager. Le CPO et le CEO peuvent Ă©galement donner leur opinion sur le rĂ©sultat final. Toutefois, câest au moment des tests utilisateurs (en interne avec les stakeholders ou en externe avec les clients rĂ©els) que la viabilitĂ© des maquettes est validĂ©e ou ajustĂ©e.
Lorsque tout est validĂ©, lâintĂ©gration des maquettes commence, et le Product Designer assure un recettage* auprĂšs des DĂ©veloppeurs pour vĂ©rifier que le rĂ©sultat final est identique aux maquettes.
*Le recettage est le fait de repasser sur toute l'application pour vérifier que le design développé est iso au design des prototypes.
Comment lâĂ©quipe Design sâassure que la solution proposĂ©e est optimale ?
LâĂ©quipe Design nâest jamais certaine Ă 100% que la solution est optimale. Mais tout au long de la conception, lâĂ©quipe :
Ăchange en interne & en externe pour vĂ©rifier le besoin et bien le comprendre
Analyse la concurrence et les applications les plus populaires pour suivre les standards UX
Conçoit des Flows & Wireframes pour valider l'UX en amont
Fait tester les prototypes pour valider le parcours et l'ergonomie
Un produit n'est pas validé tant que 80% des utilisateurs n'ont pas réussi à naviguer correctement sur le prototype et effectuer les missions demandées.
Avez-vous dĂ©jĂ Ă©tĂ© confrontĂ© Ă une situation oĂč des retours utilisateurs (ou donnĂ©es du marchĂ©) vous ont forcĂ© Ă complĂštement rĂ©ajuster votre approche Design ?
Les tests utilisateurs ont parfois rĂ©vĂ©lĂ© que la solution imaginĂ©e nâĂ©tait pas idĂ©ale. En cause, des :
Parcours trop longs : les utilisateurs abandonnaient avant la fin du prototype
Actions peu compréhensibles : les utilisateurs ne cliquaient pas sur les bons boutons et ne parvenaient donc pas à accomplir la mission demandée
Utilisateurs non satisfaits : il est arrivĂ© que ceux-ci trouvent lâUI trop chargĂ©e (information remontĂ©e via les commentaires) ou que la proposition ne rĂ©ponde pas Ă leur besoin, dans la mesure oĂč ils devraient rĂ©pĂ©ter lâaction Ă plusieurs reprises dans leur quotidien
Suite Ă ces retours, lâĂ©quipe Design a dĂ» retravailler les prototypes et, parfois, repenser lâintĂ©gralitĂ© du parcours. Ce fut par exemple le cas pour le projet âRĂ©ponse automatique aux avisâ oĂč les premiĂšres maquettes proposaient un long parcours de configuration et permettaient de distinguer visuellement les modĂšles manuels des modĂšles automatisĂ©s. En analysant les rĂ©sultats des tests, lâĂ©quipe a constatĂ© que les utilisateurs Ă©taient submergĂ©s dâinformations et ne comprenaient pas ce quâils Ă©taient en train de faire. La consĂ©quence a Ă©tĂ© de redĂ©finir la problĂ©matique, repenser tout le flow UX et imaginer un MVP rĂ©pondant aux besoins essentiels.
Spécifique à Partoo
Quelle est votre stack dâoutils au Produit ?
LâĂ©quipe Design travaille quotidiennement avec les outils suivants :
Whimsical, pour maquetter des premiers flows de réflexions ou réaliser des maquettes basse fidélité
Figma, pour concevoir les maquettes et le Design System
Maze, pour tester les prototypes auprĂšs des utilisateurs
Photoshop / Illustrator / InDesign, pour concevoir les documents de communication, les logos ou retoucher des images
Notion, pour documenter les processus de travail, les composants, planifier les projets, documenter les phases de Discovery et centraliser les retours clients
Storybook, pour centraliser les composants développés, partager les guidelines et effectuer le recettage graphique
Survicate, pour le suivi du NPSÂ
Hotjar et Google Analytics, pour le tracking
JIRA (Atlassian), pour le suivi de projets et la gestion des sprints
Typeform, pour la gestion des formulaires
Service Management (Atlassian), pour la gestion des anomalies
Looker Studio et Metabase, pour la data search et la dataviz
Datadog, pour monitorer et optimiser les performances de lâapplicationÂ
360 Learning, pour la formation des membres de lâĂ©quipe Produit.
Quels sont certains rituels uniques/fun de lâĂ©quipe Produit ou dans l'entreprise de maniĂšre gĂ©nĂ©rale ?
LâĂ©quipe Produit possĂšde de nombreux rituels visant Ă garantir Ă la fois une bonne connaissance mĂ©tier mais Ă©galement des moments de convivialitĂ© avec lâensemble de ses membres.
Product Weekly : ce rituel, qui se tient un vendredi sur deux, vise Ă partager des retours d'expĂ©rience (ex : lancement dâun nouveau produit, Ă©tude comportementale sur Hotjar), des travaux de discovery en cours, des stratĂ©gies de Tribe, et Ă inviter des intervenants extĂ©rieurs travaillant dans le domaine du Produit.
Product Breakfast : ce rituel bimensuel réunit toutes les équipes de Partoo et les équipes Tech (Produit + Engineering) autour d'un petit déjeuner. L'objectif est de permettre aux équipes Tech de présenter les projets à venir à l'ensemble des équipes internes, de se rendre disponibles pour échanger et de recueillir des insights, le tout dans un cadre convivial.
Product Dej : ce déjeuner mensuel rassemble tous les membres de l'équipe Produit afin de créer du lien et de favoriser les échanges entre eux.
Product Party Manager : chaque trimestre, 3 membres de l'Ă©quipe Produit peuvent se porter volontaires pour animer l'Ă©quipe. Leur mission est d'organiser des Ă©vĂ©nements conviviaux oĂč les Ă©quipes peuvent se rĂ©unir et passer du bon temps ensemble (par exemple, la chandeleur, des afterworks, des soirĂ©es cinĂ©ma, etc.).
Utilisez-vous lâIA dans votre pratique du Product Management ? Si oui, comment ?
LâĂ©quipe Produit de Partoo a adoptĂ© lâIA dans sa pratique quotidienne :
Discovery : lâIA leur permet de challenger leurs raisonnements et de vĂ©rifier la pertinence des questions posĂ©es (via ChatGPT)
Insights : pour rĂ©cupĂ©rer rapidement des enseignements clĂ©s sur le transcript dâune conversation entre un client et un CSM, sur un appel dâoffre, une vidĂ©o Youtube ou un article (rĂ©alisĂ© via Briefly)
Rédaction : pour reformuler, traduire, mettre en forme du texte (Compte rendu, feedback etc..)
Analyse : Pour trouver une formule SQL ou Excel plus rapidement
LâĂ©quipe de Partoo a Ă©galement son propre outil de documentation basĂ© sur IA. Cette plateforme permet la crĂ©ation de GPTs et est branchĂ©e au Slack de Partoo. Elle permet de prompter ChatGPT directement dans Slack afin de tout centraliser au mĂȘme endroit (voir screenshot ci-dessous).
Y a-t-il quelque chose d'unique dans la maniÚre dont le Produit envisage le développement Produit ?
Au dĂ©but de chaque projet, lâĂ©quipe Produit accorde une importance particuliĂšre Ă imaginer "une vision" lors de la phase dâexploration. Cet exercice consiste Ă projeter les prototypes et les scĂ©narios Ă long terme sans se soucier de l'UX/UI ou de potentielles contraintes techniques. Cette initiative a pour effet de :
Stimuler la réflexion critique
Concevoir les produits de maniÚre évolutive
Engager les équipes
Fixer des objectifs clairs.
Cette pratique sâest rĂ©vĂ©lĂ©e ĂȘtre une mĂ©thode efficace pour anticiper et discuter des futurs possibles, renforçant ainsi la confiance des Ă©quipes envers leurs solutions.
Un principe fort chez Partoo est la simplicitĂ© (on en parle sur Clef de voĂ»te avec Savinien). Tous les jeudis matin, les Ă©quipes qui le souhaitent peuvent rencontrer le CEO et le CPO sur une session de 1h nommĂ©e âPrĂ©sentation / Prise de dĂ©cision Produitâ pour challenger leurs maquettes de vision ou dâautres chantiers plus avancĂ©es sur le Delivery par exemple.Â
Quelques exemples de sujets adressĂ©s par le passĂ© pendant ce rituel :Â
"Présentation d'un nouveau flow d'onboarding"
"Présentation de la validation des fiches Google sur mobile"
"Présentation de la nouvelle page de settings"
"Présentation de la vision du produit Messages"
"Présentation des résultats de l'intégration d'IA dans notre produit de Review Management"
đ« 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é