Comment FestView mesure et optimise son Product / Market Fit grâce au framework PMF engine
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.
