Product Inbox 📬 Focus #11 - Comment construire sa roadmap produit
Par des PM de Libeo, Mym, Sendinblue, Thiga, Inato...
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 11ème édition Focus de Product Inbox ! On est désormais 6524 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 :
Trouver ta prochaine aventure Product avec notre programme Stellar
Faire décoller ta progression via notre programme de mentoring
Lire les éditions précédentes de Product Inbox
Écouter mon podcast Clef de voûte
Me suivre sur Linkedin
Introduction
J’espère que tout roule pour toi !
Je suis super content de t’envoyer cette nouvelle édition Focus.
Et pas pour rien.
Ça fait des semaines qu’on la prépare avec la core team…
Et je ne vais pas te mentir :
Elle nous a posé plus de difficultés que prévu. 😅
En soi, le sujet n’est pas nouveau. Mais beaucoup plus technique qu’il n’y paraît.
En parlant à des centaines d’équipes Produit, j’ai constaté que nombreuses sont celles qui ne remettent jamais en question la manière de construire leur roadmap.
Pourtant, beaucoup d’équipes :
Ne la construisent pas correctement
Ne l’utilisent pas à bon escient
Ne la font pas évoluer
Et ça peut avoir un impact majeur sur une boîte.
Alors j’ai eu envie de creuser ces problèmes.
Pour ça, on a invité pas moins de 12 Product Managers à partager leur retour d’expérience 🤩.
J’ai nommé 🥁 :
François L'Hostis, Head of Product chez Groupe La Centrale
Marc-Antoine Porri, Product Manager chez Bonitasoft
Baptiste Salbot, Senior Product Manager chez Hiboo
Laurent Prost, Product Manager chez Alice&Bob
Louisa Berthomier 👟, Product Leader freelance
Antoine Lancesseur, Lead PM chez BlaBlaCar
Michaël Bastien, Product Ops chez Brevo
Nicolas ADAM, ex CPO chez TheTribe.io
Anne-Sophie Corbeau, CPO chez Libeo
Charline Bestard, Lead PM chez Elevo
Quentin Bodinier, Lead PM chez Inato
Clément Paillasse, Product Coach
Je tiens également à remercier ma core team sans qui je n’aurais pas pu produire cette édition aussi efficacement : Sandy, Hassan, Guillaume. Vous êtes au top 💛.
Pour réaliser cette édition, j’ai posé 5 questions à mes invités :
Qu’est-ce qu’une roadmap ? Quel est son objectif ?
Qui définit la roadmap et quelles sont les étapes de sa création ?
À quelles parties prenantes partager la roadmap et par quels moyens ?
À quelle fréquence et comment itérer sur la roadmap ?
Quels sont les principaux écueils à éviter lors de la création de la roadmap ?
TL;DR 🧠
Roadmap ≠ Release plan. Elle évolue en continu. La clé ? La structurer en “Now/Next/Later”.
Certaines parties de la roadmap sont nourries par le leadership. D’autres, par les équipes opérationnelles (Product, Tech, Sales, CX).
Elle est partagée dans toute l’entreprise via meetings et outil. Et en externe via roadmap publique.
Elle est souvent mise à jour au trimestre ou en continu. Certaines parties sont mises à jour mensuellement.
Éviter de dissocier roadmap technique et produit. Utiliser au maximum la data pour la construire. Ne pas remplir la roadmap avec des solutions.
1/ Qu’est-ce qu’une roadmap ? Quel est son objectif ?
Antoine Lancesseur, Thiga
La première confusion est souvent la différence entre roadmap et release plan.
Et c'est d'ailleurs un de nos combats historiques chez Thiga.
Une roadmap se compose d’opportunités et non de features.
Une feature est “Done” quand elle est livrée.
Une opportunité est “Done” quand on a atteint le KPI cible. Chaque opportunité est rattachée aux OKRs de l’équipe.
Une roadmap se découpe par intervalles de temps qui suivent le principe du cône d’incertitude. Plus on est dans le futur, plus il y a d'incertitudes.
Chez Thiga on préconise souvent le “Now/Next/Later” :
Le “Now” couvre le prochain trimestre.
Le “Next” les deux suivants.
Le “Later” s’inscrit dans un horizon plus éloigné.
La différence entre la roadmap et un release plan : la roadmap est plus orientée “Outcome” et le release plan “Output”.
Michaël Bastien, Sendinblue
Chez Sendinblue, la roadmap est une liste priorisée d'initiatives que les équipes adressent. Chaque initiative a pour objectif d'impacter positivement la stratégie Produit. Chacune résout un problème utilisateur avéré en développant la bonne solution.
"Nous souhaitons aller d'un point A à un point B” → la stratégie
“Voilà comment nous pensons y arriver” → la roadmap.
Et comme tout itinéraire, il se peut qu'il y ait des changements en cours de trajet. Il faut l'accepter et le faire accepter.
Pour cela, nous avons récemment fait le switch d'une roadmap au trimestre à une roadmap "continue”, au format Now/Next/Later : les équipes peuvent communiquer avec précision sur ce qu'elles font maintenant, savent ce qu'elles vont faire ensuite et probablement ce qu'elles feront plus tard.
François L’hostis, Unify
C’est à mon sens un très bon outil de communication pour le produit, il permet de (se) poser les bonnes questions sur les priorités, de matérialiser des ambitions et de suivre l’atteinte des objectifs que l’on s’est fixés sur une période moyen terme. Depuis 1 an on s’efforce également d’y faire figurer les projets en discovery. C’est également un bon outil pour l’entreprise au global car elle apporte de la lisibilité, de l’engagement sur la réalisation des projets prioritaires.
Baptiste Salbot, Hiboo
La roadmap permet de formaliser une intention et d'aligner les équipes (Produit et Business) derrière cette intention.
Fondamentalement la roadmap représente l’intention que porte une équipe Produit pour atteindre une vision de manière structurée. Cette intention permet une priorisation claire.
Quentin Bodinier, Inato
La roadmap est, par essence, un objet mouvant qui est constamment remis en cause.
Sur chacun de nos scopes Produit, c’est :
Une vision claire de l’impact désiré à 3-4 mois, matérialisée par :
Des objectifs clairement définis sur des KPIs précis.
Un concept early stage qui permet à toutes les parties prenantes de visualiser le point d’arrivée idéal.
Une définition du prochain “pari” que l’on va tester:
Ce sur quoi on va passer le prochain mois, avec des premières maquettes.
Un rationnel expliquant clairement pourquoi c’est la bonne prochaine étape dans la direction de notre vision à 3-4 mois.
Les métriques de succès que l’on se fixe.
Nicolas Adam, theTribe
J'ai l'habitude de dire qu'avant tout, une roadmap doit raconter une histoire.
Cette histoire est le socle de la roadmap et son contenu doit être la stratégie pour y arriver en :
Définissant les hypothèses : les actions / initiatives / fonctionnalités possibles et qui semblent avoir le plus d'impact
Le séquencement des objectifs : Sur quoi devons-nous nous focaliser dans un premier temps, dans un 2-3ème temps ?
Les moyens pour valider que nous sommes proches ou dans le bon chemin pendant la route : les metrics de succès intermédiaires
Les suites potentielles si les hypothèses prouvent leur efficacité en situation réelle ou non : aller plus loin dans l'initiative actuelle, lancer une nouvelle ou pivoter sur une autre hypothèse
Pour appliquer ces grands principes, on peut utiliser des outils conversationnels utiles comme le Lean UX Canvas, les OKR's, la Outcome Based Roadmap, le Story Mapping, l'Impact Mapping ou la Goal Oriented Roadmap.
2/ Qui définit la roadmap et quelles sont les étapes de sa création ?
Marc-Antoine Porri, Platform.sh
C’est un travail collectif qui n'implique pas que les Product Managers.
Dans un premier temps, le board (C-levels) décide des objectifs business et d’une stratégie Produit globale, contenant plusieurs grands périmètres comme le développement de certaines de nos offres ou l’amélioration de l’onboarding.
Ensuite, l’équipe Produit va construire la roadmap du premier semestre :
Pour chaque périmètre, les PM et Leaders Produit définissent les features sur lesquelles concentrer leurs efforts pour s’aligner au mieux avec la stratégie. Ces features peuvent provenir du backlog des features en cours de développement ou des nouvelles features.
Les PM définissent ensuite une chronologie. Par exemple : features A et B pour le premier trimestre. Puis les features X et Y pour le second, etc.
Une dernière revue est organisée avec les équipes Engineering et Design pour confirmer la cohérence de la roadmap (et la challenger), sa faisabilité, la disponibilité des équipes et la répartition de la charge de travail.
Nous reprenons le même exercice pour la roadmap du second semestre.
Création de la roadmap chez Platform.sh
Antoine Lancesseur, Thiga
La définition de la roadmap est de la responsabilité du Product Manager, à hauteur de son périmètre produit. Elle est ensuite présentée et validée par le manager de l’équipe Produit. Ce dernier est responsable de la cohérence des roadmaps de ses équipes et de l’alignement avec la stratégie Produit (et d’entreprise).
Les étapes de création sont :
Définition des OKRs du périmètre de l’équipe, en lien avec les OKRs du produit et de l’entreprise.
Collecte des besoins des stakeholders (dont la tech). Quelles sont leurs attentes envers l’équipe Produit pour qu’ils puissent atteindre leurs propres objectifs ?
Collecte + analyse des feedbacks utilisateurs et des données d’usage afin d’en extraire les opportunités Produit.
Formalisation des opportunités prometteuses pour atteindre les KRs :
Identification via différents canaux (user research, impact map workshops, besoins stakeholders)
Formalisation au travers d’un Canva. Le format évolue d’un client à l’autre, mais les dimensions clés sont celles du “Lean Canva”.
Prioriser les opportunités entre elles au travers d’un framework type RICE, qui a l’avantage de prendre en compte le “Reach” et la “Confiance”. Ce qui n’est pas le cas de la plupart des frameworks. J’essaie d’avoir 5 critères d’impact maximum pour que l’exercice de priorisation ne soit pas trop complexe non plus.
Process de création de roadmap chez Thiga
Anne-Sophie Corbeau, Libeo
Il y a 2 niveaux de roadmap chez Libeo :
Le niveau Leadership Produit (Heads of Engineering & Product) traduisant la stratégie Produit et positionnant des initiatives stratégiques dans un horizon de temps de 18 mois à 3 ans afin d’atteindre la vision produit.
Le niveau opérationnel (des équipes Produit) définie tous les 3 mois. Ce sont ces dernières qui définissent leur roadmap en autonomie dans un contexte stratégique donné.
Pour cette seconde roadmap, les grandes étapes sont :
Définition des OKRs Libeo (par le leadership)
Déclinaison en Product Outcome-North Star pour chaque team Produit (par le leadership)
Ateliers avec les stakeholders (sales + CX) pour les pousser à prioriser leur besoin produit (par les Product Managers)
Identification et priorisation des opportunités répondant à ces enjeux (par toutes les équipes Produit)
Sizing et repriorisation (tous les PM + la tech)
Validation en Product Committee.
À savoir que chaque roadmap se divise en 2 : delivery et discovery.
Louisa Berthomier, Mym
Chez Mym, la roadmap est définie collectivement mais c’est le produit qui est en charge d’orchestrer et d’aligner tout le monde autour d’une vision commune.
On peut visualiser la roadmap comme un champ à cultiver et où les features sont des plantations. Les idées de features sont comme des graines de différentes provenances (la recherche utilisateur, le comité de direction, le service client, etc.) et la vision Produit est le terreau.
Chez Mym, la boîte est de taille moyenne (50 personnes). On peut se permettre de s’en tenir à une seule étape “ritualisée” qui est la roadmap au trimestre. Évidemment, un gros travail de fond de discovery et d’alignement des stakeholders est fait en amont.
Quentin Bodinier, Inato
La bonne profondeur de roadmap dépend directement du degré de certitude dont on a besoin. Pour choisir la bonne roadmap, la bonne réponse n’est pas d’appliquer un framework tout fait, mais de réfléchir aux problèmes spécifiquement liés à notre contexte, puis de résoudre ces problèmes.
3/ À quelles parties prenantes partager la roadmap et par quels moyens ?
Marc-Antoine Porri, Platform.sh
La roadmap est définie et mise à jour sur Productboard. C’est l’outil qu’on va principalement utiliser pour mettre à jour, communiquer et présenter la roadmap.
Tous les mois : les PM échangent avec les équipes Sales, Customer Support, Marketing, etc. On y fait le point sur la roadmap, ses changements, les features déployées, et celles à venir prochainement.
Toutes les deux semaines : les PM se réunissent avec l’équipe Engineering pour parler des blocages et problèmes qui pourraient impacter les dates de livraison et la roadmap.
Il y a aussi d’autres réunions, au cas par cas. Par exemple, lorsqu'on travaille avec les équipes marketing sur le plan de communication, on leur partage la roadmap et on voit ensemble quand et comment communiquer sur les features.
Mais la roadmap n’est pas destinée qu’en interne ! Productboard permet également de publier une roadmap publique, accessible à n’importe qui.
De cette manière, nous assurons une communication la plus transparente possible auprès de nos clients et prospects.
Antoine Lancesseur, Thiga
On partage la roadmap à l’équipe (développeurs, data, design) pour les engager dans “ce qu’on va faire” et “pourquoi on doit le faire”.
Mais aussi aux parties prenantes qui attendent des outputs de notre part pour réaliser leurs propres activités, afin qu’ils sachent sur quoi nous allons (ou n’allons pas) travailler.
La roadmap est aussi partagée aux décideurs afin qu’ils sachent sur quoi nous allons (ou n’allons pas) travailler. Ils peuvent ainsi relever toute objection.
On leur présente le Release plan à tous les sprints et la roadmap tous les mois.
Clément Paillasse, CPO Freelance
Les premiers concernés sont les personnes impliquées au quotidien dans sa réalisation : la squad et ses principaux stakeholders. Ils ont normalement tous participé à sa définition, et ne devraient pas la découvrir lorsqu’elle sera partagée plus largement aux autres équipes et au management (cela paraît évident, mais ce n’est pas le cas partout).
Un point trimestriel de 15 à 30 minutes par squad reste souvent la meilleure façon d’expliquer votre roadmap et d’adresser les questions!
Multiplié par le nombre d'équipes, cela peut représenter une durée conséquente dans les grosses organisations. Cet exercice de transparence permet cependant de garantir l’alignement et d’économiser beaucoup de temps ensuite.
Le format de votre roadmap véhicule également un message. Jeff Gothelf explique parfaitement les avantages d’une roadmap centrée sur l’impact plutôt que sur les features dans cette vidéo.
Anne-Sophie Corbeau, Libeo
La roadmap produit est partagée à tous, mais dans des degrés de complexité différents selon l’interlocuteur. Pour la roadmap opérationnelle des équipes Produit, elle est d’abord partagée sous sa forme détaillée (opport, scope, sizing, timing) au leadership Produit et aux Business Lines Manager pour validation. Chez Libeo on s’engage sur des milestones formulés comme une valeur créée, pas sur le fait de shipper une fonctionnalité à une date donnée. Une fois validée, la roadmap est partagée sous une forme vulgarisée et didactique à tout Libeo lors d’un meeting dédié de 30 minutes. L’objectif est de créer de l’excitation autour de cette roadmap et de ce qu’elle va permettre d’atteindre. Chaque roadmap d’équipe est ensuite repartagée, en détail, par le PM dans son “stakeholders meeting” bimensuel où ses parties prenantes clefs jouent le rôle de référent produit pour leur métier (Sales, Care, CX, etc.).
Louisa Berthomier, Mym
La roadmap est partagée en 3 vagues : d’abord au comité de direction (fondateurs, CMO, Chief Success, Chief Legal etc), puis à toute la tech (qui inclut le produit et le design), et enfin à toute la boîte !
On utilise une grosse table Notion qui est notre source de vérité pour la définition et l’avancement de la roadmap au global.
Et chaque trimestre on crée une timeline sur Figma pour aller davantage dans le détail, notamment des dépendances techniques entre les différentes squads :
4/ À quelle fréquence et comment itérer sur la roadmap ?
Antoine Lancesseur, Thiga
L'exercice de roadmapping devrait être un exercice quasi-continu. Au moindre changement de contexte, dans le cas contraire, la roadmap volerait en éclat.
La pérennité d’une roadmap réside dans sa structure. Quel que soit l’outil utilisé, il faut qu’on puisse faire évoluer une de ses dimensions (KR, opportunité, horizon de temps) sans avoir à tout reprendre à zéro.
Les éléments déclencheurs de la mise à jour de la roadmap sont :
Une nouvelle opportunité ultra-prioritaire qui vient d’apparaître et qui s’ajoute au Now ou au Next.
À la revue des OKRs de l’équipe (tous les mois) on se rend compte qu’on dévisse sur un périmètre sur lequel il faut réagir rapidement.
On arrive à la fin du trimestre et il faut redéfinir le périmètre du Now, du Next et du Later.
On arrive à la fin du semestre (ou de l’année) et on vient de redéfinir les OKRs de la prochaine période.
Marc-Antoine Porri, Platform.sh
Chez Platform.sh, chaque vendredi, tous les PM publient un compte rendu des avancements, retards, risques, sur chaque feature sur lesquelles ils travaillent. De ce fait, l’ensemble de l’équipe a une vision globale de la bonne tenue (ou non) de la roadmap, et s’il y a besoin de l’ajuster. Si on voit par exemple qu’une feature prend trop de retard et risque de compromettre la roadmap, on décide des mesures à prendre : appeler du renfort, faire un point sur les besoins et le reste à faire, déprioriser la feature, etc.
Il faut aussi tenir compte de l’imprévu ! La stratégie peut être ajustée en cours d’année pour différentes raisons, et c’est aussi notre rôle de PM d’évaluer comment la roadmap va être impactée.
Clément Paillasse, CPO Freelance
Une mise à jour trimestrielle convient généralement à la plupart des organisations et présente de nombreux avantages :
Assurer le focus de l’équipe en la protégeant des re-priorisations trop fréquentes.
Donner suffisamment de temps pour creuser un problème, tester une ou plusieurs opportunités et commencer à mesurer un impact.
Être aligné avec le rythme des autres départements qui ont souvent des objectifs trimestriels.
Au-delà de donner une occasion de communiquer à l’ensemble de la boîte, la revue trimestrielle est le moment idéal pour prendre du recul et se poser quelques questions. A-t-on livré l’impact attendu ? Décide-t-on de poursuivre ou d’arrêter nos efforts sur ce problème ? Nos enseignements ou l’évolution du marché nous amènent-ils à prioriser de nouveaux sujets ?
Anne-Sophie Corbeau, Libeo
Les équipes Produit proposent une nouvelle roadmap tous les 3 mois mais ils itèrent sur la roadmap en cours à la maille mensuelle, lors d’un meeting dédié, réunissant les parties prenantes clefs et le leadership produit. Dans ce meeting les équipes Produit rendent des comptes sur l’atteinte de leurs objectifs et proposent des évolutions potentielles de leur roadmap pour mieux y répondre, si jugé nécessaire. La roadmap stratégique traduisant la stratégie Produit est revue tous les ans par le leadership Produit au regard des évolutions du marché et des chiffres du BP ou si la vision / la stratégie de la boîte change par ailleurs.
Louisa Berthomier, Mym
Chez Mym on prépare la roadmap trimestre par trimestre, même s’il arrive que les choses ne se déroulent pas comme prévu (ou qu’une priorité vienne s’intercaler en cours de route).
Nicolas Adam, theTribe
À mon arrivée chez Chronotruck j'avais défini, avec les co-fondateurs, l'objectif principal sur lequel ils voulaient travailler dans les 6 prochains mois. On a mobilisé la moitié des équipes de la boîte pour travailler sur un Impact Mapping pendant une après-midi pour faire éclore un ensemble de bénéfices et de pistes de solutions pour les clients.
Après cette journée, on avait constitué une équipe discovery pluridisciplinaire qui représentait tous les métiers de la boîte. On avait priorisé toutes les initiatives selon une matrice Impact/Effort.
Toutes les semaines, le lundi, on prenait un temps de recul sur les apprentissages des semaines passées (Data, Users ou ateliers) et on repriorisait les initiatives qu'on allait, soit investiguer, abandonner ou détailler pour partir dans un dev qui prendrait moins de 2 semaines.
5/ Quels sont les principaux écueils à éviter lors de la création de la roadmap ?
Michaël Bastien, Sendinblue
Le fait de distinguer "roadmap produit" et "roadmap technique" : au final les équipes qui vont s'en occuper sont les mêmes et ça traduit bien le manque de lien qui peut exister entre tech et produit dans certaines organisations.
Ne pas faire de pédagogie sur ce qu'est une roadmap : une organisation est prête à comprendre que la roadmap est un "snapshot" de notre plan à un moment donné et non quelque chose de figé dans le marbre. Ce que va attendre le reste de l'organisation en contrepartie, c'est une communication fréquente et anticipée des évolutions, que ce soit concernant les dates de release ou les choix ou non de continuer sur un projet.
L'incapacité à porter et à scénariser sa roadmap. Sans data, sans recherche utilisateurs, sans de bonnes skills de communication, il est compliqué de justifier ses choix devant le top management. Les trois sont indispensables car, après tout, la roadmap est un support de communication.
Quentin Bodinier, Inato
En B2B avec des grands comptes où le cycle de vente est long, il m’est arrivé que l’équipe Sales ait besoin de s’engager sur la livraison d’une fonctionnalité très longtemps en avance, ce qui a un impact à long terme sur la roadmap. Si ce genre de situations se répète souvent, on a vite fait de passer d’une roadmap produit à une liste de features qui n’en finit pas de grandir.
Les clés pour sortir de ce genre de situation sont à mon sens :
Réduire l’engagement sur des features spécifiques. Et essayer de remonter avec l’équipe Sales au besoin sous-jacent.
Accepter que ce type de demande est inévitable. Pour éviter la frustration de l’équipe, il est crucial de bien communiquer sur la valeur business de la feature, même si elle n’a pas suivi un processus classique de discovery.
Charline Bestard Elevo
Un des problèmes de la roadmap classique c'est de communiquer une liste de solutions. Il faut au maximum communiquer sur des problématiques qu’on veut adresser. Communiquer sur des solutions c'est prendre le risque de vendre une feature qui ne sera peut-être pas la plus efficace face au problème.
Et c’est là tout le challenge en B2B.
Comment je fais comprendre à mes clients que la fonctionnalité qu’il souhaite ne sera peut-être pas la meilleure solution à son problème ?
Il faut au fur et à mesure faire évoluer cette manière de penser, d’où la notion importante d’évangélisation dans notre métier. On doit rassurer nos clients quant à la prise en compte de leur besoin tout en leur expliquant qu’il est nécessaire de creuser le problème pour y apporter la meilleure solution.
Nicolas Adam, theTribe
Je crois que le premier piège est de ne pas créer le socle nécessaire de contexte et de ne pas chercher à mesurer rapidement l'impact de ce qui est produit, c'est le meilleur moyen de s'enfermer dans l'usine à features.
Le 2ème est de ne pas créer une vraie dynamique d'équipe autour de la construction de la roadmap. L'ensemble des parties prenantes est compétent pour l'accompagner.
Et le dernier piège : s'enfermer dans un plan trop défini en pensant qu'il va se passer comme prévu et qu'il va être une réussite. Le meilleur moyen est de se poser la question "Comment savoir si ce que nous pensons développer va être un échec ?". Cela pousse à mesurer l'impact des features, à prioriser au maximum et à séquencer les fonctionnalités pour ne pas chercher à les déployer dans sa globalité, mais plutôt incrément par incrément.
7/ Pour aller plus loin
Mission → Vision → Strategy → Goals → Roadmap → Task, Lenny Rachitsky
Roadmap review template, par le VP Product de Figma
Comment construire sa vision produit, Product Inbox
7 examples of excellent product roadmaps, ProductBoard
Roadmap Template - Andrew Chen, Partner @Andreessen Horowitz
💫 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 12 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 (Zeliq, Edusign, Predict4health, Jaji,…).
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 🙏
À dans 15 jours pour la prochaine édition 🙏
Timothé