Un titre que vous trouverez peut-être trop technique ou catchy mais qui résume finalement assez bien l’organisation singulière de Pearltrees de ces dernières années qui aura permis plusieurs innovations radicales dans le secteur du numérique éducatif.

Mais avant d’en arriver à ce titre, je me suis simplement demandé il y a quelques jours pourquoi et comment nous avions pu faire tout ça avec un Product Manager à mi-temps ? 🤔

Au vu des organisations de startups comparables, cela me semblait très peu et je me suis dit que j’avais trouvé le sujet de mon premier article de blog ! 💡

Pour ceux d’entre vous qui ne travaillent pas dans des équipes Produit ou Technique de startup, voici ce que ChatGPT nous apprend sur les ratios que l’on retrouve habituellement entre ces deux équipes :

“Bonjour mon brave, le ratio moyen entre l’équipe Produit et l’équipe Technique dans une startup est généralement de 1:5.”

Oui, je me fais plaisir sur mes prompts ChatGPT.

Pearltrees de 2017 à 2023, c’est un mi-temps Produit, assurant également le design, et 6 ingénieurs 💕 en moyenne, soit un ratio de :

1:12

Comment expliquer une telle différence ?

Après réflexion, il y a essentiellement deux raisons à cela, toutes deux culturelles :

• Une culture Produit forte et distribuée : c’est cette spécificité organisationnelle que je vais développer aujourd’hui.
• L’excellence opérationnelle : cela ne se limite pas à l’équipe Produit et ça sera probablement la source d’articles à venir.

L’organisation singulière de Pearltrees apporte à l’équipe Produit des ressources considérables tant sur ses capacités de “delivery” (pondre pleins de fonctionnalités de qualité dans les temps) que de “discovery” (choisir les bonnes fonctionnalités). J’ai identifié deux éléments clés structurants que je développerais ici :

• 💪 Des développeurs chefs de projets
• 👂 Une équipe Produit ET Succès Client

💪 Des développeurs chefs de projets

Plutôt que d’avoir une responsabilité partagée entre produit, design, marketing et technique sur le succès d’une fonctionnalité (ou user story pour les amateurs de Scrum) on préférera ici avoir un seul responsable : le développeur. Il est à noter que le Product Manager reste quant à lui responsable du succès de l’ensemble de l’itération (ou Sprint), faut pas déconner 😉.

Les conséquences de cette prise de responsabilité totale par un développeur sur son histoire utilisateur sont multiples :

• Maîtrise des délais : il fait converger toutes parties prenantes et crée ses propres deadlines et itérations au sein de son histoire utilisateur.
• Pilotage de la qualité : il obtient un haut niveau de qualité sur l’usage principal et traite les situations secondaires avec un investissement contrôlé.
• Autonomie sur le Produit : il prend des initiatives sur les détails fonctionnelles de son histoire utilisateur qui ne seraient pas identifiés de manière exhaustive préalablement.

Les gains du point de vue du Product Manager (PM pour les intimes) sont évidents :

• Un planning d’ensemble qui reste sous contrôle et prévisible : l’attention du PM peut alors se porter là où il a le plus de valeur en identifiant les histoires utilisateurs à retirer ou ajouter.
• Des histoires utilisateurs livrées avec un haut niveau de qualité : les problèmes sont identifiés plus tôt, souvent traités en autonomie par le développeur et le PM n’est sollicité que pour trouver des solutions créatives sur des problèmes complexes. Au-delà du temps gagné sur l’assurance qualité, le PM est moins interrompu sur des petits problèmes nécessitant de replonger en profondeur quotidiennement sur chaque histoire utilisateur.
• Des spécifications finalisées et maintenues par le développeur : le PM laisse au développeur le soin de finaliser une spec qui ne sera jamais exhaustive à 100% par nature et évoluera au cours de la réalisation. D’une certaine manière, la spec devient le code. En fonction de la nature de l’histoire utilisateur et du niveau de séniorité du développeur, la spécification en amont par le PM sera plus ou moins détaillée : un gain de temps considérable.

Il existe bien entendu des conditions pour entretenir cette culture et faire fonctionner une organisation qui n’est pas naturelle :

• Une équipe technique avec des profils généralistes et curieux qui souhaitent développer des compétences au-delà de la réalisation d’un beau code robuste.
• Un onboarding adapté des jeunes développeurs qui devront développer rapidement des compétences de gestion de projet.
• Un management transversal de l’équipe produit pour faire monter en compétence l’équipe technique sur des dimensions produit, design et qualité.
• Une perte marginale de vélocité de l’équipe technique qui se retrouve à faire du Produit pour un impact collectif supérieur.
• Des processus qui encadrent l’itération et les histoires utilisateurs et qui s’assurent que cette organisation “contre nature” tienne dans la durée (une bonne source d’articles pour le futur).

👂 Une équipe Produit ET Succès Client

On voit de temps en temps des directions produit et technique unifiées sous la direction d’un Chief Product & Technology Officer (CPTO), au bénéfice d’une meilleure “delivery”, mais rarement l’union du Produit et du Succès Client, une combinaison qui s’est avérée redoutable pour la “discovery”. Vous ne vous êtes pas demandé ce que foutait la ressource produit l’autre moitié de son temps ? Et bien ça, parler aux utilisateurs, mais surtout observer et écouter.

Pour comprendre l’impact de cette organisation sur le PM, jetons d’abord un œil à certaines situations dans lequel il se retrouvera en tant que Customer Success Manager (CSM), illustrés de quelques exemples concrets :

• Traverser la France pour passer la matinée avec ses utilisateurs pour comprendre leurs problèmes au quotidien. Des freins qui ne se partagent pas toujours par écrit, sur un coup de téléphone ou une visio (notamment les enjeux politiques).
• Échanger avec tous les profils d’utilisateur sans tomber dans le cliché d’un persona.
• Passer des centaines d’heures à former les utilisateurs et vivre avec eux la découverte du produit : aider un utilisateur sur l’ouverture d’un nouvel onglet dans son navigateur et le voir cliquer sur des éléments graphiques qui ne sont pas des boutons d’action sont des retours précieux et captables uniquement sur le terrain.
• Explorer et connaître tous les usages du produit pour les valoriser auprès d’autres clients. C’est comma ça que l’enseignement à distance asynchrone en sport-études ski a inspiré la réponse de Pearltrees Éducation face à la COVID 😍.
• Devenir un expert métier pour approfondir la compréhension des enjeux de ses clients et maximiser l’impact du produit : comprendre l’impact de la politique migratoire luxembourgeoise sur son système éducatif a donné des clés de compréhension sur ses besoins en numérique éducatif 🤓

Les gains pour le PM sont là aussi évidents :

• Construire un backlog de fonctionnalités s’appuyant sur des besoins profonds, à fort impact pour le client.
• Rendre plus riches et productives les discussions avec les équipes succès client et commerciale.
• Obtenir des retours utilisateurs en direct sur les nouvelles fonctionnalités.
• Résoudre des bugs complexes en quelques minutes en appelant un client avec qui on a une super relation de confiance (de vrais chouchous 🩷).

Il existe là aussi des conditions pour mettre en place et maintenir une telle organisation :

• Être en mesure de dédoubler sa personnalité 🤪 pour que le CSM n’influe pas le PM dans ses arbitrages de roadmap : la stratégie, les intérêts commerciaux et les besoins de l’équipe techniques ne doivent pas en pâtir.
• Gérer son temps à 50/50 dans un contexte ou la saisonnalité d’un CSM et d’un PM ne sont pas toujours alignés : mon moment préféré ? Lancer une nouvelle itération au milieu d’une rentrée scolaire 🎊.
• Ne pas faire l’économie d’écouter ses collègues sur leurs propres retours clients : même si 80% des retours sont déjà connus, leur fréquence et leur source permettent d’ajuster l’impact des histoires au backlog et les 20% restant sont parfois les retours ayant le plus de valeur car ils apportent un regard neuf.
• Aimer la relation client parce que l’objectif n’est pas de jouer au CSM à mi-temps pour faire de la Product Discovery : l’objectif c’est de réduire le churn, faire de l’upsell, obtenir un taux d’usage hors norme, etc.

En conclusion

Il n’y a pas de bonne ou de mauvaise situation organisation. Je dirais que cette organisation était particulièrement adaptée à ce qu’on avait à faire : créer des produits radicalement innovants.

Démocratiser l’organisation de l’information sur le web, numériser les pratiques pédagogiques des enseignants et granulariser les manuels scolaires ont été rendus possibles par des bonnes décisions, beaucoup d’énergie, mais peut-être par-dessus tout par des équipes qui ont su aller au-delà de leur fonction initiale comme cette équipe technique qui a fait du produit et cette équipe produit qui a fait du succès client.

Si vous êtes allé au bout de ce premier article, vous voudrez peut-être lire le prochain ? Si c’est le cas, n’hésitez pas à me suivre sur LinkedIn pour être notifié 🔔. Vous avez un commentaire ? Ça fait plaisir, c’est juste en dessous.