Après avoir forcé tous les ingénieurs à participer à des appels commerciaux, la plateforme a été entièrement réécrite en deux semaines

 (old.reddit.com)
22 points par GN⁺ 2025-08-23 | 5 commentaires | Partager sur WhatsApp
  • Une startup a profondément transformé sa manière de développer son produit en faisant participer directement les ingénieurs aux appels commerciaux
  • Lors de ces appels, ils ont découvert que les produits concurrents étaient trop complexes pour les utilisateurs non techniques, que les clients voulaient moins des logs et des métriques qu’une simple confirmation visuelle (coche verte) indiquant que la surveillance fonctionne, et qu’ils demandaient souvent simplement « Est-ce que quelqu’un peut s’en charger à notre place ? »
  • Grâce à cela, une équipe très centrée sur le backend a fini par comprendre le point de vue des utilisateurs et a commencé à concevoir elle-même une nouvelle architecture, sans intervention du PM
  • En seulement deux semaines, la plateforme a vu 60 % de ses fonctionnalités supprimées, l’ajout d’une barre de progression, d’une intégration Slack et de fonctionnalités de workflow géré pour le client, avec à la clé 70 % de tickets de support en moins
  • La leçon tirée de cette expérience est que les utilisateurs veulent surtout que leur problème soit résolu, pas du code élégant, et que chaque fonctionnalité génère un coût non pas en volume de code, mais en confusion pour l’utilisateur

Contexte et expérience

  • Un ingénieur senior DevOps s’opposait à l’idée de participer aux appels commerciaux, mais a fini par accepter à condition de n’en faire qu’au moins 5
  • Le fondateur estimait que le design du produit ne changerait que si les ingénieurs entendaient directement le langage et les problèmes des clients

Enseignements tirés des appels commerciaux

  • Ils ont expliqué que les produits concurrents étaient trop complexes pour les utilisateurs non techniques
  • Les clients voulaient une validation intuitive, comme une simple coche verte, plutôt que des métriques compliquées
  • De nombreux clients demandaient un « service géré », préférant externaliser la résolution du problème plutôt que simplement utiliser un outil

Résultat de la réécriture du produit

  • L’équipe a supprimé 60 % des fonctionnalités existantes pour se concentrer sur l’essentiel
  • Une simple barre de progression a été ajoutée pour améliorer l’expérience utilisateur
  • L’intégration Slack a permis de simplifier le flux des demandes
  • Des workflows done-for-you ont été proposés pour refléter directement les besoins des clients
  • Au final, les tickets de support ont diminué de 70 % et l’utilisabilité ainsi que la satisfaction produit se sont nettement améliorées

Leçons clés

  • Les utilisateurs ne veulent pas une solution technique élégante, mais que leur problème soit réellement résolu
  • Comprendre l’utilisateur est plus important que la précision technique
  • Chaque fonctionnalité a un coût, non pas en code, mais en confusion pour l’utilisateur

Évolution de la culture d’équipe

  • Par la suite, l’entreprise a rendu obligatoire pour tous les ingénieurs de participer à 5 appels commerciaux par trimestre
  • Le fait pour les ingénieurs d’entendre directement la fatigue des clients et leur attente de « quelque chose qui fonctionne, tout simplement » est devenu un élément durable de la culture produit

Principaux points à retenir des commentaires Reddit

  • Débat autour du rôle du PM
    • Certains ont estimé que le vrai problème était l’absence d’un bon Product Manager, et qu’il était inefficace de faire gérer aussi les appels clients par les ingénieurs
    • À l’inverse, d’autres ont rétorqué que « le PM ne sert souvent que de traducteur, et les meilleurs résultats apparaissent quand les ingénieurs s’approprient directement les problèmes des clients »
  • La valeur du contact direct avec les clients
    • Plusieurs commentaires soulignent que le fait, pour les ingénieurs, d’entendre directement la voix des utilisateurs apporte des insights très puissants
    • Certains ajoutent que, dans les startups en phase initiale ou les petites équipes, il est courant que les ingénieurs assument aussi en partie un rôle de PM
  • Regards critiques
    • Certains ont critiqué l’approche en disant qu’il s’agissait simplement de faire porter aux ingénieurs un échec du leadership ou de la culture
    • D’autres ont demandé si couper des fonctionnalités et simplifier relevait vraiment d’une amélioration, avertissant qu’à long terme cela pouvait négliger les power users et les besoins en fonctionnalités avancées
  • Partage d’expériences positives
    • De nombreux témoignages expliquent que, dans des secteurs comme la banque ou les dispositifs médicaux, il existait aussi des systèmes où tous les employés faisaient l’expérience du support client ou de la vente
    • Beaucoup se retrouvent dans l’idée que le dogfooding ou le fait d’être directement face aux clients aide à améliorer à la fois la qualité du produit et la culture d’entreprise
  • Enseignement global
    • Faire ressentir directement les problèmes des clients est un outil d’apprentissage très puissant,
    • mais le cœur du débat montre aussi qu’à long terme, cela doit être combiné à de vraies compétences en PM, UX et design pour construire une stratégie produit équilibrée

À lire aussi

5 commentaires

 
meteorizer 2025-08-25

Au final, c’est sans doute une question d’efficacité.
Il y a vraiment beaucoup d’avantages à échanger directement avec les clients, mais les communications fréquentes comme les réunions et les appels cassent souvent la continuité du travail et réduisent le temps pouvant être consacré au développement.
Dans ce cas, l’entreprise devrait probablement prévoir des recrutements pour compenser cette baisse de productivité.
Le problème, c’est qu’en général, elle n’a pas l’intention de le faire.
Au final, faute de temps, il y a de fortes chances que la qualité se dégrade à mesure que le temps passe.
Je pense qu’il faut bien peser le pour et le contre.
 
laeyoung 2025-08-24

Je ne sais pas bien pourquoi le lien a été laissé en old reddit sur Hacker News, mais le chemin vers l’interface actuelle de Reddit est ici.
 
xguru 2025-08-24

Sur Hacker News, on dirait que la plupart des gens publient les URL de Reddit en version old reddit. C'est sans doute parce que c'est plus léger.
 
cnaa97 2025-08-23

Si l’objectif d’une organisation est de relever son plancher de performance, j’admets qu’une organisation par rôles, comme une équipe composée uniquement de développeurs web front-end ou une équipe de développeurs d’apps, est pertinente.

Mais pour une équipe ou une organisation qui vise un niveau d’excellence plus élevé, se structurer par rôles présente forcément des limites.
Comme le dit le texte, faut-il vraiment que les planificateurs, designers, PM et ingénieurs se répartissent chacun leur travail et avancent comme sur un tapis roulant d’usine ? Cela amène à se poser la question. L’idéal n’est pas un travail typique de simple « responsable » chargé de quelques tâches précises, mais une forme d’organisation où des membres ayant chacun leur spécialité se réunissent, définissent ensemble un objectif commun, et où l’ensemble des membres se soutient mutuellement.

Dans beaucoup d’entreprises, l’organisation se construit sous forme de task forces, via des spin-offs ou la constitution d’équipes. Mais là aussi, comme on ne fait que regrouper des personnes (des rôles), cela peut produire un renforcement négatif — par exemple : « j’essaie de faire quelque chose, mais l’entreprise ne m’aide pas ; autant abandonner » — et l’on risque alors de ne perdre que les talents les plus importants, comme les key members. C’est pourquoi une organisation orientée par objectif a elle aussi absolument besoin du soutien actif d’une organisation par rôles.
 
GN⁺ 2025-08-23
Avis Hacker News
  • À la fin, ils ont imaginé une architecture entièrement nouvelle sans mon « PMing ». La raison, c’est qu’ils ont enfin vraiment compris qui utilisait réellement notre produit. Au fond, la conclusion de cette expérience, c’est : « on a confié des sales calls aux ingénieurs, et au final le vrai problème, c’est que les PM n’arrivaient pas à assurer correctement la communication entre les clients et l’ingénierie, tandis que l’ingénieur DevOps était au contraire la personne qui transformait rapidement les besoins clients en solutions réellement fonctionnelles »
    • Il arrive que des ingénieurs, trop sûrs d’eux, pensent que si les utilisateurs s’en sortent mal avec le produit, c’est que ceux-ci l’utilisent mal. Dans cette logique, « si ça se passe mal, c’est parce que l’utilisateur est stupide », et non parce que le design complexe que j’ai créé pose problème. Rien que dans le camp du Desktop Linux, on pourrait écrire un livre entier sur les fois où des plaintes d’utilisateurs ont été ignorées. Si un ingénieur têtu se croit supérieur aux PM comme aux utilisateurs, rien n’avance. Mais si on le met directement au contact des utilisateurs, alors au lieu du PM habituellement conciliant, ce sont de vrais utilisateurs agacés qui déversent des critiques sur « cette merveille de création » comme s’il s’agissait d’un hamster ingérable. C’est un processus intimidant, mais qui démolit aussi l’ego des ingénieurs. De mon point de vue, il ne s’agit pas de montrer que les PM sont idiots, mais d’apprendre l’humilité aux ingénieurs. Avec le temps, leur arrogance revient, donc ce processus doit être répété régulièrement
    • Je suis la seule personne de mon équipe de mécanique, dans une grande entreprise, à savoir coder. L’équipe IT interne développe divers logiciels, mais la plupart sont jugés médiocres par mes collègues. Alors je refais carrément ces outils ou j’invente des compléments pour améliorer des programmes « médiocres » impossibles à remplacer, afin de faciliter le travail. Ce n’est pas forcément que je développe mieux que l’équipe IT interne, mais j’ai l’impression de mieux comprendre ce dont moi-même, c’est-à-dire notre équipe, avons réellement besoin, parce que je vois les choses du point de vue de l’utilisateur réel. Et comme c’est moi qui utilise ce logiciel, ma motivation est naturellement plus forte. C’est pour ça que le titre m’a parlé. Cela dit, je pense aussi que ce qui est décrit dans l’article peut tout à fait se produire dans la réalité. Je ne suis simplement pas familier avec les processus formels de développement logiciel ou de gestion de projet
    • Je dirige une petite startup tech qui fait 2 millions de dollars de chiffre d’affaires annuel. Il m’est arrivé de prendre moi-même le support client pendant quelques jours quand l’équipe manquait de ressources. À chaque fois, j’ai été frappé par le nombre de plaintes clients qui, en temps normal, n’atteignaient jamais l’équipe d’ingénierie. Les personnes du support ont tendance à se concentrer sur la « résolution » des problèmes par leurs propres moyens, sans que cela débouche sur des améliorations de fond côté engineering
    • Ce qui frappe, c’est que personne ne semble se demander pourquoi le logiciel était aussi mauvais au départ. À mon avis, on ne peut pas faire porter toute la responsabilité à un seul PM. En réalité, c’est un problème de système : Agile/Scrum dilue les responsabilités, et les développeurs expédient des tickets mal ficelés à un rythme trop rapide, ce qui finit par produire un logiciel bancal. C’est un résultat courant quand une organisation logicielle « moderne » devient trop lourde
    • En lisant ça, ma première pensée a été : « c’est comme ça qu’on faisait du logiciel avant que les PM ne mettent la main partout ». Quand on installe les ingénieurs à côté des personnes qui utilisent vraiment l’outil, on se rend souvent compte qu’on n’a pas besoin de PM et que tout le monde est bien plus heureux. Bien sûr, il existe d’excellents PM, mais dans mon expérience ils ont souvent tendance à défendre leur pré carré, et, étonnamment, il leur arrive aussi de très mal connaître à la fois l’ingénierie et les clients
  • J’ai souvent vu des ingénieurs désalignés par rapport au produit. Un collègue ajoute quelque chose sans prévenir personne, l’UI devient confuse, ou bien le contenu du site web ne correspond plus à la réalité du produit. Et avec une longue boucle du type [produit -> PM -> système de bug tracking -> ingénieur -> correctif -> QA -> produit], l’essentiel finit certes par être corrigé, mais les petits irritants restent des éternités. Si on ne garde plus que [produit <-> ingénieur], le gain de productivité peut être étonnant. Beaucoup d’ingénieurs n’ont en fait jamais vraiment vécu l’expérience globale du produit et ne savent même pas très bien ce qui a changé entre l’an dernier et cette année
    • J’ai eu une expérience similaire et, curieusement, c’était plus fréquent dans les endroits où il y avait beaucoup de PM. La pire expérience que j’aie vécue, c’est une entreprise qui voulait imposer un ratio fixe de PM et de « Product Designers » par rapport au nombre d’ingénieurs. En additionnant designers, produit, projet et programme, ils étaient finalement plus nombreux que les ingénieurs. Cela n’a fait qu’aggraver la situation. Une partie du travail consistait aussi à éviter la bureaucratie des PM et leurs inquiétudes sur le fait qu’on empiète sur leur rôle. Les excellents PM sont vraiment précieux, mais aujourd’hui le titre de Product Management donne l’impression d’attirer trop de gens bureaucratiques et obsédés par les process. Les influenceurs du Product Management aggravent aussi le problème
    • Cela dit, je ne pense pas non plus que forcer les ingénieurs à participer aux sales calls soit la bonne réponse. Mener avec succès un appel de ce type demande beaucoup de soft skills, or les ingénieurs ne sont ni formés pour ça, ni recrutés pour ça. (Par « sales call », j’entends ici un appel de découverte initial, avant une démo ou un PoC. Pour des démos presales complexes, il est normal qu’un ingénieur accompagne, mais en principe ce rôle devrait relever du produit)
    • Il y a énormément de façons dont cela peut mal tourner, et je les ai toutes vues de mes propres yeux. Par exemple quand les PM ou les PO monopolisent tous les échanges avec le client, ou quand le client évite toute conversation avec les développeurs et ne transmet que sa propre interprétation des besoins des utilisateurs, ou encore quand les développeurs veulent uniquement écrire du code, ou qu’on impose que toute communication passe seulement par les PM et le bug tracker. Avec une plateforme logicielle commerciale, les limites techniques peuvent aussi rendre le workflow très mauvais. Il y a toujours quelque part un facteur qui bloque la communication, et cela peut venir du client, du management intermédiaire ou des développeurs eux-mêmes. Il n’est même pas rare qu’une mauvaise solution soit décidée dès le départ, tandis que développeurs et utilisateurs démarrent sans connaître les détails. Il y a vraiment mille façons de ne pas réussir à construire un bon système pour les utilisateurs
    • Je pense qu’il est crucial que les ingénieurs comprennent profondément le produit lui-même. Faire coïncider l’aspect produit est plus difficile que l’ingénierie de base. La plupart des produits que j’ai vus échouer ont échoué pour des raisons produit ; il est donc logique, à mes yeux, d’aligner davantage les forces de l’équipe sur cet aspect
  • À l’inverse, il arrive aussi que les ingénieurs finissent réduits à un rôle de support technique. Quand on assiste directement chaque client, on accumule des hotfixes et des solutions sur mesure ; comme rien n’est correctement testé, on ne fait qu’empiler la dette technique, puis on se fait rapidement dépasser dès qu’un concurrent plus gros et mieux financé lance un produit plus abouti. Pour moi, c’est un échec classique du product management. Cela signifie que les PM ne transmettent pas correctement les besoins clients aux ingénieurs, ou qu’ils ne savent pas non plus pousser dans l’autre sens. Faire intervenir des ingénieurs dans les sales calls n’est pas une approche scalable une fois que la base client atteint une certaine taille et maturité. Et si un product manager veut vraiment qu’un ingénieur fasse des sales calls, alors cet ingénieur devrait aussi toucher une part des commissions de chaque compte. Jamais je ne prendrai en charge des sales calls sans commission
  • Dans un environnement comme une startup, où chaque membre de l’équipe doit avoir une compréhension profonde des besoins clients, c’est une stratégie extrêmement efficace. Les projets auxquels j’ai participé directement pour définir les exigences du produit avaient un taux de réussite bien supérieur. Les résultats étaient bien meilleurs que lorsque je me contentais d’implémenter des exigences simplement « transmises »
    • Veux-tu dire qu’il était plus facile de suivre des consignes que tu avais toi-même écrites, ou bien que le fait de participer directement donnait une meilleure UX ?
  • « réécriture terminée en 2 semaines, 60 % des fonctionnalités supprimées, simple barre de progression ajoutée, intégration Slack mise en place, workflow “done-for-you” proposé -> 70 % de tickets de support en moins » Si c’est vrai, alors il y avait clairement quelque chose de gravement dysfonctionnel
    • Reddit est célèbre pour l’explosion des récits inventés, et cette histoire, qu’elle soit inspirée de faits réels ou totalement fictive, est bourrée de tics d’écriture typiques de Reddit avec un parfum de storytelling business à la LinkedIn
    • J’y vois un cas de B2B SaaS qui a pivoté plusieurs fois tout en gardant une documentation produit très pauvre. Et, oui, ce genre de situation est bien plus courant qu’on ne le pense
    • Rien qu’au ton, avec ces phrases courtes à la LinkedIn suivies de retournements dramatiques répétés, on comprend facilement que c’est une fiction
    • C’est Reddit, donc évidemment que c’est inventé. Je ne comprends même pas comment ce genre de post finit par devenir un sujet de discussion
  • Avec un tel résultat, il faudrait licencier sur-le-champ les PM, les PO et l’équipe marketing. Deux choses sont claires : soit ils n’ont pas compris ce que les clients voulaient réellement, soit ils n’ont pas su transmettre correctement ces besoins à l’équipe de développement, soit les deux. Ensuite, ils ont le cerveau tellement formaté par les systèmes qu’il vaudrait peut-être mieux supprimer tous les intermédiaires entre les clients et l’équipe de développement
  • Dans un ancien poste, les ingénieurs participaient régulièrement aux appels commerciaux. C’était intéressant de voir ce que voulaient les clients et comment notre produit se vendait, mais ce n’était pas révolutionnaire. Les fonctionnalités réclamées par les clients étaient déjà dans la roadmap, et il y avait aussi une fonctionnalité confuse, mais elle avait été conçue ainsi à cause d’exigences spécifiques de notre plus gros client. L’équipe de développement aurait préféré faire plus simple, mais dans ce cas nous n’aurions pas pu répondre aux besoins de ce gros compte. On a donc fini par créer une version « light » plus simple, que tout le monde utilisait sauf ce grand client. Mais là encore, ce changement n’est pas venu du fait d’avoir accompagné les appels commerciaux ; tout le monde savait dès le départ que c’était compliqué, simplement on ne pouvait rien changer avant que la roadmap ne le permette
  • Je me reconnais profondément dans l’idée de « enfin comprendre qui sont les vrais utilisateurs ». On dit souvent que « le plus grand problème de la plupart des ingénieurs, c’est le sur-engineering », mais en réalité le sur-engineering vient très souvent d’une mauvaise compréhension des cas d’usage clients. C’est ça, le problème plus fondamental. En tant qu’ingénieur, l’une de mes frustrations les plus fréquentes est de voir d’autres ingénieurs ne faire aucun effort pour comprendre quel produit se vend réellement. Que ce soit par manque d’adéquation au poste, par orgueil ou, le plus souvent, à cause de la culture d’entreprise ou de la structure d’incitation
  • J’ai travaillé autrefois dans une entreprise qui développait une solution de robocall pour CRM, et lors d’un offsite ils ont décidé que tout le monde devait faire des cold calls en suivant le script. Ils n’avaient ni compréhension ni intérêt pour l’anxiété que cela pouvait provoquer chez les non-commerciaux. C’est à partir de là que j’ai commencé à envisager de partir
  • J’ai déjà vu une situation similaire. Une équipe monitoring insistait pour que « toutes les alertes soient directement créées sous forme de tickets par les ingénieurs de première ligne ». Sauf qu’il y avait plus de 10 000 alertes par heure. Les problèmes importants se perdaient dans le bruit, le management s’épuisait, et à un moment on a fini par imposer : « équipe monitoring, ouvrez donc vous-mêmes tous les tickets et essayez de les traiter ». Le lendemain, après avoir exclu les alertes de faible importance, le nombre d’alertes uniques est tombé à une dizaine par heure, puis tout le reste a été fermé progressivement. C’est seulement à ce moment-là que les « tableaux de bord tout verts » sont devenus réels (avant cela, c’était juste du vert forcé pour le montrer aux médias et à Gartner Group)