Blog

Projeter les évolutions fonctionnelles de votre produit dans un temps long : en voilà une belle idée qui réjouit tout le monde (sauf peut-être les équipes produit 😂) !

À première vue, il n’y a pas de quoi faire tout un article sur la planification produit à long terme, sauf que :

• Elle s’oppose au développement agile
• C’est un exercice difficile
• Elle se trouve souvent réduite à une roadmap

Voilà un sujet qui me semblait tout à fait approprié avec cette nouvelle année qui s’engage !

🎯 Quel est l’intérêt à planifier sur le long terme ?

Je vois principalement 3 intérêts à cette planification :

• Piloter plus clairement les investissements sur le produit
• Se donner des objectifs plus ambitieux
• Donner de la visibilité aux équipes et aux utilisateurs

L’intérêt dépasse donc l’équipe produit et bénéficie clairement à toute l’organisation. L’équipe produit prend quant à elle plus de hauteur, gagne en ambition et réalise des choix plus forts.

🔄 Est-il possible de planifier tout en restant agile ?

Le problème est qu’un engagement à long terme sur l’évolution d’un produit est opposé à la logique de développement itératif qui a prouvé sa valeur durant ces 20 dernières années. 😬

S’il est intéressant de planifier à long terme, il faudra être particulièrement vigilant à conserver son niveau d’agilité intact.

Il existe à mon sens deux solutions imparfaites :

• Planifier à long terme en avertissant sur la nature incertaine du plan
• Refuser de communiquer un plan à long terme pour conserver la pureté de son processus agile

Notez que dans les deux cas, on ne pourra pas faire l’économie d’acculturer les équipes et les clients à son processus de développement.

Si nous sommes d’accord pour dire que l’intérêt de planifier à long terme est fort et que le coût de communication et d’acculturation est acceptable, réaliser ce plan à long terme n’en reste pas moins difficile.

🌍 Comment planifier ?

On l’a tous expérimenté en prenant l’avion ou sur une cartographie, dézoomer va avoir deux conséquences immédiates :

• Faire disparaitre les détails
• Voir plus loin

Ce changement de hauteur et de temporalité contraindra l’équipe produit à deux adaptations essentielles :

• Synthétiser par ensemble fonctionnel : à cette hauteur de réflexion, on ne peut plus résonner avec la finesse des fonctionnalités du backlog et l’on doit faire émerger des ensembles fonctionnels. Ces ensembles auront la capacité de transformer le produit plus profondément qu’une accumulation disparate de fonctionnalités.
• Piloter par objectif et impact : sur cette nouvelle temporalité, les fonctionnalités du backlog deviennent fortement périssables. Planifier un impact à atteindre sera bien plus robuste et la solution fonctionnelle retenue sera souvent imprévisible.

Ces adaptations permettront de gagner en clarté sur les choix produits avec deux conséquences immédiates :

• Relier les objectifs “business” de la fonction produit à des investissements fonctionnels concrets.
• Dessiner une stratégie produit à long terme.

📆 Quelle différence entre roadmap et planning produit ?

Ces deux outils de planification portent sur un horizon de temps comparable et dessinent les grandes orientations de l’investissement à venir sur le produit.

Il existe néanmoins deux différences essentielles sur le fond et sur la forme :

• Sur le fond, la roadmap se limite à l’investissement dans le produit alors que le planning a vocation à intégrer toutes les dimensions de la fonction produit : son organisation, ses compétences et ses processus.
• Sur la forme, la roadmap a vocation à être partagée largement au sein de l’organisation, voir en dehors. Le planning produit est quant à lui construit par l’équipe produit et discuté en comité exécutif.

D’une certaine manière, on peut considérer la roadmap comme une sous partie du planning du produit.

En conclusion

Sans plan à long terme, le risque est d’avoir une équipe produit moins créative qui investira itération après itération dans des fonctionnalités hétérogènes avec un bon rendement à court terme, mais dont l’impact à long terme sera plus faible.

Planifier sur le long terme est donc un outil indispensable pour la fonction produit qui permettra de relier ses objectifs business à une stratégie d’investissement concrète dans le produit et dans l’équipe produit.

J’espère que ce dernier article de l’année 2024 t’aura intéressé. J’en profite pour te souhaiter une très bonne année 2025 ! 🤗🎉

S’intégrer avec succès dans une équipe repose sur sa capacité à être assimilé dans un ensemble préexistant, à s’unir pour former un tout cohérent.

Cette intégration est donc une démarche des deux parties :

• L’individu observe, apprend et s’adapte.
• L’organisation accueille et forme.

Une fois l’intégration réalisée, les individus auront bien entendu un impact sur l’organisation, mais c’est cette première étape qui m’intéresse car :

• Elle est absolument essentielle pour se développer sur une base solide
• Elle concerne tous les niveaux de séniorité
• Elle est critique et complexe en Product Management

J’ai choisi de traiter dans cet article le point de vue de l’individu qui intègre une nouvelle organisation et la question du processus d’onboarding sera traité dans un billet dédié.

L’approche que j’ai retenu est celle de l’exploration. À la manière d’une discussion avec un utilisateur, il me semblait intéressant de pouvoir explorer, plonger en profondeur, ou prendre du recul, sans s’enfermer dans un framework contraignant et réducteur.

Pour cela, j’ai imaginé une série de 40 questions qui couvrent l’ensemble des sujets à explorer sans préfigurer de la forme de l’organisation accueillante, de sa taille et de ses modes de fonctionnement. Pour info, je me suis concentré sur les questions liées à la fonction Produit et il vous faudra compléter avec les questions généralistes habituelles.

Bon questionnement à tous 😉

🎯 Objectifs

⭐ Quelle est la mission de l’entreprise ?

🗺️ Quelle est la stratégie de l’entreprise pour atteindre cette mission ?

📈 Quels sont les prochains objectifs à atteindre dans cette stratégie ?

• Quels objectifs d’ensemble ?
• Quels objectifs par fonction : commerciale, relation client, technique et produit ?
• Quels objectifs par produit ou segment de produit, s’il y en a plusieurs ?

🕵 Discovery

🧠 Connaissance du produit

• Est-ce que je peux avoir une démo complète et des comptes de test ?
• Quels sont les principaux besoins adressés et quel est l’impact du produit ?
• Quels sont les principaux indicateurs de performance ?
• Comment obtenir des données d’usage détaillées ?

🗣️ Utilisateurs

• Est-ce qu’il y existe une collection de retours ou bilan d’usages ?
• Qui échange avec les utilisateurs et sous quelle forme ?
• Est-ce que je peux avoir le contact d’utilisateurs avec qui échanger dont un qui utilise beaucoup, un qui utilise peu et un qui n’utilise plus ?

📋 Roadmap et backlogs

• Peut-on me présenter en détail le contenu de la roadmap et des backlogs ?
• Comment le contenu est ajouté et ordonné ?
  • Comment est estimé l’impact d’une nouvelle fonctionnalité ?
  • Comment est estimé le temps de développement ?
• Comment sont traités les bugs ?
• Comment sont gérées les demandes venant des différentes équipes ?

🏛️ Industrie et marché

• Comment se former sur le métier du client et quelles sont les sources d’actualité à suivre ?
• Quels sont les canaux de distribution du produit ?
• Qui sont les concurrents principaux ?
• Est-ce qu’il y a des contraintes de conformité ou de réglementation ?

📦 Delivery

👩🏻‍💻 Qui développe les fonctionnalités et comment ?

• Quelle méthodologie est suivie et quels sont les rituels ?
• Quelles sont les technologies utilisées ?
• Quelle est l’architecture technique ?

🎨 Qui réalise le design et comment ?

• Quelles sont les références design structurantes ?
• Est-ce qu’il existe un système design à respecter ?
• Est-ce que je peux accéder à la liste des éléments graphiques ?

🫠 Qui contrôle la qualité et comment ?

• Est-ce qu’il y a des tests unitaires et sur quel périmètre ?
• Est-ce qu’il y a un plan de test que je pourrais parcourir ?

📣 Qui annonce les nouvelles fonctionnalités et comment ?

• Est-ce que je peux avoir un exemple de com’ auprès des utilisateurs ?
• Comment les fonctionnalités sont présentées en interne ?

✉️ Comment les différents acteurs communiquent-ils ?

• Comment est piloté l’ensemble de la Delivery, de la construction du planning jusqu’à sa mise en production ?
• Est-ce que je peux avoir 2-3 exemples de spécification d’histoires utilisateurs de différentes natures ?

🤝 Équipe produit

Comment les objectifs sont définis et suivis à la semaine, au trimestre et à l’année ?

Comment l’équipe est organisée et quels sont ses rituels ?

Comment l’équipe produit progresse ? Sur quelles compétences ? Avec quel plan de carrière ?

Quels sont les outils de production et de communication utilisés ?

Existe-t-il une culture spécifique dans l’équipe Produit ?

En conclusion

J’ai essayé de rester le plus possible “en haut de la pyramide” et certaines questions en cache plusieurs. Mon idée était d’avoir une vision générale et de ne rien oublier de structurant. Si vous voyez une question qui manque, je suis bien évidemment preneur !

C’est possible que je sois amené à dérouler ces questions prochainement et je mettrai à jour cet article au fil de l’eau si besoin 😉.

Cet article vous a plu ? N’hésitez pas à me suivre sur LinkedIn pour être notifié du prochain 🔔

La culture du progrès dans une équipe produit, voilà un sujet à la croisée de trois sujets passionnants : la culture d’entreprise en startup, les processus d’apprentissage et le product management.

Voici les questions que je me suis posé pour aborder ce sujet :

• 🚀 Pourquoi installer une culture du progrès en startup ?
• 🧠 Comment on progresse ?
• 🏃‍♀️‍➡️ Pourquoi progresser est difficile ?
• 📚 Comment faire progresser une équipe Produit ?

🚀 Pourquoi installer une culture du progrès en startup ?

J’ai eu l’occasion de me pencher dernièrement sur la culture de plusieurs scale-up tech et on retrouve souvent la notion de progrès :

• Doctolib : serve, care, learn, act
• BlaBlaCar : be the member, share more. learn more., fail. learn. succeed., dream. decide. deliver., be lean. go far., fun & serious
• Alan : members first, fearless ambition, distributed ownership, radical transparency, personal and community growth
• Pearltrees : performance, progrès, transparence

La raison me semble évidente, une startup change rapidement et vous avez trois options pour adapter les compétences de votre équipe en conséquence :

• Progresser : votre culture et votre équipe permettent cette adaptation au changement.
• Recruter et / ou remplacer : les compétences arrivent avec de nouveaux profils.
• Ne rien faire : avec des conséquences négatives à moyen terme.

Si nous sommes d’accord que la résilience d’une équipe et sa capacité à progresser sont probablement des critères clés de succès en startup, comment les mettre en place ?

🧠 Comment on progresse ?

Une fois qu’on a décidé d’installer une culture du progrès, on saute souvent une étape en passant directement à la liste des processus à mettre en place ou pire des outils à installer.

Mais comment on progresse ? Sans partir dans un cours sur les neurosciences, on peut le résumer à :

• Choisir les bonnes modalités d’apprentissage
• Répéter fréquemment

Voici quelques exemples avec des modalités et fréquences variées :

• Assister à une conférence, une fois par an
• Suivre une formation en interne, une fois par semaine
• Lire, une heure par semaine
• Fournir du feedback, tous les jours

Si vous vous limitez à la conférence annuelle, vous bénéficiez d’un haut niveau de qualité en termes de connaissance, mais cela reste faible en termes de pédagogie avec une approche “top-down” et des connaissances peu réactivées par la suite.

Au contraire, si vous poussez uniquement vos équipes à lire toutes les semaines, vous apportez une récurrence très bénéfique, mais l’apprentissage “en autonomie” a ses limites.

Enfin, si vous optez seulement pour des formations en interne, vous favoriserez un apprentissage “par les pairs” mais vous vous priverez de la richesse des regards extérieurs.

Est-ce qu’il faut combiner toutes ces approches ? Probablement. Est-ce qu’il existe d’autres approches ? Une infinité, c’est la beauté de l’enseignement.

🏃‍♀️‍➡️ Pourquoi progresser est si difficile ?

Il ne suffit pas d’installer pleins de processus pour que vos équipes progressent miraculeusement. Vous savez quoi ? Progresser est intrinsèquement difficile.

Le sport est une analogie que j’utilise régulièrement dans ce contexte. Dans un sport aussi simple que la course à pied, vous vous rendrez compte que la blessure est vite arrivée si votre programme n’est pas adapté avec des sorties trop longues ou trop fréquentes. En entreprise, vous pouvez imaginer un séminaire interminable mal positionné ou du micro-management sur la durée.

Mais si vous dosez bien votre programme d’entraînement, en courant fréquemment et lentement, votre corps va s’habituer aux chocs, vous allez faire du muscle et finalement courir plus longtemps et plus vite.

Progresser efficacement, c’est ajuster en permanence un curseur permettant de sortir de sa zone de confort en prenant du plaisir et sans se blesser. Apprendre à positionner ce curseur, c’est apprendre à apprendre et devrait être la première leçon de toute startup installant une culture du progrès.

📚 Comment faire progresser une équipe Produit ?

Avant de parler des particularités de l’équipe produit, je pense qu’on peut s’appuyer sur quelques processus assez classiques qu’on viendra personnaliser :

• Feedbacks continus
• One-to-one et coaching
• Formations internes et externes
• Lire des livres

Je vois quand même quelques spécificités à prendre en compte pour progresser en Product Management :

• Un métier encore jeune qui amène à inclure des sources de réflexion externes et à en discuter la traduction collectivement en interne.
• Une fonction pivot qui amène à inclure des thématiques variées (design, technique, marketing et entrepreneuriale) au-delà de sa mission première (discovery et delivery).
• La nécessité de développer et entretenir une expertise sur le métier de ses clients pousse à réaliser des expériences terrain régulières.
• La résolution de problèmes complexes s’accompagne d’une rigueur analytique qui doit se développer en s’appuyant sur des méthodes d’analyse robustes (Descartes, Barbara Minto, etc.)
• Un environnement systémique avec des produits de masse qui installent des standards et qui nécessitent en retour la mise en place d’un processus de veille dédié et des tests de produits réguliers.

Vous avez identifié d’autres spécificités ? Vos commentaires sont les bienvenues !

Pour info, je me suis lancé dans un référencement des livres et épisodes de podcast de référence en Produit car l’offre de contenu s’est considérablement enrichie ces dernières années (notamment en français). Je vous partage ça bientôt !

Cet article vous a plu ? N’hésitez pas à me suivre sur LinkedIn pour être notifié du prochain 🔔

J’ai eu récemment la chance de réfléchir à la création d’un nouveau produit innovant à partir d’une idée.

C’est un exercice assez rare en tant que Product Manager car la définition du produit original qui permettra à une entreprise de réaliser sa mission est souvent conduite par ses fondateurs et c’est d’autant plus le cas quand il s’agit d’un produit innovant.

C’est une étape essentielle dans un projet entrepreneurial parce qu’avant d’embarquer son premier développeur ou de contacter des investisseurs, il faudra rapidement avoir une idée du produit que l’on veut réaliser et de son coût.

Comme je viens de faire l’exercice, je me suis dit que ma méthode pourrait peut-être aider d’autres entrepreneurs. C’est le sujet de cet article.

Pour info, il s’agit d’une adaptation du framework que nous suivions à Pearltrees pour penser nos macro-fonctionnalités jusqu’à des produits complets comme Pearltrees Éducation ou Pearltrees Éditeur.

Voici les 9 étapes que j’ai suivies :

• 🌟 Rappel de la mission de l’entreprise
• 🎯 Objectifs du produit
• 🤕 Besoins profonds des utilisateurs
• 🕵 Produits de référence
• 🔠 Vocabulaire
• 🧭 Approche
• ✍️ Maquette du cas d’usage principal
• 📋 Identification des cas d’usage secondaires
• ⏱️ Estimation du temps de développement

🌟 Rappel de la mission de l’entreprise

Je pars du principe que la mission de votre entreprise a déjà été posée en amont. On agit ici avec une casquette produit et notre fonction est de concevoir un produit qui remplira cette mission.

Imaginons que nous soyons Leboncoin et que notre mission soit la suivante :

Donner à chacun le pouvoir de mieux vivre au quotidien.

C’est beau.

🎯 Objectifs du produit

Il existe potentiellement une infinité de produits pouvant répondre à la mission de votre entreprise. Définir une liste d’objectifs hiérarchisés sera votre boussole et un outil précieux dans vos premières décisions produits qui seront structurantes. Par exemple, si l’on reprend l’exemple de Leboncoin, cela pourrait être :

• Un lieu pour faire des économies en achetant d’occasion
• Permettre de revendre ses objets plutôt que les donner ou les jeter
• Rejoindre une communauté qui agit en faveur d’un monde plus durable

L’ordre est important et vous permettra de trancher des questions difficiles comme : est-ce que les utilisateurs doivent arriver sur la recherche d’objets à acheter ou sur l’ajout d’objets à vendre ?

À son lancement, le site sera vide de toute annonce et il pourrait être judicieux de pousser les utilisateurs à vendre leurs objets en premier lieu … Et bien non, on les fera atterrir sur une recherche d’objets à acheter (c’est l’objectif n°1) et on règlera le problème du «catalogue vide» via d’autres leviers plus secondaires.

🤕 Besoins profonds des utilisateurs

Je ne vais pas vous dessiner une pyramide de Maslow mais il s’agit bien là d’identifier les besoins profonds que vous allez chercher à adresser en priorité. Faire des économies ou gagner du temps sont des classiques à ne pas négliger mais vous pouvez probablement les compléter par des besoins plus spécifiques.

Si on reprend notre exemple, je verrai bien :

Faire des économies, rapidement et en sécurité

En conséquence, on mettra très certainement en avant le prix et son évolution (c’est le moment d’acheter), la distance du vendeur (je ne vais pas traverser la Bretagne pour une table basse), ses options de livraisons (car ça ne tiendra jamais dans ma voiture) et sa vitesse de réponse moyenne (car sur Amazon ça arrive demain), et le tout dans un environnement protégé (cela va de soi, mais on en fera quand même des caisses).

🕵 Produits de référence

Je vous suggère d’identifier 2 ou 3 produits de référence à étudier en détail. Je ferais un article dédié sur «comment analyser un produit» mais d’ici là, contentez-vous d’étudier en détail :

• L’onboarding : la page d’accueil, l’inscription et les étapes qui s’ensuivent. Concentrez-vous sur le fond : qu’est-ce qu’on vous raconte ? Qu’est-ce qu’on vous incite à faire en premier ?
• L’architecture du produit : à la manière d’un bâtiment, quels sont les murs porteurs ? Astuce : l’app mobile ayant des fortes contraintes d’espace disponible, il y a plus de chance que la hiérarchie des fonctionnalités soit plus clairement exposée.

Sur toutes vos observations, demandez-vous systématiquement pourquoi ? Quels problèmes ont-ils rencontrés ? Est-ce la solution la plus simple pour y répondre ? Quelles étaient les alternatives ? Est-ce un standard ?

Dans notre exemple, si on revient en 2006, date de création du bon coin, je verrai bien un benchmark des solutions suivantes :

Ebay

Craigslist

Amazon

🔠 Vocabulaire

Le terme d’onboarding est assez usuel dans la conception d’un produit, tout comme le panier dans un site e-commerce, mais vous vous rendrez vite compte qu’il vous faut nommer tous les lieus, objets et interactions sociales pour les concevoir à plusieurs.

Définissez votre vocabulaire clairement, simplement et assurez-vous qu’il soit connu de tous.

Alors, mon annonce, je la publie, je l’ajoute ou je la dépose ?

Petit avertissement sur la communication avec votre équipe technique : qui dit langage de programmation, dit vocabulaire. Votre équipe technique a ses propres contraintes de nommage et moins de flexibilité que vous pour en changer. Laissez-les diverger sur un vocabulaire propre, mais assurez-vous qu’ils restent bilingues.

🧭Approche

Récapitulons, nous avons des objectifs, une liste de besoins, des produits comparables et un vocabulaire, on pourrait ouvrir un paperboard et commencer à dessiner non ? Encore un peu de patience, je vous propose une dernière étape de cadrage.

À ce stade de la réflexion, il existe encore une infinité de produits pouvant répondre aux objectifs que nous nous sommes fixés, choisir une approche va réduire considérablement le champ des possibles.

Notre étude des produits de référence a montré qu’il existait plusieurs approches pour réaliser un site de vente d’objets d’occasion. Pour Leboncoin, je la décrirai de la manière suivante :

Comprendre immédiatement qu’il s’agit d’un coin, une sorte de brocante en plein air, pas spécialement raffiné ni chaleureux, où je vais faire rapidement des bonnes affaires.

L’approche va avoir des conséquences fortes sur le produit et le design. Elle va vous permettre de poser l’architecture et les murs porteurs dont je parlais précédemment et de donner une direction pour définir votre identité visuelle.

Petite parenthèse sur le design car on n’en a pas trop parlé pour le moment. Vous trouviez le Leboncoin moche ? Son design est pour moi une conséquence directe de l’approche qui a été choisie.

✍️ Maquette du cas d’usage principal

Il s’agit ici de définir un et un seul cas d’usage à décrire de bout en bout. Il faut choisir le cycle utilisateur qui sera le plus critique pour le succès de votre produit. Je ne vais pas décrire maintenant ce qu’est un bon produit, mais vos efforts maintenant et dans le futur devront se porter en priorité sur ce cycle utilisateur.

Le cycle doit commencer le plus en amont possible et être le plus réaliste possible :

• L’exhaustivité du cycle vous permettra de ne rien oublier et de vous conditionner comme un vrai utilisateur qui découvre votre produit.
• Le réalisme vous permettra de réduire les biais de présentation à des personnes extérieures à votre projet.

Par exemple, si je me mets dans la peau d’une personne qui ne connait pas Leboncoin et qui cherche dans Google «Appareil à raclette d’occasion».

(Les captures d’écran originales de cette maquette n’ont malheureusement pas été archivées par Wayback Machine et n’ont donc pas pu être restaurées.)

Je m’arrête sur la demande de connexion car vous avez compris le principe mais il faudrait pousser jusqu’au message au vendeur.

📋 Identification des cas d’usage secondaires

À ce stade, il n’est pas nécessaire de réaliser des maquettes des autres cycles, mais il vous faudra les énumérer afin d’avoir une idée du chantier qui se présente devant vous.

Je vous recommande une approche pyramidale pour ne rien oublier. Décomposez votre produit en quelques sous-ensembles et itérez. Cela peut être des listes à puces, un mindmap, des boites dans des boites… Vous obtiendrez ainsi une cartographie complète de votre produit qui vous sera très utile sur le long terme.

Dans notre exemple cela pourrait être :

• Présentation des produits
  • Détail d’un produit
    • Photos
      • Carroussel
      • Zoom
      • Etc.
    • Description
    • Livraison
    • Etc.
  • Liste des produits
  • Recherche
  • Recommandations
  • Etc.
• Système social
  • Profil utilisateur
  • Messagerie
  • Notifications
  • Etc.
• Onboarding
  • Page d’accueil
  • Tunnel d’inscription
  • Etc.
• Support utilisateur
  • Changer de mot de passe
  • Préférences
  • Etc.

Pas besoin d’être exhaustif, 3-4 niveaux de profondeurs doivent suffir.

⏱️ Estimation du temps de développement

Nous avons coutume de dire à Pearltrees qu’on peut tout estimer en 5 minutes, même envoyer une fusée sur la lune. L’astuce, c’est qu’il y a deux chiffres qui vont sortir de cet exercice, le temps et la marge d’erreur.

La marge d’erreur est principalement impactée par :

• L’expérience de la personne qui estime
• Le temps passé à estimer
• La quantité d’information à sa disposition

Le troisième point est piègeur car toute l’information n’est jamais disponible. La marge d’erreur n’est donc jamais à 0%, même 24h avant la date de sortie du produit. Le jeu consiste donc à itérer et réestimer régulièrement quand vous aurez plus d’expérience et d’information disponible.

Qui peut estimer ? N’importe qui. Si vous voulez faire repeindre votre salon, vous vous doutez bien que cela prendra plus d’une heure et moins de deux semaines, soit 7 jours en coupant la poire en deux. Je ne suis pas peintre et j’estime ma marge d’erreur à 50%. Le projet prendra donc entre 3 jours et 10 jours.

Faites le même exercice sur votre produit en vous appuyant sur votre cas principal et la liste des cas secondaires, vous obtiendrez le nombre de journées homme de développement nécessaire avec une première marge d’erreur.

Si vous comptiez sortir une première version de votre produit dans 1 an, vous serrez en mesure d’estimer si un associé CTO suffit ou s’il faut lever des fonds pour recruter une armée de développeurs.

Pour un site comme Leboncoin en version beta, j’arrive à :

3 125 jours de développement avec une marge d’erreur de 50%, soit 8 ETP pendant une année (entre 4 et 13).

J’ai calculé ça en 5 minutes sans lister les fonctionnalités de manière exhaustive mais si l’objectif était de sortir une beta dans un an et que vous êtes actuellement tout seul il vous faudra soit :

• Augmenter les ressources. Par exemple, embaucher une équipe technique de 8 personnes.
• Allonger le délai de sortie. Par exemple, sortir une beta dans 2-3 ans qui sera développée par 2 cofondateurs.
• Réduire le périmètre. Par exemple, se limiter aux fonctionnalités critiques dans un premier temps et itérer.

🙏 En conclusion

J’espère que vous avez trouvé cette méthode intéressante, voir utile ? Si vous voyez des étapes manquantes ou superflux, vos commentaires sont les bienvenues !

Si vous êtes arrivé jusqu’ici, vous êtes courageux car j’anticipais pas un article aussi long 🤣 N’hésitez pas à me suivre sur LinkedIn pour être notifié du prochain article 🔔

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 comme ç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 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.

Je suis un peu un dingue et j’ai décidé de m’y remettre. Suite à cette annonce j’ai reçu plusieurs centaines de questions d’anciens lecteurs🔥. J’ai décidé de vous répondre dans ce premier article, sans tabou.

Pourquoi repartir de zéro ?

“Bah oui, il était bien le vieux !”

Je sais, je l’aurai bien gardé mais il méritait un petit coup de polish. Pour cela, j’ai entrepris la mise à jour d’une machine qui n’avait pas redémarré depuis 7 ans et elle ne redémarrera plus jamais la pauvre. Le monsieur de Scaleway m’a dit gentiment que tout avait grillé et que je pouvais aller me faire cuire le cul pour récupérer mes données, je suis donc reparti de zéro.

Quelle ligne éditoriale ?

“Si c’est pour parler de web sémantique, je m’en vais”

L’idée m’a titillée mais en 16 ans je suis passé à autre chose. Je me suis dit que ça serait cool de parler de produit, d’innovation et d’entrepreneuriat. Bref, ce que j’ai fait et ce que j’aime faire. Le ton sera le même, des émojis en plus 😎.

Toujours autant de fautes d’orthographe ?

“Car ça piquait fort un article sur deux”

A priori ça a pas trop bougé mais je compte sur l’IA pour m’aider. J’ai bien entendu laissé les commentaires ouverts pour vous plaindre.