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

• 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