Malt et Jobteaser racontent leurs Impact Teams

Après avoir (longuement) parlé des impact teams chez  MeilleursAgents, on remet le couvert avec les études de cas de Malt et Jobteaser, en 8 questions.

⌛ 15 minutes de lecture sans jeter l’éponge

 ✉️ Article issu du Ticket n°13 – Mis à jour le 26 mai 2024

---

Les 8 questions sur les Impact Teams de Malt et Jobteaser :

1- Les Impact Teams : une réponse à quels problèmes ?

2- Les Impact Teams, comment ça marche en termes d’organisation ?

3- Comment fait-on sa roadmap en Impact Teams ?

4- Quel est le rythme des rituels en impact teams ?

5- Comment trouver le temps de faire de la Discovery en Impact Team ?

6- Quelles compétences en Discovery sont-elles nécessaires ?

7- Quels sont les avantages de passer en Impact Teams ?

8- Quels sont les points de vigilance à garder en tête en Impact Teams ?

---

Le 10 février 2021, Johan Aradan, l’ex VP product de Malt aujourd’hui VP Product et Design d’Ornikar, expliquait dans cet article Medium comment la plateforme de mise en relation entre entreprises et travailleurs indépendants (240 000 freelances inscrits), était passée, en fin d’année dernière, des features teams à une organisation “centrée business, orientée outcomes et privilégiant la discovery”. Aux impact teams en somme.

Fin 2019, dans cette conf’ LPCx, l’équipe de Jobteaser, boîte qui fournit des solutions de recrutement et marque employeur aux entreprises pour embaucher des jeunes talents, présentait, elle, son modèle “à l’américaine” qui succédait à “l’usine à features” d’auparavant. Des impact teams en somme.

Aujourd’hui, sur Le Ticket, on revient sur les grands principes de leurs organisations respectives. En 8 questions. Pour te faciliter la compréhension en somme.

1- Les Impact Teams : une réponse à quels problèmes ?

Évidemment, dès qu’on parle de changement d’orga, la première question qui se pose c’est… pourquoi ? Autrement dit : qu’est-ce qui ne marchait plus et, surtout, à quels enjeux les impact teams devaient répondre ?

Chez Malt, l’orga en feature teams, qui avait tout de même permis d’arriver à une équipe produit / tech de 65 personnes pour 6 squads, commençait à se rigidifier. En gros, à devenir plus orientée “projet” que “produit”. Voici quelques symptômes de ce terrible mal qui guettait:

• Une roadmap de plus en plus hiérarchique (top-down)

“On faisait une roadmap et, parfois, on se rendait compte que tel ou tel sujet n’avait finalement pas tant de levier que ça et que cela ne méritait peut-être pas tant d’effort. Mais, entre-temps, tu avais mis en place l’équipe. Ça créait donc naturellement du stress et de l’inconfort”, explique Johan Aradan en interview au Ticket.

• Des effets tunnel

“Quand une squad travaillait sur un sujet, généralement, on ne voyait pas de release avant 3 mois. Ce n’était pas très lean. Tu n’es pas dans ce côté “urgence business””, ajoute-t-il. 

• Un manque d’ownership

Avec des équipes qui passent de fonctionnalités en fonctionnalités. D’où une certaine confusion en interne, matérialisée par la question qui devenait récurrente : qui est responsable de cette partie ? “On passait beaucoup de temps sur un sujet. Puis, après, on abandonnait le projet et les parties prenantes, qui se retrouvaient alors sans PM à qui s’adresser. Et personne ne suivait les KPI du projet en question,” témoigne Yasmina Hamada, PM chez Malt. Cette dernière, par exemple, avait passé plusieurs mois sur un produit intitulé Malt Plus (dont on va reparler), avant de basculer sur un projet de CRM pour la communauté… puis de revenir sur Matl Plus six mois plus tard !

• Sans oublier en effet l’absence d’amélioration continue

…pour faire en sorte que ces fonctionnalités lancées… marchent vraiment ! “On était sans cesse coincé à courir derrière la killer feature d’après…”, décrit Johan. 

Illustration concrète. L’an passé, Malt lance un produit qui permet aux grandes entreprises qui ont plusieurs divisions (donc plusieurs comptes sur Malt) d’avoir un tableau de bord centralisé pour faire un suivi de tous ces comptes.“On l’a créé à la demande des clients… puis on est passé à autre chose, raconte Johan.

« Sauf qu’on s’est rendu compte que l’utilisation n’était pas si importante que cela… mais les clients et les équipes internes continuaient à nous demander beaucoup d’améliorations dessus ! Si tu ne prends pas de recul, tu peux continuer à chercher à ajouter des fonctionnalités en te disant que c’est ce qui te permettra d’avoir plus d’usage. L’exemple typique du produit que tu veux densifier en fonctionnalités avant même de voir son positionnement et la valeur qu’il apporte aux utilisateurs.”

La rencontre d’un rêve et d’un contexte chez Jobteaser

En arrivant chez Jobteaser, en juin 2018, en tant que Chief Product Officer (CPO), Arthur Rougier, lui, commence par échanger avec de nombreuses personnes de l’équipe. Ce qui revient très fréquemment ? Le manque de mesure des actions effectuées (le côté data-driven si tu préfères) et l’accroissement naturel du produit, sans jamais rien n’enlever (avec le risque de créer une sorte de Frankenstein).

Sachant que dans ses expériences préalables, aussi positives soient-elles (chez les entreprises Dashlane et Papernest), Arthur avait été marqué par la frustration du PM à faire du “cycle en V”. Autrement dit : prévoir en chambre un produit, plancher des mois pour le sortir puis… passer à autre chose, sans avoir le temps d’en mesurer le résultat concret !

Le pilotage par des indicateurs, qu’il découvre en s’inspirant des pratiques appliquées aux Etats-Unis, lui semble plus judicieux. Cette organisation “rêvée” commence à mûrir dans sa tête.

Par chance, le contexte du moment à Jobteaser se prêtait bien à l’application de ses convictions. Jusqu’alors, la roadmap était très claire et le modèle en feature teams avait permis de livrer des tonnes de fonctionnalités.

“Mais à un moment, tu arrives un peu au bout du problème que tu veux résoudre avec ta solution. Il faut donc revenir à un mode où tu dois te reposer des questions, aller comprendre d’autres problèmes, inventer des choses nouvelles et donc apprendre à te diriger autrement”, résume Arthur.

Point important : ce dernier tient à citer la confiance accordée par les fondateurs dans cette transition, condition sine qua non à sa mise en place. “Les impact teams, pour eux, ça veut dire que tu ne peux plus venir le matin avec une idée de feature à développer que tu as eu sous ta douche. Il faut accepter de perdre pas mal de pouvoir décisionnel…”

Pivot !

On a en mémoire les mots de Christopher Parola, dans l’article sur la création des Impact Teams chez Meilleurs Agents: “Il n’y a pas de meilleur moment pour changer une organisation que quand elle commence à craqueler…”

Chez Malt, la goutte d’eau vient peut-être, en l’occurrence, de l’équipe de développeurs volants qui avaient été mises en place un an plus tôt. Leur mission : voler au secours des trous dans la raquette, les bouts du produit qui n’étaient pas gérés par des squads. Sauf que plus on lance de fonctionnalités, plus il y a de code à maintenir…

“Arrive un moment où cette équipe était complètement cramée. On arrivait face à un mur,” témoigne Johan. “On ne peut plus continuer comme ça”, lance alors Benoit (Guillon), le nouveau VP engineering arrivé en février. “Les planètes étaient donc alignées avec une envie commune au produit, à la tech et au design. C’est un point important car tu ne peux pas y arriver si l’impulsion ne vient que du produit,” précise Johan. 

Un manuel d’une quarantaine de pages sur la vision globale de la future organisation est transmis aux équipes en octobre. Des ateliers ont lieu en novembre pour définir les Tribes. Et en décembre… En avant Guingamp !

2- Les Impact Teams, comment ça marche en termes d’organisation ?

“Désormais, la seule définition d’une équipe est devenue son indicateur, répond Arthur de Jobteaser. C’est sa raison d’être. Elle n’a plus de périmètre fonctionnel et peut toucher à n’importe quel endroit du produit pour l’atteindre”.

Le découpage se fait ainsi de manière assez naturelle. “En 2018, on a couplé le passage en impact team avec la mise en place des OKR. Le comité de direction a établi 5 résultats clés (KR) à viser au produit sur une année… qui sont devenus mes 5 squads produit !”, poursuit-il. Précisons que ces “squads” sont des sous-équipes qui font elles-mêmes partie de 2 Tribes correspondant au modèle d’affaires de Jobteaser (grosso modo B2B et B2C, les universités/écoles/entreprises et les étudiants).

Chez Malt, la division des équipes se fait aussi en fonction des grands enjeux business, qu’on va détailler ici en guise d’illustration concrète :

• Une tribe “Company” (celle de Yasmina) : qui s’adresse aux segments des moyennes et grandes entreprises, autrement dit la partie Saas (= software as a service) de Malt

• Une tribe “Freelance” : pour aider et faciliter la vie des freelances (pour trouver des missions, sécuriser leurs paiements, gérer leurs contrats et factures etc.)

• Une tribe “Matching” : pour faciliter la mise en relation entre les entreprises et les freelance, autrement dit le modèle place de marché de Malt

Sans oublier l’équipe “Platform” qui vient en support opérationnel des équipes produit et business. 

Chaque tribe comporte le trio magique product manager / product designer / product analyst. Auxquels il faut ajouter des parties prenantes d’autres équipes (ventes, marketing, communauté etc.) dédiées. “Ce sont nos stakeholders principaux et ils partagent le même objectif business et les mêmes résultats clés à atteindre que nous”, précise Yasmina.

3- Comment fait-on sa roadmap en Impact Teams ?

Il va sans dire que, désormais, ce ne sont plus des fonctionnalités qui se retrouvent dans les roadmaps, mais des objectifs à atteindre, mesurés par des indicateurs clés (=KPI, Key Performance Indicator). 

Chez Malt par exemple, les OKR sont en place depuis 3 ans et ces KPI n’en sont que la déclinaison plus segmentée. Les équipes se débrouillent alors pour trouver comment faire pour arriver à faire bouger leur métrique. 

“Elles doivent définir des hypothèses qui pourraient augmenter leur KPI et lancer plein d’expérimentations. Nous, à la fin, on veut le maximum d’insights. Je préfère avoir 4 tests sur des sujets très différents et on voit ce qui a le mieux marché pour passer à l’étape d’après. Plutôt que de dire qu’on va bosser sur une fonctionnalité, on se revoit dans un mois ou deux… et constater que finalement ça n’a pas marché”, résume Johan.

Mine de rien, un exercice pas si facile, comme le confirme Arthur. “Ce fut difficile d’arrêter les roadmaps en features quand tu en fais depuis 5 ans. Il y avait parfois cette tentation du comité de direction de se dire : “Si on définit cet indicateur, est-ce qu’on va pouvoir faire cette fonctionnalité ?” Il faut alors expliquer qu’on n’en sait rien, c’est le terrain qui nous le dira”. Avant d’ajouter : “Sachant que c’est super dur de définir des indicateurs, cela requiert un certain niveau d’abstraction”.

C’est pourquoi, chez Jobteaser, d’autres artefacts guident les équipes, en plus de leur objectif.

“Pour éviter qu’elles partent dans tous les sens, on leur donne la vision produit, pour qu’elles aient toute l’histoire. Ainsi que nos principes produits. Par exemple, en cas de conflit d’intérêt entre les étudiants et les entreprises sur une feature, on priorisera toujours l’étudiant. Ça donne un cadre plus précis. Car, cela peut paraître paradoxal mais on est plus créatif dans un environnement sous contrainte”, justifie Arthur.

4- Quel est le rythme des rituels en impact teams ?

On aborde cette question car, dans l’idée, les impact teams permettent de sortir de la rigidité des plans de release trimestriels, au profit d’itérations plus courtes, grâce à la discovery. “Auparavant, on passait généralement le 1er mois à réfléchir à ce qu’on allait faire, le 2e à faire puis, le 3e, à lancer. Sachant que tu ne récoltes les données qu’à partir du 4e mois…” indique Johan. Les fameux trimestres de 4 mois du produit.

Chez Malt, le modèle initial, c’était plutôt de fonctionner en “focus” tous les mois. Soit deux sprints. “L’idée du focus, c’est de se dire : à la fin du mois, on veut avoir des premiers éléments qui nous permettent de dire si on continue ou pas dans cette direction”, précise Johan. Sachant que des équipes peuvent travailler 4 mois sur un même focus si elles ont des résultats et que tout le monde estime qu’il y a encore des choses à faire sur ce sujet.

“Certaines expériences ont des effets, d’autres non. Mais ce n’est pas grave car on y a passé 2 semaines et non 3 mois. Et on communique dessus malgré tout auprès des parties prenantes et du comité de direction pour leur indiquer que ce n’est pas là qu’il faut aller”, illustre Yasmina.

“On veut créer ainsi du rythme dans les équipes… mais on se rend compte que c’est assez intense quand même. Donc on a remis un échelon à 3 mois malgré tout, marqué par une discussion avec le comité de direction qui, comme un board d’investisseurs, challenge et valide ce qui est proposé par les Tribes”, ajoute Johan.

Chez Jobteaser, des petites évolutions ont aussi été apportées en cours de route. Déjà, toutes les deux semaines, une “design review” a été ajoutée (design à comprendre au sens large… enfin au sens propre du terme !) entre les head of product, lead tech et product designer de la tribe, pour voir comment la compréhension de l’équipe a évolué par rapport à l’enjeu traité. Ici, l’équipe se sert du modèle de l’arbre d’opportunités (qui se rapproche de l’impact mapping).

Par ailleurs, tous les 6 mois, un gros board produit est organisé pour effectuer la rétrospective du semestre, voir si les métriques des squads ont été atteintes, se resynchroniser potentiellement avec les objectifs globaux de la boîte etc. 

C’est à ce moment que se posent les questions :

• Avons-nous le bon nombre de squads placées dans les bonnes tribes ?
• Gardons-nous les objectifs des squads ?

Dans les faits, les objectifs restent relativement stables dans le temps chez Jobteaser. “On a des équipes qui ont le même type de KR quasiment depuis le début de la nouvelle organisation”, confie Arthur. Pour des sujets de monétisation par exemple, des objectifs atemporels en soi. Avec la crise de l’an passé toutefois, des changements drastiques ont eu lieu pour s’adapter à l’évolution de l’environnement.

5- Comment trouver le temps de faire de la Discovery en Impact Team ?

On l’a vu avec l’illustration de MeilleursAgents, le grand sous-entendu derrière un fonctionnement en impact team, c’est la discovery. La capacité à faire du test & learn rapidement. Tu ne pars pas d’une solution (= une fonctionnalité) mais d’une hypothèse que tu dois valider, ou non, le plus rapidement possible pour avancer. 

“C’est très entrepreneurial. C’est une façon de demander à tes équipes : si c’était ta boîte, qu’est-ce que tu ferais ? Est-ce que tu passes 4 mois à faire un truc et tu ne sais pas trop si ça va marcher ? Ou est-ce que tu lances plein d’expérimentations pour améliorer tel ou tel KPI ? On voit vraiment les Tribes comme des mini-boîtes”, dit Johan. 

Encore faut-il avoir le temps de faire de la discovery… On avait vu que MeilleursAgents avait mis en place des équipes composées de 2 Product Managers fonctionnant en “dual track” (une personne en discovery, l’autre en delivery puis inversement des rôles) pour résoudre cet enjeu.

Malt, de son côté, a opté pour une autre solution : la prise en charge de la delivery… par le lead tech de l’équipe ! Autrement dit, le rôle de Product Owner (PO) se dilue au sein des tech pour libérer du temps aux PM afin qu’ils/elles fassent plus de discovery. 

“Le lead tech anime l’équipe et les sprint car il a une vision globale de tous les sujets qui arrivent et prend la responsabilité des quick wins. On ne veut pas que les PM se prennent la tête sur des micro sujets”, indique Johan. Il n’est donc pas rare désormais que les PM n’aient pas de contact avec l’équipe dev’ pendant plusieurs jours voire semaines. 

“J’assiste toujours au sprint planif mais je ne les anime plus, témoigne Yasmina. Moi, j’ai l’axe focus du mois et je vais plus être concentrée sur la conception en amont et les nouveaux tests et expérimentations. Pendant que le lead tech va s’occuper de les introduire dans JIRA, écrire les tickets et organiser pour que ça rentre dans le sprint”, décrit Yasmina.

Attention cependant : “Tous les dev’, même très senior, ne veulent pas forcément jouer ce rôle !”, avertit-elle. “Ce sujet RH n’est vraiment pas à sous-estimer. Je ne m’en étais pas rendu compte au début mais ça secoue tout le monde”, prévient Johan.

Chez Jobteaser, on a choisi d’aborder cet enjeu sous un angle plus managérial voire culturel. “Si les PM n’ont pas de temps pour la discovery, ça veut dire qu’ils ne font pas les bonnes choses ou du moins qu’ils doivent justifier que la delivery est plus importante,” indique Arthur Rougier.

Pour lui, ce changement de mentalité vient en partie de la culture :

“Si, au lieu de leur demander “quels tickets as-tu livré ?”, tu es plutôt dans l’approche “qu’as-tu appris dans ton arbre d’opportunité ?”, tu vas déplacer naturellement leurs priorités. Ça dépend de ce que tu valorises dans la boîte et tes instances de reporting. C’est le problème de Scrum qui met plus d’emphases sur les tickets que tu livres”. 

Mais comment faire pour ne pas se faire happer malgré tout par le sprint planning et la nécessité de “nourrir les dev’” ? “Il faut faire accepter aux dev’ que la meilleure action à faire est parfois de prendre du recul sur le problème à résoudre. Soit pour qu’ils participent à la réflexion voire aux interviews utilisateurs. En tant qu’équipe. Soit, si cela ne les intéresse pas, il y a toujours des bugs ou du MRO (=Maintenance, Repair & Operations) à faire sur la plateforme ?”, justifie Arthur.

6- Quelles compétences en Discovery sont-elles nécessaires ?

“C’est LE sujet le plus important”, lance d’emblée Johan de Malt. Et pour cause, MeilleursAgents, Malt et Jobteaser ont tous reconnu s’être pris un mur à ce sujet.

“Les gens se plaignent d’avoir des roadmaps gérées par l’exécutif. Mais cela a aussi un côté rassurant et confortable. Cette responsabilité est lourde à porter quand tu ne sais pas ce qu’il faut faire…”, témoigne Arthur. 

Sans langue de bois, il confie que certaines équipes, laissées dans la nature avec des expériences limitées en discovery, ont déraillé au début. Elles sont parties sur des solutions pas suffisamment validées sur le terrain et quelques mois plus tard… leur impact fut minime. Un risque business… mais aussi humain. Avec une perte de confiance 1) en soi 2) des dev’ envers le produit.

« Presque un changement de métier »

“Le sujet numéro 1 a été le coaching dans notre cas, explique Johan. On a passé beaucoup de temps au début, quitte à travailler en binôme, pour voir comment bien définir un focus. On ne voulait pas les laisser complètement dans la nature… tout en les mettant malgré tout en phase de stress pour voir ce que cela donnait”. Des experts freelance en discovery (notamment sur la partie AB test ou user flow) sont aussi venu prêter main forte pour aider les équipes à monter en compétences.

“On est passé de 80% du temps à faire du delivery à 40 %. C’est presque un changement de métier,” assure Yasmina, qui explique que, pour elle, le grand défi fut d’entrer en contact direct avec les clients.

“Cela change aussi nos critères de recrutement, poursuit Arthur. Personnellement, j’ai ajouté une partie dans le processus d’entretien pour tester les capacités en discovery, avec des cas que j’ai piqué à Google”.

“On se pose en effet la question des nouveaux profils qui vont s’intégrer à cette organisation, ajoute Johan. Est-ce qu’il vaut mieux embaucher une personne qui a une forte expérience en produit mais essentiellement en delivery et que l’on formera en discovery ? Ce qu’il y a beaucoup sur le marché. Ou une personne très business (growth, ops…) que l’on va amener au produit ?”.

Petit élément de réponse : les deux dernières recrues chez Malt appartenaient plutôt à la deuxième catégorie.

7- Quels sont les avantages de passer en Impact Teams ?

Et tout ça pour quoi au juste ? Voici les deux grands avantages cités :

• Du sens pour les équipes !

“On sait pourquoi on fait les choses, d’autant qu’on est plus proche du business désormais. Cela donne beaucoup plus de sens à notre travail”, lance avec enthousiasme Yasmina. “Cela crée des équipes de missionnaires (NDLR : à l’inverse des mercenaires) qui sont plus engagées et qui s’approprient plus les problèmes”, renchérit Arthur.

“On sent une excitation supplémentaire dans les équipes quand un KPI est atteint. Car elles n’ont pas juste fait ce qu’on leur a demandé : elles ont fait le parcours de bout en bout,” insiste Johan. Avant d’ajouter : “C’est moins le produit qui se fait plaisir. En mode le produit fait un beau produit pour les utilisateurs, pendant que le reste de la boîte s’occupe du business. Là, en agissant sur les KPI liés à nos OKR, on fait plaisir à l’utilisateur en prouvant que ça sert le business”.

• Un produit plus frugal et efficace

“Je ne sais pas si on fait moins de fonctionnalités au final, mais ce qui est sûr, c’est qu’on passe moins de temps de dev’ dessus, résume Johan. On ne mesure pas la valeur utilisateur à la richesse fonctionnelle ou la complexité technique d’une fonctionnalité”.

Exemple très concret justement. La boîte sort l’été dernier un nouveau produit qui s’appelle Malt Plus. Le concept : au lieu de passer par le moteur de recherche pour trouver un freelance, l’entreprise cliente dépose un brief et reçoit en moins de 24h des soumissions, après que Malt se soit occupé du matching. Usage : “pourrave !” décrit Johan sans prendre de pincette. 

Une squad est alors mise en place avec l’objectif d’en accroître l’utilisation. Et alors que le produit est d’une grande complexité algorithmique, l’équipe fait essentiellement des choses en front. Notamment en ajoutant une partie onboarding avec un assistant (= un wizard dans la jargon) qui expliquait ce nouveau parcours. Résultat : l’usage fait X5 en deux mois ! Pour un temps de dev’ extrêmement limité (ça se joue à pas grand chose parfois).

“On élargit moins la surface produit”, affirme de son côté Arthur. Mieux : pour la première fois de l’histoire de Jobteaser, des fonctionnalités qui n’avaient pas atteint leur indicateur de succès ont été retirées !

“Quand tu regardais une offre d’emploi, on avait fait un bandeau avec des offres similaires, un peu comme chez Amazon. Cela n’a pas atteint l’impact nécessaire pour justifier la taille du dev’, on l’a donc retiré pour ne pas se trimballer un truc qu’on devra maintenir tout le temps ensuite”, raconte-t-il.

8- Quels sont les points de vigilance à garder en tête en Impact Teams ?

• Une data solide

“Tu ne fais plus la data a posteriori. En impact teams, tu en as besoin pour vivre ! Ce qui donne beaucoup de responsabilité (et de pression) à l’équipe en question”, révèle Arthur. 

“Nous, ça faisait un an et demi qu’on avait une équipe data structurée. C’est un pré-requis indispensable pour passer en impact teams. C’est compliqué sinon, si tu n’es pas capable de mesurer ce que tu fais…”, ajoute Johan.

• Gare aux trous dans la raquette

Comme les impact teams n’ont plus de périmètre fonctionnel défini, des pans du produit peuvent se retrouver sans responsable. C’est la raison pour laquelle, chez MeilleursAgents, des rôles transverses, comme des product analysts, ont été ajoutés. “Comment je fais sinon pour m’assurer, par exemple, que mon KPI d’acquisition ne parte pas en sucette et que personne ne s’en rende compte ?” expliquait Christopher Parola.

Jobteaser a connu ce problème dans la gestion des bugs. Par conséquent, chaque équipe a désormais sous sa responsabilité un objectif… et un périmètre fonctionnel à maintenir (même s’il n’est pas lié au KR à atteindre). Ce qui recrée des arbitrages complexes (j’avance sur mon KR ou j’améliore mon territoire ?)

• De nouvelles compétences requises au produit

“Ce changement est hyper valorisant car, après un certain nombre d’années, la valeur ajoutée du PM est ailleurs que sur le delivery”, explique Yasmina. Mais ces responsabilités ne sont pas faites pour tout le monde.

“Tu passes d’un job de gestion de projets à quasiment de l’entrepreneuriat, pour essayer de trouver des propositions de valeur qui marchent, confirme Arthur. Ca élargit le poste : le delivery n’est plus qu’un élément parmi tant d’autres. Mais des gens qui étaient très forts en feature teams ne seront peut-être pas adaptés à un fonctionnement en impact. Tu peux les faire exploser…”

Même en tant que CPO, les missions évoluent : “C’est un choix “facile” car tu donnes aux autres beaucoup de tes anciennes responsabilités. Ton métier devient plus alors de définir des résultats clés et de faire de l’accompagnement”, ajoute Arthur.

• Un modèle pas adapté si tu as une roadmap claire

“Si tu sais ce que tu as besoin de faire sans avoir à te poser de questions, les features teams restent plus appropriées”, prévient malgré tout Arthur Rougier. “Au début de ta boîte, tu n’as pas besoin de ça, confirme Johan. Les fondateurs ont une vision, la roadmap est claire, ton produit comporte si peu de choses que tu as juste besoin de le densifier”. Une bonne usine à features fait le taf.

Les modèles hybrides sont aussi possibles. “Ce fonctionnement en impact n’est pas vraiment adapté pour certaines squads chez nous, notamment sur la partie infrastructure, avoue Arthur. Leur roadmap est claire, on sait exactement ce qu’il faut faire et dans quel ordre… Ils ont des objectifs mais, en soi, le pilotage est toujours hyper feature-driven”.

Maintenant, tu peux faire ton choix d’orga en (meilleure) connaissance de cause !

---

Pour aller plus loin sur les Impact Teams :

Comment Meilleurs Agents a inventé les Impact Teams, en transformant intégralement son organisation produit

• J. Aradan raconte la transition feature teams 🠒🠒→ impact teams chez Malt
•  J. Aradan sur le même sujet au micro de Estelle Aubouin dans Product Tape
•  L’équipe produit de Jobteaser présente son orga à LPCx
•  … sans oublier notre article fleuve sur les impact teams de MeilleursAgents

---