Et voilà le premier podcast de ProductFrogs ! J’ai le plaisir d’interviewer Christophe Frenet, CPO de Botify.

Christophe est arrivé chez Botify en 2019 pour les aider a passer d’une organisation produit top down à des équipes produit autonomes. Découvrez les coulisses de cette transformation :

• Un changement qui s’appuie sur 4 piliers fondamentaux
• Les principaux challenges rencontrés
• La place réservée à la Product Discovery
• Les impacts positifs sur le business et la croissance
• L’évolution du rôle des fondateurs dans l’organisation
• La transformation de la roadmap
• Et plein d’insights passionnants !

Si vous faites encore du Product Management en mode top down, ce n’est pas une fatalité ! ;) écoutez cette interview pour comprendre comment opérer sereinement votre transformation.

Merci beaucoup Christophe pour ton retour d’expérience !

Transcript

[Rafik pour ProductFrogs] On va commencer par parler de toi. Est-ce que tu peux nous parler de ton parcours et de comment tu en es arrivé à travailler chez Botify ?

[Christophe] Tout d'abord merci pour ton invitation et ton travail pour partager les bonnes pratiques du product management !
Tout a commencé lors de mes études d'ingénieur à l'ECE Paris au début des années 2000. Internet en était à ses débuts en France et avec 2 amis nous avons monté un site d'information sur les nouveautés techs : nous testions les nouveaux gadgets à la mode (l'iPod date de 2001 !).
Nous avons rapidement créé une seconde activité en parallèle avec la création d'une solution de forums de discussion. C'était d'abord pour gérer notre propre communauté tech grandissante mais rapidement c'est devenu une solution commerciale que nous avons licenciée aux plus gros forums français de l'époque, de France Télévisions à Hardware.fr ou Doctissimo.
Plusieurs de ces sites continuent d'ailleurs toujours d'utiliser cette techno, que nous avons revendue à Lagardère en 2007.
Quant à moi j'ai continué l'aventure dans les médias où j'ai pu accompagner l'incroyable croissance du groupe Bestofmedia, devenu ensuite Purch, qui est passé en 10 ans d'une petite startup française au leader américain de la catégorie Tech News.

[Rafik] Pour ceux qui ne connaissent pas, Purch c’est tom’s hardware, AnandTech, c’est bien ça ?

[Christophe] Tout à fait et on a ensuite évolué vers des sites plus scientifiques comme space.com.
C'est cette croissance qui m'a amené à New York en 2014 où j'habite depuis. C'est aussi durant cette aventure que j'ai pu découvrir le métier de Product Manager des deux côtés de l'Atlantique.

[Rafik] Aujourd’hui tu es le CPO de Botify, peux-tu nous expliquer ce que fait Botify ?

[Christophe] Botify est une solution SaaS B2B créée en 2012 afin d'aider les gros sites web à optimiser leur référencement naturel sur les moteurs de recherche. On appelle cela le SEO pour "Search Engine Optimization".
Pour la petite histoire, j'étais l'un des premiers clients de Botify lorsqu'ils se sont lancés, car le SEO a toujours été un pilier fondamental pour les groupes médias et nos sites avaient des millions de pages, notamment grâce à leurs forums de discussion.
Ce que l'on sait peu, c'est que les moteurs de recherche, Google ou Bing, ne peuvent en fait par crawler l'ensemble du web : c'était vrai il y a 10 ans et ça l'est encore aujourd'hui car le contenu a explosé de façon exponentielle et qu'il est plus difficile qu'avant pour les moteurs d'interpréter le contenu dynamique du web.
C'est là que Botify intervient : nous aidons les grandes entreprises à mesurer ce problème et à optimiser techniquement leurs sites de plusieurs millions, voire centaines de millions de pages.
C'était pour moi un énorme plaisir de rejoindre en 2019, cette société dont j'avais adoré en tant que client le côté visionnaire du produit, afin de pouvoir participer à la suite de son aventure !

[Rafik] Justement cette aventure a pris pas mal d’ampleur, vous êtes présents sur quels marchés aujourd’hui ?

[Christophe] Aujourd'hui Botify a des bureaux de Seattle à Singapour en passant par New-York, Londres et Paris. Nous comptons les plus grosses marques du web comme clients.

[Rafik] Tu peux nous en citer quelques-uns ?

[Christophe] En France, nous travaillons avec des groupes de eCommerce comme Fnac-Darty, et au niveau international nous travaillons avec des marques comme Expedia, Glassdoor ou Condenast.

Partie 1 : Comment c'était avant ?

[Rafik] Parlons maintenant de Product Management, quand est-ce que tu es arrivé chez Botify ? Et comment fonctionnait l’organisation produit à l’époque ?

[Christophe] J'ai rejoint Botify au moment de la Série B début 2019 où nous avions levé $20M. L'équipe produit & ingé faisait environ 20 personnes et les fondateurs étaient les product managers. La levée de fond avait pour objectif d'accélérer la croissance de Botify qui avait déjà trouvé un très bon market-fit, en France mais aussi aux États-Unis après la Série A en 2016. Ceci nous a permis de doubler la taille de l'équipe produit et de mettre en place la suite de notre stratégie.
Avec moins de 20 personnes en ingénierie, il était encore gérable pour les fondateurs de tenir la partie produit et de décider directement de toutes les évolutions. Mais ce qui fonctionne pour 20 ne marche plus lorsque l'on veut grossir à 40, 60 ou beaucoup plus. C'est pour cette raison que j'ai été recruté : mettre en place une équipe de product management moderne pouvant scaler avec les ambitions de Botify.

[Rafik] Donc avant que tu arrives, on était dans un fonctionnement top down avec des inputs qui venaient essentiellement des fondateurs, mais avec le besoin de croissance, ils ont fait appel à toi pour moderniser et scaler l’activité produit.

Partie 2 : Comment s'est passée la transformation

[Rafik] Alors justement, parlons de la transformation de cette activité, est-ce que tu peux nous expliquer comment ça s’est passé.

[Christophe] Afin d'opérer la transformation, j'ai immédiatement mis en place 4 piliers :

1. L'équipe

[Christophe] J'ai eu la chance d'arriver avec une équipe UX/UI déjà constituée avec des personnes très compétentes. Il ne manquait plus qu'à recruter les Product Managers pour les accompagner ! J'ai voulu créer des binômes UX / PM qui participent au process de discovery produit ensemble et nous avons bien clarifié les rôles et responsabilités de chacun : très important aussi quand on grandit vite !

2. La collecte du feedback client

[Christophe] A mon arrivée, la connaissance des besoins et problèmes de nos clients était uniquement dans la tête de certaines personnes.
Afin de pouvoir scaler, il était nécessaire de centraliser ce feedback mais aussi de s'assurer qu'on le collecte partout et tout le temps. D'un point de vue pratique nous avons mis en place ProductBoard comme outil de centralisation et toutes les équipes en contact avec les clients ont commencé à nous faire parvenir du feedback en continu. Je ne voulais pas d’un process rigide qui découragerait celles-ci et j'ai trouvé ProductBoard parfait pour ça : on peut y pousser des "insights" par email ou Slack très facilement et ensuite les PMs vont traiter ce feedback.
Un élément majeur est de pouvoir découper chaque retour utilisateur en différents morceaux que l'on tag sur des problèmes ou fonctionnalités particulières. Ceci permet ensuite de regrouper par thèmes plus facilement entre plein de clients différents. En parallèle, j'ai commencé à rencontrer des clients directement.
Une partie majeure permettant de comprendre les clients est aussi de regarder leur usage sur la plateforme : dans mon cas j'ai eu la vie facile car Botify a toujours été data-centric et j'ai eu accès à toute l'info nécessaire immédiatement.

3. Nos partenaires privilégiés de l'engineering

[Christophe] Là aussi, j'ai découvert une équipe super motivée et talentueuse qui a été très réceptive aux besoins de changements qu'amenait notre croissance. L'équipe de dev était historiquement découpée entre d'un côté les back-end et de l'autre les front-end. Notre plus gros changement a été la création progressive de squads autonomes full-stack.
Cette transition nous a pris environ 12 mois, le temps notamment de recruter de nouvelles personnes et de changer les habitudes de travail.

[Rafik] Au passage, comment est-ce que vous avez structuré vos squads ?

[Christophe] Plutôt que d’attribuer à chaque squad un périmètre fonctionnel, nous avons préféré leur attribuer à chacune un problème à résoudre.
Le mindset chez Botify est vraiment super et tout le monde avait très envie de tester ce nouveau mode de travail qui a amené aussi beaucoup plus de responsabilisation et d'autonomie pour les développeurs et les développeuses.

4. La stratégie produit

[Christophe] Pour scaler une équipe de PM, il faut qu'ils puissent prendre des décisions en autonomie.
Ceci ne peut arriver que s'ils ont une compréhension très claire des objectifs à long, moyen et court terme.
Dans la phase startup d'une boîte, la croissance se fait généralement tous azimuts en fonction des besoins du moment et des clients prêts à signer un deal.
Ceci amène souvent à la création d'une roadmap qui est surtout une liste de fonctionnalités plus ou moins ordonnée. Chez Botify, nous avions un beau fichier Excel de ce genre mais nous arrivions aussi à la fin d'un cycle qui avait produit la formidable suite Botify Analytics et permis la croissance jusque-là mais mon rôle était de mettre en place la stratégie produit pour les prochaines années : ce que j'ai fait dans les 6 premiers mois avec les fondateurs.
Pour comprendre comment une stratégie produit peut se définir, je recommande d'ailleurs la lecture de l'excellent livre de Melissa Perri : Escaping the Build Trap.

[Rafik] Pour ceux qui n’ont pas lu le livre, est-ce que tu peux nous dire en quelques mots de quoi ça parle ?

[Christophe] De façon macro cela revient à réfléchir à plusieurs éléments : d'abord la vision à 3-5 ans (si elle n'existe pas déjà), ensuite d'identifier les principaux freins business pour atteindre cette vision (est-ce le taux de renouvellement des clients ? l'ouverture sur de nouveaux marchés ?).
Finalement il faut transformer ces problèmes, qui ont généralement des indicateurs business associés (revenue, churn rate...), en initiatives Produit mesurables. L'objectif ici est d'identifier les problèmes du produit qui, s'ils étaient résolus, permettraient de résoudre le problème business. Ces problèmes doivent pouvoir se mesurer, avec le moins d'inertie possible, afin de permettre au PM de savoir si les solutions qu'il ou elle met en place vont dans la bonne direction.
Les freins business et les initiatives produits sont revus annuellement chez Botify et tous les trimestres nous définissons les options que nous allons vouloir mettre en œuvre pour les résoudre.

[Rafik] Donc pour résumer, les grands axes sur lesquels tu as travaillé à ton arrivée :

1. La création des binômes PM / designer
2. La mise en place d'une discovery permanente pour le feedback client
3. La réorganisation des équipes en squads autonomes
4. Et un gros travail sur la vision et la stratégie produit pour aligner tout le monde et s’assurer que les équipes travaillent sur les bons sujets.

[Rafik] Pour toi, quel a été le plus gros challenge sur ce changement d’organisation ?

[Christophe] Il faut que tout le monde ait un mindset où le changement n’est pas un problème. Chez Botify, on avait la chance d’avoir une équipe qui avait une attitude très positive sur ces sujets-là. Mais même dans ce cadre, le changement prend du temps. Ça nous a pris environ 12 mois pour mettre en place cette nouvelle organisation, pour avoir les bonnes personnes aux bons endroits et pour changer les habitudes.

[Rafik] Selon toi, quelle est la clé du succès quand on crée des équipes produit autonomes ?

[Christophe] L’élément le plus important est probablement la stratégie. Si on veut que les équipes soient autonomes il faut qu’on leur donne un cadre de travail et ce cadre doit être ni trop large ni trop petit pour permettre aux équipes d’avancer.

[Rafik] Il y a une complexité supplémentaire chez Botify, c'est que tu es à New York alors que les équipes produit et tech sont à Paris. Comment est-ce que vous vous organisez au quotidien ?

[Christophe] Ça revient à ce besoin d’autonomie : si mon travail est bien fait, les équipes n’ont pas besoin de moi au quotidien. Ça oblige à faire parfaitement ce travail d’organisation de notre stratégie et de nos process. Ça demande aussi un peu plus de rigueur dans la documentation, pour que chacun puisse retrouver l’information et travailler en asynchrone.

Partie 3 : Comment ça se passe aujourd'hui ?

[Rafik] Aujourd'hui vos équipes ont grossi, vous êtes combien maintenant sur la partie produit et tech ?

[Christophe] Aujourd'hui il y a 10 personnes dans l'équipe produit / design et 40 personnes dans la partie ingénierie et produit.

[Rafik] Et vous êtes organisés en combien de squads ?

[Christophe] Aujourd’hui nous avons 4 squads.

[Rafik] Ça serait quoi le ou les points qu’il faudrait encore améliorer ?

[Christophe] Un des éléments qu’on a découvert avec le temps, c’est que les PM et les équipes produit apprennent beaucoup de choses. Ces apprentissages vont leur permettre de prendre des décisions et de faire des choix produit. Et parfois quand on arrive avec ces choix en face des stakeholders, il peut y avoir un disconnect parce qu’on arrive avec des semaines de réflexions et d’inputs qui sont arrivés progressivement et qui nous ont amené à cette décision-là et on présente la solution finale en disant « voilà la solution » sans que tout le monde ait été accompagné et ait eu l’explication de ce qui s’est passé avant. Ce qu’on a commencé à changer, c’est d’amener nos résultats de discovery et les insights de nos clients vers l’ensemble des stakeholders en interne pour que tout le monde partage l’information. Il faut que tout le monde en interne ait cette connaissance du client acquise lors du travail de discovery.
On fait ça depuis l’année dernière et on le fait de plus en plus aujourd’hui, il faut trouver le bon mix pour donner une information utile tout en évitant que chacun ait une page d’information à lire tous les matins.

[Rafik] Justement, quel est le format ?

[Christophe] On a mis en place un format trimestriel avec les stakeholders de chaque département pour partager ces insights. Ça permet de se poser pour expliquer ce qu’on a appris, ce qu’on a fait et là où on en est, par rapport à la résolution des problèmes qu’on essaye de résoudre et aussi d’expliquer les prochaines étapes, les prochains choix qu’on veut faire et pourquoi on veut les faire.
En complément, on utilise Slack pour pousser de l’information au fil de l’eau à des groupes de travail un peu plus élargis.

[Rafik] Comment s’est passée la mise en place de la discovery ?

[Christophe] L’élément le plus difficile pour les PM c’est de gérer le temps entre discovery et delivery. L’idéal c’est d’avoir de la discovery continue qui mélange le traitement de feedbacks clients mais aussi pro activement, d’organiser des entretiens avec les clients afin de découvrir leurs problématiques. Certains PM arrivent à gérer des dizaines de feedbacks clients par mois plus des entretiens réguliers, d’autres vont être plus « start and go » en fonction de leur charge de travail en delivery.
A cette taille d’équipe, il est très important que les PM soient impliqués dans la discovery, ça leur permet de monter en compétence sur le produit et aussi sur les contraintes du métier de SEO dans notre cas. Ce travail se fait toujours en binôme avec un ou une UX designer qui sont les personnes les mieux formées pour réaliser des interviews correctes. Il y a beaucoup de pièges à éviter lorsqu’on fait un entretien client et si on en n’est pas conscient, on ne va pas obtenir une matière fiable. On perdrait alors tout l’intérêt du process de discovery, il ne faut surtout pas qu’on aille voir les clients avec des idées préconçues et qu’on leur fasse dire ce qu’on veut entendre.

[Rafik] Tes PM consacrent combien de temps à la discovery ?

[Christophe] Je dirais environ 15% mais on aimerait que ça soit beaucoup plus.

[Rafik] Idéalement ça serait combien ?

[Christophe] Je pense qu’il faudrait que ça soit plutôt 25%. Il va y avoir des périodes où ça va être plus important, comme sur des débuts de cycle ou sur de nouveaux produits, mais c’est dans tous les cas une partie qui devrait être importante pour les PM. Je sais que certains font même beaucoup plus, mais après ça va aussi dépendre de la taille de l’équipe de dev et de la charge que va avoir le PM pour la delivery.

[Rafik] Comment est-ce que la nouvelle orga impacte le business ?

[Christophe] On a déjà découvert des problèmes qui n’étaient pas forcément connus ou priorisés précédemment. L’un des sujets ça a été de découvrir des personas qui étaient moins techniques que ce qu’on avait connu auparavant. C’était peut-être dû au fait que l’on allait pas voir ces clients-là par le passé et qu’avec sa croissance Botify a eu une plus grande variété de clients et que donc de nouveaux personas sont apparus. C’est ce nouveau process de discovery qui nous a permis cela, et cela nous a permis aussi d’ajouter de nouvelles fonctionnalités sur les produits existants pour aider ces nouveaux personas.
En complément, cela a permis la croissance de l’équipe, et donc nous avons pu déployer bien sûr beaucoup de choses. Nous avons eu un nombre de lancements produit qui a été très important dans les 18 derniers mois.
On a notamment lancé en complément de notre suite historique Botify Analytics, une suite qui s’appelle Botify Intelligence, qui a pour objectif avec une équipe de data science d’identifier dans toutes les données qu’on a dans Botify Analytics, les informations clés qui vont aider nos clients à améliorer leur référencement.
Et plus récemment on a lancé Botify Activation qui va utiliser cette intelligence pour implémenter automatiquement cette correction pour nos clients. Ça n’aurait pas été possible avec une équipe plus petite.

[Rafik] Tu me disais que les fondateurs jouaient le rôle de PM avant ton arrivée, comment ça se passe aujourd’hui et comment est-ce qu’ils interagissent avec l’organisation produit ?

[Christophe] C’est un élément très important car le produit c’est le bébé des fondateurs. Donc c’est important qu’ils soient toujours impliqués. J’ai eu de la chance car les fondateurs m’ont fait confiance dès le lancement pour mettre en place cette stratégie et cette organisation, et ça a été extrêmement important pour réussir.
Au quotidien on a aussi mis en place des points de synchro pour qu’ils puissent participer : on a les workshops trimestriels dont je parlais auxquels ils participent, et de mon côté j’ai aussi des points hebdomadaires avec eux pour échanger sur les problématiques court terme, et de plus en plus moyen et long terme, parce que ce qui est important c’est de réfléchir avec eux à la stratégie d’entreprise, et aux tendances marché sur lesquels on doit être pertinent.

[Rafik] Tu m’as parlé de cette roadmap sous forme de features dans un fichier excel, ça me rappelle ce que j’ai vu dans beaucoup d’entreprises, à quoi ressemble votre roadmap aujourd’hui ?

[Christophe] L’élément important que je présente à la société c’est notre stratégie produit. Nous avons aujourd’hui trois problèmes clés que l’on veut résoudre cette année, et c’est ça que je vais tout le temps mettre en avant : « voilà les problèmes à résoudre, voilà comment on les mesure, et pour chacun de ces problèmes, voilà les deux ou trois initiatives du moment pour résoudre ce problème ». Ça rend la communication beaucoup plus simple et ça rentre sur une slide.

[Rafik] Donc plutôt des objectifs business qu’une liste de features.

[Christophe] Oui parce que je vais avoir ma liste de features au trimestre, mais je n’ai aucune idée de ce que je vais mettre en place dans neuf mois parce que beaucoup de choses peuvent se passer. A la fois parce que ce qu’on met en place aujourd’hui va avoir un impact, ou pas, et parce qu’on va découvrir de nouvelles choses en avançant. Je sais que dans neuf mois je vais avoir besoin de travailler sur tel problème mais je ne sais pas quelles sont les solutions que je mettrai en place à ce moment-là.

Partie 4 : Mot de la fin

[Rafik] On voit que les organisations top down sont encore très répandues, qu'est-ce que tu dirais aux CEOs / entreprises qui sont encore sur ce modèle ?

[Christophe] Je leur conseillerais de lire le dernier livre de Marty Cagan “Empowered” ou de regarder une vidéo d'un de ses talks sur Youtube. Il explique très bien comment les plus gros succès de ces 20 dernières années se sont basés sur un mode d'organisation différent de ce que l'on a connu par le passé, rendu possible par les nouvelles technologies, par l’accès facilité aux clients et par l’itération rapide.

[Rafik] Qu'est ce que tu dirais aux PMs qui travaillent dans des entreprises en top down ?

[Christophe] Botify recrute, contactez moi :)

[Rafik] Est-ce qu'il y a des pré-requis indispensables pour initier cette transformation ?

[Christophe] Il est primordial je pense que le CEO et/ou les fondateurs soient moteurs de cette transformation. C'est avant tout une vision d'entreprise, pas "juste" un sujet d'organisation d'équipe.

Dans notre article précédent, nous avons vu comment mesurer et optimiser son Product / Market Fit grâce à la méthode du "PMF engine" mise au point par Sean Ellis et Rahul Vohra. Je vous invite d'ailleurs à vous familiariser avec cette méthode avant de continuer pour ne pas être perdu en lisant la suite 😉.

Pour rappel, il s'agit de déterminer un "PMF score" (pour Product / Market Fit score) qui correspond au pourcentage de personnes qui se diraient très déçues si notre produit n'existait plus. D'après plusieurs expérimentations, Sean Ellis estime que le PMF est atteint lorsque cet indicateur est supérieur à 40%. Une fois ce score calculé, la méthode permet d'identifier les axes produit à travailler pour atteindre cet objectif.

Je vous propose cette fois-ci de découvrir comment Tristan Bochu, co-fondateur et CPO de l'encyclopédie musicale FestView, s'est servi de cette méthode pour le lancement de son produit.

FestView c'est quoi ?

[Rafik pour ProductFrogs] Bonjour Tristan, est-ce que tu peux te présenter et nous expliquer ce qu'est FestView en quelques mots ?

[Tristan] Hello Rafik, et bien moi c'est Tristan, j'ai 27 ans et je travaille au Product chez FestView. C'est une encyclopédie musicale collaborative où les fans de musique ajoutent tout un tas d'informations sympas sur les artistes qu'ils suivent (interviews, concerts, anecdotes, discographie...). L'objectif c'est de devenir le Wikipedia de la musique (en savoir plus sur la vision).

[Rafik] Tu peux nous en dire un peu plus sur votre modèle économique ?

[Tristan] Nous avons deux sources de revenus : un business model de media qui implique les annonceurs qui souhaitent s'adresser à un public mélomane de manière ultra-ciblée directement sur FestView. Et d'autre part, un business model de Data / Information / Answer as a Service où les acteurs industriels qui ont besoin de data brute, d'information détaillée ou de réponses directes à leurs questions piochent dans notre API.

[Rafik] Et vous avez combien d'utilisateurs aujourd'hui ?

[Tristan] On a bientôt 1500 contributeurs, qui ensemble ont créé pas loin de 75000 pages d'artistes.

Le PMF engine chez FestView

[Rafik] Rentrons dans le vif du sujet, peux-tu me dire comment tu en es venu à utiliser le framework "PMF Engine" ?

[Tristan] 1500 contributeurs ça fait beaucoup de matière à analyser. Cette matière sert à enrichir et peaufiner notre stratégie produit à long-terme et la priorisation à court-terme.

A la base, notre discovery repose sur cette rythmique hebdomadaire :

• Une poignée d'entretiens face-à-face
• Des discussions avec des users sur des channels directs (Discord, Instagram,...)
• Des sessions d'analyse de données de navigation (Google Analytics, Hotjar,...)
• Des sessions d'analyse de la base de données (Metabase)

Et le tout est synthétisé dans un Product Board bien pondéré et priorisé. Et c'est déjà très efficace.

Mais comment dire... D'une manière, ça reste des features en vrac. Elles ont beau être priorisées selon leur user impact score, ces idées de features n'ont pas un lien évident avec notre vision produit. Au moment du tri, il faut apporter beaucoup de subjectivité pour déterminer ce qui est vraiment important in fine.

C'est là qu'intervient le framework "PMF Engine" et je remercie d'ailleurs Gil Doukhan, d'Iris Capital qui nous en a parlé pour la première fois 🙏🏻. Il propose une clé de lecture supplémentaire et puissante en suggérant d'adresser uniquement les demandes de features formulées par les utilisateurs pertinents. Ceux avec qui on est le plus proche d'avoir le fameux fit.

Pour un jeune produit comme le nôtre qui a encore une très grande variété de stratégies produit envisageables, c'est un framework bien canalisateur.

[Rafik] Comment tu as utilisé la méthode ?

[Tristan] La première implémentation était très légère : on a demandé quelle était la valeur ajoutée numéro 1 perçue par l'utilisateur lors d'une vingtaine d'interviews en face-à-face.
On a essayé de recouper les données, mais il manquait notamment la première question essentielle pour bien distinguer les utilisateurs - Pas déçu vs un Peu déçu vs Très déçu.

La seconde tentative c'était un Google Form envoyé à nos 150 utilisateurs de l'époque (novembre 2020), suivant à la lettre les questions du framework "PMF engine" - on s'est inspiré directement du modèle de Sean Ellis.
Sur 150 utilisateurs, nous avons eu 25 répondants. Et là énorme surprise : 32% de product/market fit ! On pensait juste relever quelques bonnes idées d'amélioration et on a obtenu un score plutôt encourageant. C'est là qu'une vertu cachée du PMF s'est révélée : il propose un indicateur unique et simple à suivre. Une étoile de berger standard pour Product Managers. Alors que d'habitude le PM a, au mieux, une North Star Metric, sinon la plus part du temps une batterie complexe d'indicateurs très différents. Du genre Pirate Metrics - AARRR. C'était donc hautement stimulant d'avoir ce paramètre unique à suivre. Et à partir de là on avait qu'une envie : tout faire pour l'augmenter ! Et 32% on s'est dit, allez plus que 8% et on y est !! Par contre 25 réponses c'était bien trop léger comme volume pour traiter les idées d'amélioration des users à convertir. Une fois qu'on avait exclu les idées des Pas déçu celles des Un peu déçu qui ne partageaient pas la même valeur perçue que les Très déçu... Il ne restait qu'une petite dizaine d'idées d'amélioration à analyser. Et en l'occurence on en a obtenu 10 différentes. Pas très utile donc !

En troisième tentative, on a envoyé le même formulaire mais à 489 nouveaux comptes plus récents pour avoir plus de retours à analyser. Voici le résultat cumulé des deux sessions d'entretien :

Avec cette relance, nous avons obtenu 68 répondants et des choses intéressantes à analyser...

Déjà, on s'est rendu compte qu'avec les 25 premières réponses de la 2ème tentative, on surfait sur une cohorte de supporters proches du projet et qu'en élargissant l'audience, le PMF score perdait 10 points. Un score moins éloquent, mais plus réaliste.

La quantité de retours nous a permis de dresser un nuage de mots sur la valeur ajoutée perçue N°1 par les Très déçu. Le dénominateur commun : "Apprendre et partager des connaissances liées à mes artistes préférés grâce à la centralisation des informations". On a donc retenu les valeurs ajoutées "centralisation" et "communautaire" pour la suite.

Puis on a dressé un second nuage de mots pour identifier les idées d'amélioration. Il rassemble les idées des Très déçu qu'il faut garder satisfait ; et celles des Un peu déçu qu'il est possible de convertir en Très déçu car ils partagent avec eux la même vision de valeur ajoutée de FestView. NB : la méthode suggère de séparer les deux lots d'idées pour irriguer la roadmap avec 50% de l'un et 50% de l'autre. Mais dans notre cas le filtrage des 68 répondants initiaux a donné un pool de 47 réponses à prendre en compte, dont 9 étaient "Je n'ai pas d'idée ; RAS ; Rien". En définitive cela fait donc 38 idées. C'est trop peu pour appliquer une dichotomie supplémentaire en espérant faire ressortir des idées réellement plébiscitées. Pour faire cette manipulation il nous faudra minimum 100 répondants je pense.

Le résultat obtenu en nuage est assez éloquent. Il nous a servi à :

• Revoir la priorisation des idées que nous avions dans la roadmap. Là, par exemple,  l'amélioration de l'accès à l'édition de contenu, on avait identifié le point, mais ce n'était pas une urgence...
• Confirmer des intuitions de long-terme sur des grosses features comme celle du Forum qui demandent beaucoup de travail et donc beaucoup de confiance dans le besoin du user avant de lancer le chantier.

Ce qui nous amène à aujourd'hui et notre dernière version de l'implémentation de la méthode : nous développons une feature dédiée pour avoir un stream régulier de feedbacks à analyser et un PMF score bien à jour.

Nous allons proposer à tous les utilisateurs d'accéder au questionnaire depuis leur profil et d'y répondre en l'échange de 50FP (c'est la monnaie de l'encyclopédie). On espère ainsi avoir des résultats régulièrement nous permettant d'ajuster plus finement nos arbitrages de features.

[Rafik] Au final, tu dirais que tu es satisfait de la méthode ?

[Tristan] Je suis hautement satisfait de la méthode, oui. C'est d'une rationalité implacable ! La segmentation des idées par type d'utilisateur c'est très canalisant ; l'unique critère à suivre PMF Score c'est très motivant. Par contre, il faut bien employer cette méthode en addition du circuit classique de discovery-priorisation. Je ne pense pas qu'elle se suffise à elle même. Dans ce framework tout est basé sur le déclaratif des utilisateurs. Ça ne peut remplacer en aucun cas la valeur apportée par une analyse de données quanti, des entretiens en navigation semi-guidée, ou des interviews face-à-face.

[Rafik] Merci Tristan pour ton témoignage, je souhaite à toute l'équipe de FestView beaucoup de succès !

Conclusion

Cet exemple d'utilisation du framework "PMF engine" montre donc que c'est un outil puissant qui permet de bien identifier ses "core users", de savoir si l'on répond bien à leurs attentes et de déterminer les axes produit prioritaires sur lesquels travailler. Il nécessite cependant un certain volume de réponses au sondage envoyé pour en tirer des enseignements clairs et actionnables (il faut avoir au moins une centaine de réponses). A noter pour finir que ce framework ne remplace pas les techniques de Discovery classiques qu'il faut continuer à utiliser en parallèle. Ci-dessous quelques ressources pour aller plus loin :

L'article expliquant la méthode "PMF engine" sur ProductFrogs.

L'article de Rahul Vohra qui explique comment il l'a appliqué pour son client email Superhuman.

Un outil en ligne pour vous aider à appliquer la méthode.

Je suis sûr que vous connaissez déjà le concept du product / market fit (PMF)... mais quels critères utilisez-vous pour dire qu'il est atteint ? Et comment faites-vous pour le mesurer ?

Pour rappel, ce terme a été popularisé par Marc Andreessen (de Andreessen Horowitz) qui le définit comme suit :

Product/market fit means being in a good market with a product that can satisfy that market - Marc Andreessen

Traduction : Le PMF veut dire que vous êtes sur un bon marché avec un produit qui répond à [un besoin de] ce marché.

C'est la première étape clé à atteindre pour tous les entrepreneurs qui veulent lancer un nouveau produit.

Ceci étant dit, comment savoir si l'on a atteint le PMF ? C'est généralement là que ça coince, car les réponses classiques que l'on trouve dans la littérature sont d'ordre qualitatif. Exemple : "on sait qu'on a atteint le PMF quand le bouche à oreille fonctionne entre les clients, quand on reçoit des appels spontanés d'investisseurs, quand on est obligé d'embaucher rapidement, etc."

Tout cela est vrai mais ne pourrait-on pas mesurer quantitativement le PMF ? Cela permettrait de voir comment telle ou telle action l'impacte et on pourrait ainsi l'optimiser.

C'est précisément la question que s'est posée Rahul Vohra le fondateur et CEO de Superhuman. Suite à un échange avec Sean Ellis (un des gurus du Growth Hacking), il a utilisé un indicateur simple : le "PMF score".

Le PMF score est le pourcentage d'utilisateurs qui se diraient "très déçus" si le produit n'existait plus.

En s'appuyant sur plusieurs expérimentations, Sean Ellis estime que le PMF est atteint lorsque cet indicateur est supérieur à 40%.

Dans cet article, Rahul Vohra explique de façon détaillée comment il a créé sa propre méthode autour de cet indicateur pour mesurer et optimiser son PMF lors de la conception de son client email Superhuman. Il appelle cette méthode le "PMF engine".

Je vous résume ci-dessous la méthode qu'il a utilisée en s'appuyant sur les réponses à un court questionnaire envoyé aux utilisateurs.

En quelques mots, il s'agit d'identifier nos utilisateurs coeur de cible (leur proportion est le PMF score) puis de déterminer les utilisateurs restants qui s'en rapprochent le plus (même profil et même bénéfice produit perçu) mais pour qui il manque encore de la valeur dans le produit. On va ensuite travailler à convertir ces derniers vers notre groupe coeur de cible en répondant à leurs attentes afin d'améliorer le PMF score.

Et de façon plus détaillée, voici les 6 étapes de cette méthode :

1. Envoyer un court questionnaire aux utilisateurs

Tout commence avec un questionnaire envoyé aux utilisateurs qui comporte 4 questions :

Question #1 : À quel point seriez-vous déçu si le produit n'existait plus ?
       A. Très déçu (groupe A)
       B. Un peu déçu (groupe B)
       C. Pas déçu (groupe C)

Question #2 : Décrivez le profil des personnes qui peuvent être le plus intéressées par le produit.

Question #3 : Quel est selon vous le bénéfice principal du produit ?

Question #4 : Comment pouvons-nous améliorer le produit pour vous ?

2. Segmenter ses utilisateurs

Grâce aux réponses à la question #1 ("À quel point seriez-vous déçu si le produit n'existait plus ?"), on filtre les utilisateurs en éliminant ceux que l'on considère ne pas être dans la cible : on filtre les groupe B et C en gardant uniquement les mêmes profils que dans le groupe A ("Très déçu"). Par exemple si dans ce dernier groupe on avait uniquement des fondateurs, des managers et des business developers, on va uniquement garder ces profils dans les groupes B et C.

Les réponses à la question #2 ("Décrivez le profil des personnes qui peuvent être le plus intéressées par le produit") ne sont pas directement utilisées dans le "PMF engine" mais permettent de définir son persona type. Etant donné que nous avons filtré les répondants pour garder uniquement les plus intéressés, la réponse à cette question va nous donner leur profil type car ces utilisateurs vont avoir tendance à se décrire eux-mêmes dans leur réponse. Cela va nous permettre de bien cerner notre utilisateur type et de se concentrer dessus.

Rahul Vohra utilise pour cela le framework High-Expectation Customer de Julie Supan.

3. Mesurer son PMF score

Il nous reste donc le groupe A ainsi que les groupe B et C filtrés. Le PMF score est alors la proportion du groupe A ("Très déçu"). On considère que l'on a atteint le Product / Market Fit lorsque ce score est supérieur à 40%.

Une fois ce score calculé, on ne tient plus compte du groupe C ("Pas déçu"), car on considère que ces utilisateurs ne sont pas dans la cible.

4. Identifier les utilisateurs que l'on peut convertir vers le groupe des "Très déçus"

Le groupe B des "Un peu déçus" peut être divisé en deux : ceux que l'on va pouvoir convertir vers le groupe des "Très déçus" et les autres. Pour identifier ces deux groupes, on utilise la question #3 : "Quel est selon vous le bénéfice principal du produit ?".

On identifie les bénéfices principaux du groupe A et on garde les utilisateurs du groupe B qui perçoivent les mêmes bénéfices. Il nous restera les mêmes types d'utilisateurs que dans le groupe A, qui perçoivent la même valeur produit, mais pour qui il manque quelque chose pour se dire "Très déçus" (dans l'exemple de Superhuman, on voit clairement que pour les utilisateurs du groupe B, il manque une app mobile et des intégrations). La prochaine étape est donc de combler ce manque pour les convertir au groupe A et donc augmenter le PMF score.

5. Identifier les besoins clés des utilisateurs sur lesquels travailler pour améliorer le PMF score

Il nous reste donc deux groupes :

• Le groupe A des "Très déçus".
• Une partie du groupe B ("Un peu déçu") qui comprend des utilisateurs qui ont le même profil que le groupe A, qui perçoivent la même valeur produit et que l'on va pouvoir convertir pour les amener dans le groupe A.

Il est important ici de considérer les deux groupes car comme le souligne Rahul Vohra :

Si l'on s'occupe uniquement du groupe A ("Très déçus"), on ne pourra pas augmenter son PMF score et si l'on s'occupe uniquement du groupe B ("Un peu déçu"), on risque une fuite du groupe A vers la concurrence.

Il faut donc identifier les besoins des utilisateurs de ces deux groupes restants, et pour cela, nous utilisons :

• Les réponses à la question #3 ("Quel est selon vous le bénéfice principal du produit ?"), qui vont nous donner les axes qui apportent le plus de valeur au produit et qu'il est indispensable de faire parfaitement pour conserver les utilisateurs coeur de cible.
• Les réponses à la question #4 ("Comment pouvons-nous améliorer le produit pour vous ?"), qui vont nous donner les axes à travailler pour convertir les utilisateurs restants du groupe B vers le groupe A.

Nous avons maintenant identifié les principaux sujets de la roadmap.

6. Recommencer

Une fois ce processus terminé, on peut travailler aux différents sujets identifiés et ensuite relancer un sondage pour mesurer à nouveau son PMF score. Rahul Vohra recommande même d'utiliser le PMF score comme indicateur principal de l'entreprise et d'en faire un OKR dédié dans les équipes produits.

Conclusion

Cette méthode du "PMF engine" permet donc de quantifier son Product/Market Fit afin de pouvoir suivre son évolution et l'optimiser. Par la même occasion, on va également pouvoir identifier clairement les personas de notre coeur de cible ainsi que les besoins produit clé sur lesquels se concentrer.

Pour essayer cette méthode, il existe des outils en ligne pour vous aider.

Si vous avez déjà utilisé cette méthode, n'hésitez pas à me contacter pour en discuter !

Il y a quelques jours, j'ai eu une discussion au sujet de ProductFrogs avec une amie au cours de laquelle elle m'a dit : "C'est dingue, dans ma boîte on a un CPO, des Head of Product, des PM, on entend parler de Scrum et d'agilité toute la journée, mais c'est la première fois que j'entends parler de Product Discovery".

En creusant un peu, je comprends qu'ils fonctionnent avec un cycle en V classique (ou waterfall),  les fonctionnalités à développer sont dictées par le management, les PM les transforment en specs et les développeurs exécutent.

Sans dire où elle travaille, je préciserais simplement que c'est une grande entreprise française du tertiaire que tout le monde connaît et pour qui le développement logiciel est vital.

Malheureusement ce cas de figure est plus que courant, c'est même une situation que l'on retrouve dans la majorité des entreprises qui font du logiciel aujourd'hui (et que vous rencontrez peut-être vous même au quotidien ?). Alors oui, quand on regarde l'écosystème des start-ups, c'est une situation que l'on rencontre moins souvent, mais ces entreprises ne sont pas représentatives de l'industrie du soft en France.

J'écris donc cet article dans une optique d'évangélisation parce que bon... il est temps que tout ça évolue non ? 😉

Je précise également que l'objectif de ce qui suit n'est pas d'expliquer en détails comment faire la Product Discovery, je laisse cela pour un prochain article.

La Product Discovery : qu'est-ce que c'est et pourquoi c'est essentiel ?

Depuis plus d'une trentaine d'années, le focus du Product Management a été mis sur la phase de delivery (des spécifications produit jusqu'à la livraison). Les méthodes agiles se sont développées, si bien que le Scrum et le Kanban sont aujourd'hui largement démocratisés dans les équipes de développement permettant aux entreprises de "livrer du code" avec une grande efficacité.

Pendant toutes ces années, nous avons donc perfectionné le "comment faire" les choses en laissant au second plan le "quoi faire". Autrement dit : pendant longtemps on s'est concentré sur le domaine du développement de la solution, en délaissant quelque peu le domaine du problème.

La difficulté que cela pose est parfaitement résumée par Peter Drucker (consultant en management, Pionnier du Management par les Objectifs) dans la phrase suivante :

There is nothing quite so useless as doing with great efficiency something that should not be done at all - Peter Drucker

Traduction : "Il n'y a rien de plus inutile que de faire avec une grande efficacité quelque chose qui ne devrait pas être fait du tout".

L'intérêt pour les méthodes et frameworks permettant de bien cadrer le "quoi" est pourtant bien présent depuis de nombreuses années (avec par exemple David Kelley qui a popularisé au début des années 90 le Design Thinking, le prototypage, les itérations rapides...), mais comparé aux méthodes agiles de développement, il y a un net retard dans leur adoption par les entreprises.

Pourtant le "quoi" et le "comment" sont indissociables, tout aussi importants, et le bon sens nous dit que l'un devrait venir avant l'autre. Après tout, pourquoi risquer de développer le mauvais produit ou les mauvaises fonctionnalités, si l'on peut valider en amont que l'on répond à un vrai besoin utilisateur avec la bonne solution ? C'est la raison d'être de la Product Discovery : s'assurer que l'on développe les bons produits en éliminant les risques de se tromper au plus tôt et pour le moins cher possible.

Pourquoi ce n'est pas plus répandu ?

Si le bénéfice de la Product Discovery semble évident, on peut se demander pourquoi les méthodes associées ne sont pas plus répandues dans les entreprises. Les principales explications de ce retard sont selon moi les suivantes :

Une pratique encore récente

Comme évoqué plus haut, les méthodes de Product Discovery sont arrivées après les méthodes agiles de développement et sont donc mécaniquement moins connues et moins répandues en entreprise. Le temps devrait donc contribuer à changer cela.

La culture d'entreprise

C'est le plus grand frein à l'adoption de la Product Discovery (et des méthodes de Product Management modernes) car cette pratique récente bouscule les organisations en place et les périmètres de responsabilités du management. Elle nécessite en effet de donner beaucoup d'autonomie aux équipes produit et de les laisser décider des meilleures solutions à développer. Les équipes produit sont alors managées avec des objectifs business à atteindre et non avec des roadmaps de features à développer.

Or, on rencontre encore trop souvent le cas de figure décrit au début de l'article où c'est le top management qui décide des fonctionnalités à développer et les équipes produit sont simplement là pour exécuter. En plus du manque de délégation, ce type de fonctionnement vient généralement avec une hiérarchie rigide et le classique "HiPPO" (Highest Paid Person's Opinion) où l'on retient généralement l'avis du manager "le plus gradé".

Source : businessillustrator.com

Si vous voulez en savoir plus sur les équipes produit autonomes et les organisations produit modernes, je vous invite à aller lire mon résumé du livre de Marty Cagan : "Inspired: How to create tech products customers love".

Notre cerveau n'aime pas les problèmes

C'est un de nos nombreux biais cognitifs : quand nous voyons un problème, notre cerveau a tendance à vouloir le résoudre rapidement, ce qui conduit souvent à aller trop vite, à suivre ses intuitions et à faire développer une des premières solutions qui vient à l'esprit et qui semble résoudre le problème. Cette façon de faire est une des erreurs les plus répandues en product management.

Pourtant la pratique de la Product Discovery montre qu'il faut du temps pour comprendre les usages et les problèmes des utilisateurs et pour trouver les bonnes solutions. Les meilleurs produits sont faits par les équipes qui prennent le temps de parfaitement comprendre les problèmes des utilisateurs, pas par celles qui se précipitent sur les solutions.

Fall in love with the problem, not the solution - Waze cofounder Uri Levine

Traduction : "Tombez amoureux du problème, pas de la solution".

Le manque de temps

Le quotidien du Product Manager est souvent chargé de tâches aussi complexes que chronophages. Même dans les organisations produit modernes, les Product Managers ont vite fait de se laisser absorber par les réunions et les tâches quotidiennes liées au domaine du développement de la solution laissant peu de temps pour la Product Discovery.

Un savoir-faire à acquérir

Même dans les organisations produit modernes où l'on a conscience de l'importance d'une compréhension profonde des utilisateurs, la Product Discovery ne s'improvise pas. Comment mener des entretiens avec les utilisateurs ? Comment identifier les vrais problèmes à résoudre ? Comment interpréter les data d'usage ? Comment gérer les feedbacks utilisateurs et les reformuler ? Quel type de prototype choisir pour quelle situation ? Comment tester et valider une solution ?... Autant de questions qui nécessitent une formation ad hoc des Product Managers et de la pratique.

Pourquoi est-il important d'intégrer cette pratique dans son organisation produit ?

Avoir une compréhension profonde de ses utilisateurs est une nécessité, cela permet de créer des produits que les clients veulent et dont ils ont besoin. Grâce à la Product Discovery, on évite non seulement de gaspiller ses ressources sur des produits qui ne marcheront pas, mais c'est aussi ce qui va faire la différence entre des fonctionnalités "nice to have" et des produits qui vont réellement simplifier la vie des utilisateurs en résolvant leurs problèmes.

Ce processus permet également de s'assurer que les équipes produit travaillent sur les bons sujets.

Sans cette compréhension profonde des utilisateurs, on s'expose à un certain nombre de problèmes :

• On s'appuie trop souvent sur des intuitions pour identifier les problèmes utilisateurs et construire les solutions : que ça soit l'intuition du CEO ou celle du product manager, cela conduit rarement aux bons produits. La raison est simple : aucune intuition ne remplace un travail de recherche utilisateur approfondi et une confrontation des solutions potentielles auprès de ces utilisateurs. Les décisions produit doivent être prises en s'appuyant sur des preuves et non sur des intuitions.
• Même si l'on a parfaitement compris le besoin des utilisateurs, la première solution proposée est rarement la bonne, il faut plusieurs itérations pour l'améliorer et apporter la valeur attendue (par exemple, un produit peut répondre à un besoin mais avec une mauvaise ergonomie).
• Lorsque l'on travaille dans un mode très "top down", on laisse généralement peu d'autonomie aux équipes produit. La conséquence directe est un manque de motivation et d'implication ("on fait ce qu'on nous demande de faire, le succès ou non du produit n'est pas de notre ressort"), et évidemment un turn-over plus élevé, en particulier chez les bons profils.
• Enfin avec ce fonctionnement "top down", la validation de la valeur arrive bien trop tard : c'est uniquement au moment de la mise en marché que l'on saura si le produit apporte la valeur attendue par les utilisateurs.

Rich Mironov (auteur de "The Art of Product Management") décrit les conséquences de "sauter" la phase de Product Discovery :

“A lot of organizations skip user research, testing, and validation and get right into solutions and what they want to build. The result is a struggle to find a meaningful market that will use and pay for the product.” - Rich Mironov

Traduction : "Beaucoup d'organisations sautent les phases de recherche utilisateur, de tests et de validation et vont directement aux solutions qu'elles veulent construire. Le résultat est qu'elles ont du mal à trouver un marché significatif qui voudra utiliser et payer pour leur produit."

Conclusion

La capacité à faire la Product Discovery correctement est une des compétences clés des meilleures organisations produit et c'est ce qui a fait le succès des grands noms de la tech. Cette pratique demande cependant un effort de mise en place important de la part des entreprises, car elle nécessite de laisser une autonomie suffisante aux équipes produit pour chercher et décider elles-mêmes ce qu'elles vont développer. Cela requiert souvent une réorganisation et une délégation des responsabilités du management vers les équipes produit, ce qui représente un vrai changement culturel. Pourtant ce changement en vaut la peine, et il peut être fait progressivement. Par exemple, on peut commencer par constituer une équipe produit qui va travailler sur un sujet business donné avec cette méthode de travail. Une fois les effets bénéfiques de ce changement observés, on peut ensuite l'étendre au reste de l'organisation. Et comme on dit : "l'essayer, c'est l'adopter" ! 😉

Pour cette première synthèse de livre, nous vous proposons le best seller de Marty Cagan : Inspired - How to create tech products customers love. C'est un des livres de référence du product management et une lecture indispensable pour tous les product managers et toute personne souhaitant comprendre le product management moderne.

Pour télécharger la synthèse du livre en 5 points, cliquez sur le lien ci-dessous 👇👇👇:

A propos du livre

Les entreprises à succès de la tech (Google, Amazon, Facebook, Netflix, Tesla...) ont développé des produits que des milliards d'utilisateurs adorent et utilisent quotidiennement. La recette de leur succès réside dans une pratique du product management moderne que malheureusement l'immense majorité des entreprises ignore encore.

Dans son livre Inspired, Marty Cagan nous explique comment le product management moderne permet de créer des produits à succès que ce soit pour les start-up naissantes, en croissance, ou pour les grandes entreprises.

A propos de l'auteur

Marty Cagan a occupé des postes de direction chez eBay, Netscape et HP. Il a accompagné les grands noms du web sur les problématiques suivantes : stratégie business, stratégie produit, product management, design produit, expérience utilisateur et process de développement produit. Il est le fondateur du Silicon Valley Product Group et est aujourd'hui considéré comme une des références mondiales du product management.

Le product management a énormément évolué ces dernières années. Il existe aujourd'hui des méthodes et des bonnes pratiques qui ont fait leurs preuves et qui permettent de trouver des solutions efficaces aux problèmes de nos utilisateurs. Pourtant, le product management moderne est très loin d'être la norme dans les entreprises. La plupart des entreprises dites agiles le sont beaucoup moins qu'elles ne le pensent.

Notre mission

La mission de ProductFrogs est d'évangéliser sur le product management moderne et la culture produit qui ont fait le succès des grands noms de la tech. Pour cela, nous vous proposons pour commencer une newsletter et des résumés de livres indispensables pour comprendre le product management d'aujourd'hui.

La newsletter

Notre newsletter est faite pour tous ceux qui travaillent de près ou de loin sur des développements de produits innovants. Les product managers bien sûr, mais aussi les développeurs, les designers et les managers... Vous recevrez deux fois par mois:

• Les derniers articles made in ProductFrogs
• Notre sélection d'articles de veille sur la culture produit et le product management moderne
• Des résumés de livres en français
• Les actus techs à ne pas rater
• Et bien d'autres choses à venir...

Les livres

Nous allons également vous proposer au fil du temps des résumés des livres que nous pensons être des lectures indispensables pour toutes les personnes souhaitant comprendre le product management moderne.

Le premier est le livre Inspired - How to create tech products customers love écrit par Marty Cagan qui est une des références mondiales du product management.

Bonne lecture ! Et n'hésitez pas à nous contacter si vous avez des questions ou des suggestions...

A très vite !