Galen Low s’entretient avec Julia Ryzhkova, Product Manager chez Railsware, pour discuter de la manière dont une organisation parvient à développer avec succès des solutions logicielles complexes grâce à des squads distribués et auto-gérés, et ce que cela signifie pour la gestion de projet numérique à grande échelle.
Faits saillants de l’entretien :
- Julia Ryzhkova est une professionnelle IT basée à Kiev, qui repousse les limites de la gestion des processus métier et de la gestion de produit numérique depuis plus de 15 ans. Elle a été analyste métier, directrice PMO, directrice produit, directrice du succès client, travaillant avec des marques comme Heinz, Yandex, Adidas et Zyxel pour mettre en œuvre des systèmes d’entreprise à grande échelle. [0:55]
- Aujourd’hui, Julia est Product Manager chez Railsware, et travaille dans l’équipe Coupler.io où elle supervise des squads Agiles distants et auto-gérés, qui créent des produits très adoptés, désormais des noms familiers, comme Calendly. [1:18]
- En dehors du travail, Julia enseigne la gestion des processus métier et de projets à la Lviv Business School et élève son enfant pour faire partie de la prochaine génération de femmes dans la tech. [1:30]
- Récemment, Railsware a conçu le cadre BRIDGeS — un cadre décisionnel flexible dans lequel vous pouvez, à un haut niveau, décrire votre problème et ensuite le transformer en solution. Julia participe à sa promotion par le bouche-à-oreille. Ils l’ont conçu pendant plus de 15 ans et c’est le début de son ouverture au public. [2:09]
- Julia travaille également à la Business School de Lviv et ils organisent actuellement une formation publique en ligne sur les processus métiers. Julia espère que cela améliorera la maturité globale de la culture des processus métier en Ukraine. [2:49]
- Aujourd’hui, Julia est product manager, ce qui signifie qu’elle gère les produits — développement, marketing, stratégie de prix et force de vente. Elle a une formation technique qui l’a beaucoup aidée, mais elle n’aime pas coder. En cherchant des opportunités professionnelles, Julia voulait trouver un poste où elle pourrait créer des algorithmes, mais laisser quelqu’un d’autre coder. C’est ainsi qu’elle est devenue BA. Ensuite, cela a façonné ses compétences en leadership et elle est devenue chef d’équipe BA, chef de projet, puis responsable du département BA. [5:15]
- Julia a remarqué que les résultats de son travail dépendent du produit sur lequel elle travaille. C’est pourquoi elle a décidé de passer à la R&D en tant que product owner et de faire partie du produit. Puis leur produit a grandi, l’équipe s’est agrandie, ils ont eu plus de product owners et Julia est devenue Directrice adjointe produit, gérant la moitié des équipes scrum. [5:55]
- Julia est également devenue directrice de l’expérience client et a géré le support — tout ce qui concerne les services, le support, l’académie, etc. Elle a réussi à mettre en place d’excellents processus et à montrer de très bons résultats. [6:24]
- Julia a voulu se concentrer sur la valeur apportée aux clients tout en laissant la gestion des processus de côté. Pour elle, c’est la différence entre la gestion de produit et la gestion de projet. [7:17]
Les product managers se concentrent sur la plupart des produits et des clients, alors que la gestion de projet se concentre sur les processus et leurs résultats.
Julia Ryzhkova
- La structure des équipes chez Railsware dépend du type de projet sur lequel ils travaillent. Ils sont un studio de produits, ce qui signifie qu’ils créent des produits pour eux-mêmes et pour d’autres entreprises. [8:28]
- Chez Railsware, ils aiment tout automatiser, et parfois ils ne trouvent pas sur le marché l’outil qui fera exactement ce dont ils ont besoin. C’est alors qu’ils décident de développer quelque chose pour leurs propres besoins. Ils l’utilisent, puis le lancent publiquement et le proposent sur le marché, car ils savent qu’ils ne sont pas les seuls à avoir ce besoin. [8:42]
- Le Smart Checklist for Jira, l’un des produits de Railsware, a été développé à temps partiel par l’un de leurs développeurs, puis ils ont décidé d’y affecter des développeurs à temps plein après avoir atteint 50k MRR. [9:12]
- Chez Coupler.io, ils ont une équipe de développement, composée de quatre ou cinq développeurs, et une équipe marketing, également composée de quatre ou cinq spécialistes différents. Toutes les autres personnes travaillent à temps partiel, comme l’analyste de données, le responsable support, et même Julia en tant que product manager, qui s’investit à la fois dans ce produit et dans ceux des clients. [9:38]
- Le défi habituel de tout product manager sur un produit en start-up est de trouver la pépite sur le marché. Chez Railsware, ils résolvent généralement certaines douleurs des clients, c’est pourquoi leur base de clients grandit, leurs indicateurs augmentent, mais ils veulent garder la cadence et la doubler. [10:55]
- Chez Railsware, ils recherchent des développeurs expérimentés, en forme de T, ayant de nombreuses expériences diverses. Ils peuvent ainsi commencer à travailler avec les clients en tant que développeur, PDM et PM dès la période du MVP. [13:23]
- La plupart des personnes travaillant chez Railsware avaient une expérience managériale, ou même géraient leur propre entreprise, comme des RH, des designers et des chefs de produit. Cependant, aucun d’eux n’est le manager direct de l’équipe, et la façon de devenir une autorité repose sur le principe du « donner l’exemple ». [14:39]
On ne peut pas simplement dire ce qui doit être fait, il faut juste faire de son mieux pour avoir un impact sur le produit et sur le résultat global, et c’est ainsi que l’équipe vous fait confiance.
Julia Ryzhkova
- Il est facile d’évaluer sa nécessité pour l’entreprise quand on est l’unique héros et que, sans vous, tout part à la dérive. Cependant, quand tout va bien, même sans vous, on ne ressent plus l’impact comme avant. [16:51]
- Après avoir cessé de vouloir tout contrôler, et avec tout le temps libre dont vous disposez, vous trouvez différentes manières d’avoir un impact. Vous vous concentrez sur le produit. Vous vous concentrez sur le client. Vous vous concentrez sur la stratégie. Lorsque vous laissez plus d’espace à l’équipe, elle peut créer quelque chose d’incroyable dans la guilde. [17:38]
- Son background technique a apporté certains avantages à Julia, mais les compétences en gestion de projet sont cruciales pour un chef de produit. Tous les postes seniors chez Railsware incluent les compétences en gestion de projet dans leurs critères de compétence. [20:25]
- Pour tous les rôles chez Railsware qui contribuent aux produits et aux projets, il faut au moins savoir se gérer soi-même — son périmètre, son planning, ses coûts et ses achats. C’est pourquoi ils recherchent des développeurs et membres d’équipe expérimentés. [22:32]
- Même lorsqu’il n’y avait que deux fondateurs chez Railsware, ils avaient défini des processus, les géraient comme de simples listes de tâches, mais tout restait structuré et documenté. C’est pourquoi cela fait partie de leur culture, ce qui est rare chez les petites entreprises. [24:39]
- Chez Railsware, ils appliquent le principe « documenter au fil de l’eau » et chaque synchronisation dispose d’un doc partagé ou d’un board Figma où chacun note des informations avant ou pendant la réunion. [25:27]
- Dans le cadre de leur culture de transparence, toutes les communications se font sur des canaux publics, des canaux Slack, et ils en ont plus de trois cents. [26:35]
Vous ne pouvez pas ignorer les processus si vous voulez faire du business.
Julia Ryzhkova
- Julia ne suit pas les indicateurs de performance, mais elle suit les métriques produit et la croissance du produit. Elle suit la vélocité de l’équipe, mais seulement pour prédire ce qu’ils peuvent réellement réaliser lors de la release et pour gérer les attentes. [31:08]
- Les équipes Railsware pratiquent le pair programming, les tests croisés, la revue de code, ils suivent donc eux-mêmes leur performance en communiquant clairement ce qui doit être amélioré. [32:14]
- La culture du feedback dans l’entreprise est très développée. Tout nouveau reçoit un retour de tous les membres de l’équipe, et tout le monde peut pointer un problème de performance ; de même, un nouveau partage son propre retour sur les membres, la collaboration et sur l’entreprise. [33:04]
- Toutes les équipes Railsware utilisent des approches similaires. Julia leur a appris à estimer. Ils font du grooming, de la gestion de roadmap, des projets RH, ils planifient et suivent la vélocité, et ils utilisent réellement cela pour gérer leurs processus. [45:17]
- Chez Railsware, ils ont ce Processus de Gestion des Inputs où n’importe quel membre peut créer une demande à ajouter dans le backlog de n’importe qui, et elles sont revues chaque semaine. [52:34]
- Chez Railsware, ils préfèrent partager les éléments importants lors des synchronisations de la guilde dans le cadre de leur perfectionnement professionnel. Si quelqu’un ressent un manque de compétences ou reçoit un feedback d’amélioration, il peut utiliser un budget formation pour se former. [59:48]
- Julia a fourni une formation à l’équipe RH sur l’estimation des tâches, par exemple lorsqu’ils construisaient et estimaient leur roadmap projet de l’année. Julia a également partagé des approches apprises lors de différents événements et formations. [1:00:12]
Les équipes auto-gérées permettent aux chefs de projet de concentrer leurs efforts sur la stratégie, le produit et le client.
Julia Ryzhkova
Bio de l’invitée :
Julia évolue dans l’industrie des technologies de l’information depuis 15 ans. Occupant divers postes, elle a été analyste d’affaires puis cheffe de projet chez Creatio pendant 5 ans. Là, elle a accompagné avec succès 70 entreprises dans l’adoption de systèmes CRM et BPM. En particulier, elle a supervisé des projets d’implémentation chez Yandex, Heinz, Zyxel, Adidas et d’autres grandes marques.
Chez Creatio, Julia est devenue directrice adjointe du produit puis directrice du succès client.
Toute cette expérience lui a permis de renforcer ses compétences en gestion de projet, en management et en optimisation des processus de marketing, de vente, de service client et des processus métiers internes.
Parallèlement, l’une des grandes passions de Julia est le produit. Elle cumule plus de 8 ans en gestion de produit. Actuellement, Julia est cheffe de produit chez Railsware. Elle a rejoint l’équipe produit de Coupler.io (un produit développé par Railsware) en 2020, et sa contribution à la croissance et au développement du produit est immense !
De plus, Julia anime des cours sur les processus métier et la gestion de projet à la Lviv Business School. Ces formations sont principalement dédiées au marché local. Des professionnels de SoftServe, Nova Poshta, ainsi que des dizaines de start-ups ukrainiennes assistent régulièrement aux formations de Julia. Toujours désireuse de partager son savoir et son expertise, elle participe fréquemment à des conférences, webinaires et autres événements locaux.
Julia est une cheffe de produit orientée client et une grande leader, dotée de solides compétences interpersonnelles et d’un bagage technique important. Julia est reconnue pour son management inspirant, son excellence opérationnelle et est régulièrement récompensée pour ses réussites en matière d’amélioration des processus.

Lorsque vous disposez d’une équipe qui sait s’autogérer, vous pouvez réellement accomplir des choses sans devoir intervenir en profondeur et vous pouvez réfléchir à ce qui doit être fait plutôt que de vous concentrer sur la façon dont cela doit être fait.
Julia Ryzhkova
Ressources de cet épisode :
- Rejoignez la communauté Digital Project Manager
- Découvrez Railsware
- Connectez-vous avec Julia sur LinkedIn
Articles et podcasts liés :
- À propos du podcast
- Article expliquant comment exploiter les données humaines pour piloter des équipes projet hautement performantes
- Article expliquant chefs de projet : comment gérer le burnout au travail
À découvrir : Mentorat en direct : Formulations clés pour des conversations difficiles et au-delà
Lisez la transcription :
Nous testons la retranscription de nos podcasts à l'aide d'un logiciel. Veuillez excuser les éventuelles fautes de frappe, l’IA ne retranscrit pas encore parfaitement à 100% du temps.
Galen Low : Équipes projet auto-gérées. Cette seule expression suffit à provoquer une crise existentielle chez n'importe quel chef de projet. Mais est-ce une menace pour notre existence ? Ou est-ce la clé permettant au chef de projet de prendre un rôle bien plus stratégique ?
Si vous vous interrogez sur l'avenir de la gestion de projet et sur la pérennité du métier de chef·fe de projet digital, continuez d'écouter. Nous allons soulever le capot pour découvrir comment une organisation parvient à développer avec succès des solutions logicielles complexes grâce à des équipes distribuées et auto-organisées, et ce que cela signifie pour la gestion de projets digitaux en général.
Merci de nous écouter, je m’appelle Galen Low de Digital Project Manager. Nous sommes une communauté de professionnels du digital en mission pour s’entraider à devenir plus compétents, confiants et connectés afin de livrer des projets impactants et porteurs de sens. Pour en savoir plus, rendez-vous sur thedigitalprojectmanager.com.
Bonjour à tous — merci d'être avec nous pour ce podcast du DPM.
Mon invitée aujourd’hui est une professionnelle IT basée à Kiev, qui fait bouger les lignes du management des processus métier et du management de produits digitaux depuis plus de 15 ans. Elle a été business analyst, directrice PMO, directrice produit, directrice expérience client, travaillant pour des marques telles que Heinz, Yandex, Adidas ou Zyxel pour déployer des systèmes d’entreprise à grande échelle.
Aujourd’hui, elle est cheffe de produit chez Railsware, sur l’équipe Coupler.io, où elle supervise des équipes distantes et agiles, auto-gérées, qui créent des produits largement adoptés, aujourd'hui devenus des références, comme Calendly.
En dehors du travail, elle enseigne la gestion des processus métiers et la gestion de projet à la Lviv Business School, tout en élevant son bébé pour qu'elle devienne la prochaine génération de femmes dans la tech.
Accueillons chaleureusement Julia Ryzhkova. Bonjour, Julia !
Julia Ryzhkova : Bonjour à tous !
Galen Low : Merci d’être avec nous aujourd’hui. Merci pour nos récentes discussions, je suis vraiment ravi pour l’épisode d’aujourd’hui car je pense qu’il touche à un sujet qui nous rend tous un peu nerveux en tant que chefs de projet : est-ce que notre métier va continuer d’exister ?
Nous allons y revenir, mais je voulais te demander — comment vas-tu ? Qu’est-ce qui t’inspire en ce moment ?
Julia Ryzhkova : Ce sont en fait deux choses différentes. Si l’on parle de Railsware, c’est le framework BRIDGeS. On l’a ouvert récemment, il s'agit d’un cadre de décision qui permet, à haut niveau, de décrire un problème puis de le transformer en solution.
Nous venons de le partager publiquement et actuellement je m’emploie à en faire parler autour de moi. C’est vraiment génial, je suis très enthousiaste à ce sujet. On y travaille depuis plus de 15 ans. Là, c’est comme une ouverture au public, et c’est vraiment inspirant.
D’un point de vue personnel, comme tu l'as dit, j’enseigne aussi à la business school de Lviv et on monte en ce moment une formation publique en ligne sur les processus métiers. J’espère que cela améliorera la maturité globale de la culture du business process en Ukraine.
Cela aussi m’inspire.
Galen Low : J’adore ça. Deux choses passionnantes, de belles réussites. Félicitations !
Si les gens souhaitent en savoir plus sur le framework BRIDGeS, où doivent-ils aller ?
Julia Ryzhkova : Sur le site de Railsware, nous avons un sous-domaine dédié.
Galen Low : Génial. Très cool. Très cool. Et puis, on enregistre en décembre, on s’apprête à passer à 2022… Qu’est-ce qui t’enthousiasme le plus pour 2022 ?
Julia Ryzhkova : Oh, tu sais, tout le monde parle d’intelligence artificielle et de machine learning. Dernièrement, on a fait une réunion pour discuter des visions produits, et j’ai cette idée d’utiliser l’IA sur mon produit, Coupler.io, et j’ai vraiment hâte d’essayer ça et voir ce que ça donne.
Galen Low : Trop bien.
Bon, rentrons dans le vif du sujet. Aujourd’hui, on va parler de la façon dont de petites équipes agiles, à distance, peuvent s’auto-manager et s’auto-organiser en essaim pour créer des solutions logicielles complexes, sans chef de projet à aucun moment. Est-ce une menace pour nous, chefs de projet ? Est-ce une opportunité de devenir plus stratégiques ? Alimente-t-on l’angoisse existentielle de nos auditeurs ?
On va tout explorer en détail, on va vraiment lever le couvercle et creuser.
Mais pour commencer, pourrais-tu nous raconter ton parcours ? Quel est ton rôle aujourd’hui et comment en es-tu arrivée là ?
Julia Ryzhkova : Aujourd’hui, je suis cheffe de produit, donc je gère le développement, la stratégie marketing, la tarification et la force de vente.
J’ai une formation technique, ce qui m’a beaucoup aidée en informatique, mais je n’aimais pas coder. Quand j’ai cherché une voie professionnelle, je voulais un poste où concevoir un algorithme sans avoir à le coder moi-même. C’est ainsi que je suis devenue BA. Puis le leadership m’a plu, je suis devenue cheffe d’équipe BA, cheffe de projet, responsable du pôle BA.
Mais j’ai remarqué que le résultat de mon travail dépendait vraiment du produit sur lequel je travaillais. D’où mon choix de me tourner vers la R&D pour devenir product owner et faire partie du produit. Ce fut la première fois où je me suis sentie à ma place. Le produit a grandi, l’équipe aussi, il y a eu davantage de product owners et je suis devenue directrice adjointe produit, gérant la moitié des équipes scrum, puis j’ai voulu aller plus loin.
Comme on avait déjà une directrice produit, j’ai choisi de m’orienter vers la direction de l’expérience client, où j’ai géré le support, l’académie, tout ce qui touchait aux services. J’y ai mis en place de super process et obtenu de bons résultats.
D’où la décision de tirer parti de ces compétences pour structurer d’autres départements, et je suis devenue directrice PMO. Puis il y a eu le congé maternité. Et une fois ce chapitre important terminé, j’ai voulu revenir au management de produit.
C’était une décision importante et peut-être te demandes-tu pourquoi manager le produit et non le projet ? Parce que je voulais me concentrer sur la valeur pour les clients en laissant la gestion des process de côté. Pour moi, c’est ça la différence entre produit et projet. Il y a beaucoup de points communs.
Mais il me semble que la chefferie de produit permet de se focaliser sur le produit et le client, alors que le management de projet vise le process et son aboutissement, non ? Là, les équipes auto-organisées sont essentielles, et j’ai su que Railsware était une parfaite opportunité quand j’en ai entendu parler et que je m’y suis intéressée.
Galen Low : J’adore ce parcours, ce bagage technique, cette expérience client, ce leadership. C’est vraiment inspirant pour le secteur.
Peux-tu nous parler un peu de Railsware, de la structure des équipes que tu diriges, et du type de projets traités par Railsware ?
Julia Ryzhkova : Oui, commençons par les projets, car la structure des équipes dépend du type de projets. Nous sommes un studio produit, donc nous créons à la fois pour nous et pour d’autres entreprises. Chez Railsware, on aime automatiser tout, et parfois, il n’existe pas un outil sur le marché qui fait ce que l’on veut.
C’est là qu’on décide de développer l’outil en interne, on l’utilise, puis on le lance publiquement car nous savons que d’autres en ont aussi besoin. On commence donc en petite équipe pour tâter le terrain, parfois même avec un développeur à temps partiel — par exemple, pour le Smart Checklist for Jira que nous avons lancé, il a été développé à temps partiel par un seul développeur, et ce n’est qu’à 50k de MRR qu’on a détaché des développeurs à temps plein dessus.
Pour les petits produits comme Coupler.io, on a une squad de développement de 4-5 devs, et une squad marketing aussi de 4-5 spécialistes.
Les autres rôles sont en temps partiel, comme l’analyste data, le support, ou même moi, cheffe de produit, j’interviens sur ce produit et sur ceux des clients. Mais quand le produit grossit, comme ce fut le cas pour Calendly, on étoffe la dev team, puis on divise en plusieurs squads, car on croit à l’efficacité des petites équipes.
Aujourd’hui, Calendly compte trois équipes côté Railsware, plus plein de développeurs côté client. Voilà comment on fonctionne.
Galen Low : Super. J’aimerais vraiment creuser cette idée de squads et de « swarms ». J’aime que le marketing soit aussi une squad. Au fond, Agile ne veut pas dire que développement ou ingénierie.
Ça peut être plein d’autres choses, on va en parler. Dis-moi, quel est le plus grand défi pour toi aujourd’hui côté gestion de produit ?
Julia Ryzhkova : Je pense que ce ne sera pas une surprise, c’est le défi habituel de tout Product Manager dans un produit startup : trouver l’opportunité en or sur le marché.
On résout généralement un « pain point » du client, c’est pour ça que la base client et les KPI augmentent, mais on veut garder le rythme, voire le doubler. Il faut donc identifier un nouveau problème que les clients seraient prêts à payer cher pour résoudre.
Galen Low : Vous êtes des résolveurs de problèmes. Ce que j’aime, c’est que vous réglez d’abord vos propres soucis puis vous permettez à d’autres d’en bénéficier. C’est comme un produit interne qui rayonne vers l’extérieur. Vous êtes aussi un prestataire, aidant d’autres structures à bâtir les produits de leurs rêves pour éliminer leurs douleurs insupportables.
C’est super.
Pour éclairer nos auditeurs : dans mes cercles, l’idée d’équipes auto-gérées est à double tranchant. D’un côté, la plupart des chefs de projet veulent des équipes autonomes pour ne pas devenir le goulot d’étranglement, mais de l’autre, ils souhaitent rester pertinents et garder un poste.
Le concept des équipes projet sans chef de projet n’est pas nouveau au fond. En Scrum Agile, il n’y a pas de chef de projet, juste un product owner, un scrum master et l’équipe de dev. Donc quelque part, l’avenir était déjà en marche, mais on tente toujours de décrypter pour qui ce sera pertinent et comment.
D’un côté, c’est donc une menace — qui a besoin d’un chef de projet si l’équipe peut s’auto-gérer ? Mais de l’autre, c’est le nirvana du management : être plus stratégique, plus proche du produit et du client, moins « dans la mêlée » du pilotage quotidien.
Alors, la question : y a-t-il un équilibre à trouver ? Peux-tu nous expliquer comment fonctionnent ces squads auto-gérées chez Railsware et dans Coupler.io ?
Julia Ryzhkova : En fait, la réponse est liée à notre concept du « product mindset » des développeurs.
On a fait un webinaire sur ce sujet récemment. L’idée, c’est qu’on cherche des développeurs « profil T » mûrs, comme je le suis — tu as dit que j’avais beaucoup d’expériences différentes, et c’est typiquement le genre de personne qu’on recherche. Cela leur permet de travailler avec le client en tant que dev, PDM, PM au moment du MVP.
On a affiné notre processus de recrutement pendant des années pour trouver ce genre de profils, car ce n’est pas évident. On intègre ces talents sur nos produits internes d’abord, avant de les envoyer sur les produits clients, histoire de les former sur l’état d’esprit produit.
Alors seulement, ils peuvent travailler avec les clients, un peu comme un orchestre à un seul musicien. Mais c’est pareil aussi pour d’autres rôles. Tous les Railswarians (c’est comme ça qu’on s’appelle) peuvent travailler séparément. Beaucoup de gens ont eu des expériences de management, même monté leur propre business, que ce soit RH, designers, ou chefs de produit bien sûr. Vraiment tout le monde.
Mais aucun de nous n’est le manager direct de l’équipe. L’autorité se gagne par l’exemplarité. Tu montres le chemin par ton impact sur le produit et le résultat global, c’est ça qui génère la confiance de l’équipe. Tu ne peux pas juste dire quoi faire, tu dois agir et influencer de façon concrète.
Galen Low : J’aime beaucoup cette logique du T-shape, l’apport d’expériences variées. Et c’est intéressant de voir le recrutement focalisé autant sur la posture managériale ou entrepreneuriale que sur la technique. Même si les rôles sont plats dans l’équipe.
Tu as un background en gestion de projets, tu as même dirigé un PMO. Cette idée d’équipes auto-gérées, au départ, ça ne t’a pas perturbée/ébranlée ?
Julia Ryzhkova : Oui, c’est drôle que tu le demandes. Au début, pendant la période d’essai chez Railsware… C’était facile d’évaluer mon utilité quand j’étais l’élément clé et que sans moi tout partait à la dérive. Mais quand tout fonctionne bien même sans toi, tu ne ressens plus l’impact, du moins comme avant.
On fait des changements, on améliore un processus, et ça avance… un peu. C’est bien, ta présence améliore les choses, mais tu pourrais partir deux semaines sans que tout ne s’écroule. Pourquoi ont-ils alors besoin de toi ? Mais avec le temps, on arrête de vouloir tout contrôler, et avec ce temps libéré, on trouve d’autres moyens d’influencer.
On se concentre sur le produit, le client, la stratégie, et on peut peser plus, parfois. D’autant plus, en laissant de l’espace à l’équipe, elle peut créer des choses incroyables via des guildes — squad de 4 devs, 1 QA, mais aussi la guilde des ingénieurs, la guilde du QA, la guilde des produits.
Par exemple, c’est la guilde produit qui a bâti le framework BRIDGeS dont j’ai parlé. Impossible d’inventer ça sans avoir cette liberté d’action, sans validation inutile…
Galen Low : J’adore. Tous mes meilleurs souvenirs d’équipe sont ceux où il y avait beaucoup d’indépendance et d’empowerment, pas où on cherche à évincer le chef de projet, mais où on donne assez de latitude pour inspirer, orienter, guider. Parfois, on caricature notre boulot de chef de projet, à courir partout façon berger de chats, mais en réalité, c’est surtout donner sens, inspirer et créer l’espace pour que l’équipe donne le meilleur. Ça ressemble beaucoup à votre culture, pas tant dans l’idée de supprimer ton poste, mais de l’élever, le rendre plus stratégique. Et puis, le luxe de réellement pouvoir partir en vacances !
Du coup, aujourd’hui, tu utilises encore tes compétences de gestion de projet ? Est-ce que ça te sert ?
Julia Ryzhkova : Clairement ! Je ne vois pas comment on peut être chef·fe de produit sans avoir un passé de gestion de projet. Comme je l’ai dit, c’est crucial. Mon bagage technique m’a apporté un plus, mais la gestion de projet est indispensable en produit aussi.
Chez Railsware, toutes les fonctions seniors doivent savoir gérer un projet : communication, organisation, etc. C’est utile pour tout le monde.
Si on parle de compétences précises, souvenons-nous du PMBOK, j’évite aujourd’hui surtout l’intégration et la communication, car c’est l’autogestion qui prime. Mais la gestion du scope, du coût, du planning et des stakeholders reste. Pour la qualité, c’est du ressort QA/dev, ce n’est plus moi. Les risques et achats sont partagés sur tous. Si quelqu’un a besoin d’un outil, il fait juste une demande en argumentant.
Et c’est cool de ne pas avoir à tout comprendre. Je ne vois pas pourquoi je devrais décider de tel outil marketing ou de telle librairie de dev. Tant mieux !
Galen Low : Ce qui est fort, c’est que tu dis que toutes les fonctions seniors doivent maîtriser la gestion de projet — scope, coût, planning, stakeholder. Parfois, on l’oublie, alors que c’est la base pour faire avancer sainement un business. Est-ce inscrit dans votre process de recrutement ou bien chacun se forme sur le tas ?
Julia Ryzhkova : Quand je parle des seniors, je pense aussi aux devs ou QA — pas les office managers évidemment. Mais toutes les fonctions qui concourent aux produits/projets doivent savoir se gérer : son scope, son planning, son coût… C’est ce qu’on attend de chacun. On cherche des profils mûrs !
On ne demande pas une formation certifiante, mais on complète au besoin. Mais pas de formation de zéro.
Galen Low : Je comprends. Et comme digital project/product managers, on doit beaucoup apprendre des autres métiers, mais eux aussi doivent apprendre de nous — sur la gestion, le collaboratif, et la compréhension business. Ce partage, c'est clé.
Double-cliquons sur tout ça, pour aider ceux qui nous écoutent et se questionnent sur comment transposer ce modèle : comment ces squads communiquent et restent alignées ?
Julia Ryzhkova : C’est surtout une question de culture. Quand les deux fondateurs de Railsware ont démarré, ils ont défini leurs process de façon structurée — des to-do simples, mais tout était documenté. Ils cherchaient des gens partageant cette culture. Peu de jeunes entreprises démarrent comme ça. D’habitude, on ne s’occupe des process que lorsqu’on perd pied.
Mais là, la structure était présente dès le départ, c’est devenu culturel. L’onboarding est processé, mais le vrai mantra est « documenter au fil de l’eau ».
Chaque réunion, chaque échange collectif, tout va dans une doc partagée, Figma, doc Word, où chaque participant note au fil de l’eau — pas de compte rendu post-réunion. Tout se fait en amont ou pendant la réunion. Et si quelqu’un sort du script, les autres l’écrivent aussi. Deux semaines de vacances ? Il suffit d’ouvrir ces documents, tout est là — pas besoin de « Faites-moi le point ». Rien n’est laissé sur le bas-côté.
Cela va de pair avec la culture de la transparence : toutes les communications passent par des channels publics, on a plus de 300 Slack channels. Quasiment pas de messages privés pour le travail. Tout est public, donc chacun peut s’informer ou répondre plus vite que la personne concernée.
Galen Low : Oui, c’est ce que beaucoup essaient de maîtriser — l’asynchrone, la conservation des discussions. Railsware est très précurseur en la matière, dès le début avec de simples to-do partagés. Pas besoin d’énormes process, mais que ce soit écrit quelque part.
Julia Ryzhkova : Oui, j’admire ça. Avant, j’enseignais qu’au lancement, on pouvait se passer de process si tu es seul et que tu sais comment faire. Mais après avoir vu l’histoire de Railsware, j’ai changé d’avis : il faut structurer dès le départ, même si ce n’est qu’une checklist. Si tu veux te repérer seul, tu feras quand même ton tableau ou ta liste d’étapes. Sinon, tu perds le fil.
Impossible de faire du business sans processus.
Galen Low : Je vois. Qu’en est-il des métriques équipe ?
Dans ce modèle, beaucoup se demandent sur quelles performances se fier, comment savoir que tout est sur les rails, comment contrôler alors que la structure est plate ?
Julia Ryzhkova : C’est amusant, mais je ne regarde aucune métrique de performance individuelle. Peut-être que ça semble fou, mais je suis les métriques produit.
On observe la croissance, nos indicateurs SaaS : conversion, chiffre d’affaires, etc. Bon, je suis la vélocité d’équipe, mais uniquement pour prédire ce que je pourrai livrer à tel ou tel sprint/époque. Je reste donc sur la gestion du planning. Mais si on livre chaque jour ou a minima chaque quinzaine, livrer avec deux semaines de retard n’est pas dramatique.
Le squad gère lui-même sa performance : pair programming avec les nouveaux, cross-testing, code review. Ils se soutiennent et se donnent des feedbacks. Ça se voit pendant les standups, les rétros, où on communique en toute transparence — et même le client est convié, on partage les retours.
La culture du feedback est à haut niveau, chaque nouveau reçoit les retours de l’équipe et peut en donner sur le process, l’entreprise, moi-même. Résultat, deux issues : soit tu ne valides pas la période d’essai, soit tu es au niveau et on ne contrôle plus la performance.
Galen Low : Parfois, ce n’est pas trop intense ?
Julia Ryzhkova : Ça peut l’être, mais en général tout le monde est aligné. Si quelqu’un détecte un souci, tout le monde le voit et on se partage le feedback — je n’ai pas eu de problème marquant.
Galen Low : C’est dans la culture, ancré dès le recrutement. On intègre des gens déjà prêts à vivre ça, à recevoir et donner du feedback, pour que ça fonctionne en structure plate.
Julia Ryzhkova : Oui, c’est vraiment ce qu’on contrôle à l’embauche. Beaucoup de temps est investi : pour les chefs de produit, on organise une journée de travail en binôme sur un vrai problème, pour voir la réaction au feedback. C’est un gros investissement, mais au final, chacun sait si la culture match, au-delà de la technique. Résultat top.
Galen Low : Ce qui prouve l’investissement côté entreprise. Beaucoup font des tests arbitraires, mais là c’est du concret : le product manager et un décideur C-level passent du temps à collaborer pour juger la dynamique de travail en vrai.
Tout le monde ne peut pas, mais c’est très efficace quand il faut être sûr du fit. Et du côté candidat ?
Julia Ryzhkova : Pour le candidat, c’est aussi un investissement : au lieu de perdre trois mois d’essai avant de réaliser que la boîte ne leur convient pas, ils le savent rapidement. Ce n’est pas la journée entière pour tous les métiers, cela peut être deux à quatre heures selon le poste. Mais il faut ouvrir le contact.
Galen Low : Ça a du sens. Autre sujet : en tant que cheffe de produit, quand tu dois changer la roadmap, modifier le backlog ou le calendrier, comment équipes réagissent-elles au changement ?
Julia Ryzhkova : Probablement tu seras surpris, mais il ne se passe… rien. Je peux retirer des tâches du sprint, en ajouter, expliquer le contexte — par exemple on a dû faire ça récemment, et on en discute, point. Je peux changer le backlog même en cours de sprint, tant que cela reste raisonnable. On fait une réunion pour estimer et synchroniser, et voilà… Je ne chamboule pas la roadmap trop souvent, je la révise une fois par mois pour y intégrer les insights et nouvelles données.
L’équipe connaît la vision et participe aux séances stratégiques avec les C-level pour remonter les alertes ou réajuster si besoin. Ils font même leurs propres remontées — j’ai eu le cas d’un ingénieur qui nous a informés qu’après le changement de notre modèle tarifaire, une plateforme intégrée avec de nombreux clients avait ajusté ses propres prix, mettant nos modèles en incohérence. On a pu corriger nos limites grâce à lui.
C’est incroyable d’avoir ce type de remontée du terrain.
Lorsque j’ai changé d’outil de gestion pour la 3e fois en 6 mois (Trello –> Coda –> Pivotal Tracker –> JIRA), l’équipe a juste demandé 15 minutes de formation et s’est adaptée. Ils sont ouverts au changement, car ils comprennent le pourquoi pour le produit/le client.
Galen Low : C’est fou ! Savoir changer d’outil trois fois en six mois sans râler, ça dit beaucoup… L’esprit « product mindset » s’exprime là : même les devs/designers/marketeurs comprennent le business et s’adaptent pour servir l’utilité client ou business. Ce n’est pas « on me fait changer de cap pour rien », mais « on le fait pour de bonnes raisons ».
Le produit, c’est le changement lui-même. En vrai, la gestion, c’est anticiper l'avenir, planifier en étant prêt à pivoter, justement parce que tout bouge constamment !
Julia Ryzhkova : Exact, d’ailleurs récemment un dev m’a dit qu’il ressentait la stabilité car on avait la visibilité sur le backlog pour plusieurs sprints, même s’il savait que tout pouvait changer. Ce qui compte, c’est d’avoir une vision et de la partager, même si le comment évolue. Ça apporte le sentiment de sécurité nécessaire.
Galen Low : Oui, c’est la confiance par la transparence. Les gens voient la roadmap, le backlog, connaissent la vision globale, et cela suffit à créer l’indépendance et la stabilité. J’aime beaucoup.
Je reviens à un point : on parle beaucoup d’agilité logicielle, de backlog, de vélocité, etc. Mais tu penses que ce modèle fonctionne seulement pour le soft en Agile ? Ou pour tout type d’équipe pluridisciplinaire ?
Julia Ryzhkova : Il faut être Agile, oui — mais au sens du manifeste Agile qui ne parle pas que de logiciel, non ?
Toutes nos squads fonctionnent ainsi, y compris marketing, finance, opérations. Je leur ai appris à estimer, à faire du grooming, à gérer une roadmap, à utiliser le Kanban, à mesurer la vélocité… Ce sont des approches dont tout le monde peut profiter.
Galen Low : À creuser dans un autre épisode ! Car beaucoup voudraient leur équipe marketing/finance aussi Agile que les devs. Tu casses le cliché : Agile n’est pas réservé au code, c’est la capacité à s’adapter au changement, ce dont n’importe quelle équipe peut bénéficier.
Julia Ryzhkova : Oui, par exemple l’équipe d’ingénierie travaille en Scrum, les designers aussi, mais le marketing en Kanban – c’est plus adapté. Tout ça reste Agile !
Galen Low : Ce qui est logique, car l’opérationnel continue. Bon, passons au côté épineux : personne ne dit qu’un modèle est parfait. Pour ceux tentés de passer à l’auto-gestion, peux-tu dire ce qui, parfois, dysfonctionne dans ce modèle ?
Julia Ryzhkova : Question tricky. Disons que parfois un squad n’a pas la visibilité sur ce qui se passe ailleurs. Par exemple, on avait deux produits internes, Mailtrap et Coupler.io. L’équipe de dev de Coupler.io livrait plein de nouveautés que la petite équipe marketing n’arrivait pas à couvrir côté contenu. Sur Mailtrap, c’était l’inverse. La direction a donc décidé de transférer une partie des marketeurs de Mailtrap vers Coupler.io, et une partie des devs de Coupler.io vers Mailtrap. Ça, le squad ne peut le détecter ni décider seul, il faut une vision macro, donc une intervention du management.
Galen Low : Qui prend ce type de décision ? Toi, les ops… ?
Julia Ryzhkova : C’est niveau C-level. Moi, je remonte le besoin pour mon produit, pareil pour Mailtrap, et les décideurs tranchent car ils voient l’ensemble et sont peu impliqués dans les détails du quotidien — ce qui leur donne la hauteur nécessaire.
Galen Low : Cette réallocalisation était permanente ou temporaire ?
Julia Ryzhkova : On peut soit embaucher, soit switcher temporairement — là, c’est un mélange des deux. Mais cela ne nous dérange pas, comme je l’ai dit, on est Agile. Rebasculer une équipe sur un autre produit pour six mois ou un an n’est pas un problème.
Galen Low : Mais tout ça vient d’un souci de synchronisation entre squads, non ? À quelle fréquence l’équipe marketing et l’équipe technique se parlent-elles ?
Julia Ryzhkova : Ça dépend, mais on a au minimum la démo où les devs présentent les livraisons et une réunion hebdo où je partage les sorties/roadmap à venir côté dev comme côté marketing. Il y a un process d’input management : chacun peut formuler une demande à l’autre équipe, révisée chaque semaine, priorisée ou mise en attente.
Le marketing propose d’améliorer la homepage, le dev demande une nouvelle maquette d’email — tout cela est intégré/planifié ensemble.
Galen Low : Super intéressant. On n’a pas parlé de géographie et fuseaux horaires. Vos squads sont dispersées dans le monde. Faut-il être hyper efficace pour que ça marche en distribué ?
Julia Ryzhkova : Je dirais l’inverse : le remote permet justement plus d’efficience. Parfois, c’est difficile de synchroniser l’Argentine et la Thaïlande, certes, mais c’est mineur.
La majorité travaille à distance depuis 15+ pays, mais avec docs partagées et channels publics, tout est super organisé. Le travail asynchrone fait qu’on n’a pas besoin d’autant de réunions ou de planifier sur des créneaux impossibles !
Galen Low : C’est fondamental : asynchrone ne veut pas dire jamais de réunions mais qu’on se concentre sur l’essentiel, chacun peut consulter les docs en différé. Et « remote » n’est pas juste « télétravail » : la transparence documentaire est capitale.
Y a-t-il une sorte de rejet du management de projet dans ces squads auto-gérées ? Est-ce un gros mot ?
Julia Ryzhkova : Non, pas de rejet. On aime expérimenter, il n’y a aucune obligation. Rien ne sert d’imposer un vrai cursus PM à tout le monde. On préfère partager les points clés lors des guildes, en fonction des besoins. Si quelqu’un souhaite se former plus, il utilise son budget formation, mais c’est du « just in time ».
Galen Low : J’aime ce partage artisanal des compétences, sans chercher à faire de tout le monde un chef de projet ni de chaque chef de projet un dev. L’idée, c’est d’apprendre chacun des autres.
Pour finir, la question phare : tu as mené un PMO, tu es aujourd’hui plus stratégique en tant que cheffe de produit, penses-tu que les squads auto-gérées sont le futur du management de projet ?
Julia Ryzhkova : Je pense que c’est l’avenir des entreprises produit qui réussissent.
Les équipes auto-gérées permettent au chef de projet de se concentrer sur la stratégie, le produit ou le client. C’est là qu’on atteint enfin le nirvana du « important mais pas urgent » — cet espace qu’on a trop rarement. L’équipe gère l’urgent et tu peux enfin te consacrer à l’essentiel.
Mais bien sûr, tous ne sont pas prêts à être auto-gérés, surtout les juniors. Certains nécessitent plus d’encadrement, même au niveau senior parfois. Donc il y aura toujours de la place pour le management classique de projet.
Mais pour obtenir des résultats ambitieux sur un produit, il faut atteindre ce degré d’auto-gestion qui libère le chef de projet pour la stratégie et l’amélioration globale, au lieu de régler chaque détail.
Galen Low : Très intéressant. Ce que je retiens : l’important contre l’urgent. Beaucoup de chefs de projet classiques souffrent de ne jamais avoir le temps pour le stratégique. Mais il ne s’agit pas de supprimer leur poste, plutôt de l’élever et d’occuper ce créneau.
Julia Ryzhkova : La gestion de projet reste cruciale. Mais avec une équipe auto-gérée, on peut se permettre d’être moins dans l’opérationnel terrain et plus dans l’anticipation, le « quoi faire » plutôt que le « comment ».
Galen Low : C’est ça, élever la fonction et être proactif.
Julia, toutes ces idées sont super. Pour moi, l’essentiel c'est la culture « mindset produit ». Ce n’est pas juste penser au produit dans une logique cycle de vie/lancements, mais être ouvert à l’adaptabilité : comprendre que tout change tout le temps, et que l’équipe doit répondre au changement en comprenant son sens, pas en le subissant.
Votre job, votre backlog, vos outils de gestion, tout peut changer trois fois en un an, mais c’est le mindset qui compte — et c’est clé dans des équipes auto-gérées.
Dernière question, un conseil pour une organisation qui voudrait tester ?
Julia Ryzhkova : N’essayez pas, faites-le. Commencez par une petite équipe, donnez-lui l’autorité et regardez les résultats. Les résultats viendront. Quand vous verrez les bénéfices, vous aurez envie de propager ce modèle dans toute l’entreprise. Il faut juste commencer avec les personnes qui incarnent cet état d’esprit.
Galen Low : Merci Julia d’avoir partagé tout ça. Ce fut passionnant d’apprendre comment vous fonctionnez chez Railsware, comment les squads auto-gérées prennent forme, comment l’Agile est mis en œuvre dans le studio produit.
J’espère que nos auditeurs sont repartis avec de bonnes idées pour insuffler une culture d’auto-gestion, sans se sentir menacés pour autant ! Reviens-nous parler de l’intégration de l’IA dans Coupler.io, ce sera passionnant…
Julia Ryzhkova : Avec plaisir, j’espère pouvoir vous raconter tout cela bientôt.
Galen Low : Merci beaucoup, génial.
Julia Ryzhkova : Merci. C’était vraiment agréable d’échanger, ce sont des sujets qui m’inspirent beaucoup et j’espère que cela inspirera d’autres personnes à tenter l’aventure.
Galen Low : Merci encore.
Julia Ryzhkova : Merci !
Galen Low : Et vous, qu’en pensez-vous ? Les équipes auto-gérées sont-elles l’avenir, ou ont-elles des limites qui les rendent inadaptées à certains contextes ?
Racontez-nous vos expériences : quelle est l’équipe projet la plus autonome avec laquelle vous avez travaillé, et comment cela s’est-il passé ? À l’inverse, quelles sont vos pires frustrations comme chef d’orchestre plus que stratège ? Partagez en commentaire.
Et pour perfectionner vos talents de leader stratégique de projet, rejoignez notre collectif !
Rendez-vous sur thedigitalprojectmanager.com/membership pour intégrer une communauté qui partage ses connaissances, résout des problématiques complexes, et façonne l’avenir de notre métier — ensemble.
Des templates robustes, des sessions de formation mensuelles, des événements communauté et groupes de « mastermind » : être membre, c’est bénéficier de plus de 1000 pairs à vos côtés pour naviguer dans votre carrière de delivery digital.
Si vous avez aimé cet épisode, abonnez-vous et restez connectés sur thedigitalprojectmanager.com
À bientôt et merci de votre écoute.
