#2 – 🕵🏻‍♂️ Définir et tester le parcours clé de Festview

[Ce billet est le 2ème volet de la Saga Festview – Mettre en ligne un Wikipédia de la musique]

Dans l’épisode précédent, 1. Consolider la vision de Festview , on a vu que :

  1. Lors d’une session exploratoire de navigation, je n’avais pas réussi à comprendre le projet global de Festview car jusqu’à ce jour, il n’avait été présent que dans l’esprit du fondateur
  2. Que les business qui écrivent et diffusent leur vision ont de meilleures chances de réussite ; d’autant plus lorsqu’ils portent attention aux 6 paramètres majeurs d’une vision efficace
  3. Un atelier de 2h nous a permis de rédiger une plateforme de marque, contenant la vision, et de la publier sur le site
  4. Cette démarche avait créé un gain de confiance, de motivation, d’alignement ; ainsi que de nouvelles idées fortes pour Festview

Dans cet opus, je vais parler de l’urgence numéro 1 qui, à mon sens, doit préoccuper un Product Manager lorsqu’il prend un nouveau produit en main : identifier son parcours clé. C’est-à-dire l’expérience utilisateur qui porte la promesse du projet avec le plus de puissance. Je vais raconter comment, pour Festview, nous avons imaginé ce parcours clé, puis comment nous avons mené une grande phase de tests d’utilisateurs pour mesurer l’efficacité de ce parcours.

Le parcours clé 🎵

Après avoir clarifié le positionnement de Festview avec une vision bien rédigée et publiée, il fallait désormais proposer l’expérience adéquate aux utilisateurs.

Nous rêvions notamment de compléter le parcours de l’époque avec une brique supplémentaires : donner des récompenses aux utilisateurs qui gagnent des points grâce à leurs contributions.

Cette fonctionnalité n’était pas encore présente sur le site ; il fallait l’implémenter. Et cela allait prendre du temps à construire…

  • Permettre aux administrateurs de créer des récompenses – 1 semaine
  • Permettre aux utilisateurs de consulter, trier et filtrer des récompenses – 2 semaines
  • Permettre aux utilisateurs de consulter, liker et partager le détail d’une récompense – 2 semaines
  • Permettre aux utilisateurs d’obtenir leur récompense contre leurs points – 1 semaine
  • Livrer la récompense aux utilisateurs – 1 semaine
  • Trouver des partenaires business intéressés pour faire leur promotion à travers des récompenses – 3 semaines

Pour une expérience utilisateur complète et bien faite, ce chantier représente à lui seul une charge de travail de plusieurs mois. Or nous n’avions pas ce temps là.

Story mapping : se concentrer sur l’essentiel 🎵

Nous avons donc retravaillé ensemble la feature de « Récompenses » à l’aide d’un Story Mapping. A mon sens, c’est le meilleur outil dans ces cas là : il permet d’identifier ce qui est vraiment nécessaire pour que la feature fonctionne, versus tout ce qui est superflu. Le but est de garder l’essentiel, et de remettre à plus tard tout le reste.

L’exécution s’est traduite par un atelier de 2 heures :

  1. Introduction au Story Mapping, avec l’exemple de la routine matinale*. Super simple et efficace : en 20min nous étions parfaitement alignés sur la méthodologie
  2. Listing des grandes fonctionnalité et des sous-fonctionnalités du parcours
  3. Réduction du parcours aux fonctionnalités et sous-fonctionnalités indispensables

*Je publierai prochainement un contenu à propos de cet atelier « Routine Matinale », car je n’ai pas trouvé de ressources solides dessus. C’est un atelier bien connu qui consiste (1) à imaginer collectivement une routine matinale parfaite. Câlin dans le lit, café, tartines, journal, salle de bain, choix des vêtements,… (2) puis à la dégrader sous la pression d’une panne de réveil. Il en ressort « un parcours minimal » qui ressemble souvent à « je m’habille, je brosse mes dents et je file ».

Voilà le résultat de notre travail ce jour là :

Impliquez l’équipe 🎵

Construisez-vous les story maps de vos projets de fonctionnalités directement avec votre équipe de développement ?

Je pense qu’il le faut. Peut-être pas pour faire la décomposition de Tous les projets de features qui entrent dans le backlog. Mais au moins pour les features majeures ; celles qui mélangent du back-end, du front-end, du design,… Grâce à cet exercice, les priorités sont bien comprises par tout le monde. L’équipe – ici, l’unique développeur de la boite – peut se mettre au travail immédiatement en sachant exactement pourquoi elle développe chacune des briques de la fonctionnalité. En un mot :

Construire la story map d’une feature avec son équipe, c’est la promesse d’un passage fluide des idées au développement.

Ainsi, mon ami a entamé aussitôt la construction de la feature minimale que nous avions définis ensemble. La semaine suivante, cette dernière était livrée :

Tests utilisateur 🎵

Reprenons. Vision ⇒ Positionnement ⇒ Idées de parcours ⇒ Fonctionnalité ⇒ Dev ⇒ …. il restait plus qu’à savoir ce que les utilisateurs en pensaient.

Grâce aux outils adaptés (voir partie outils plus bas), en un jour nous avons booké 20 rendez-vous avec des proches susceptibles d’être intéressées par Festview. Pourquoi 20 ? La théorie dit qu' »entre 20 et 30 entretiens sont nécessaires avant d’être capable de savoir à l’avance ce que vont dire les utilisateurs à propos du produit. Une fois que c’est le cas, c’est qu’il n’y a plus rien à apprendre, et qu’on peut se mettre au travail.« (Ash Maurya – Running Lean)

J’ai préparé un script d’entretien, comme le suggère la méthode. Avec une intro, des questions et une conclusion. La répétition schématique du même script à chaque interview favorise la détection des propos intéressants des utilisateurs. J’ai également préparé des outils permettant de réceptionner correctement toute la masse d’informations que nous allions recevoir.

Le contenu du test utilisateur était relativement libre. Voici ce que nous souhaitions obtenir :

  • un ressenti général de l’utilisateur sur le concept. Que pensait-il de l’articulation entre encyclopédie, recherche de contenu, contribution, points, récompenses,…)
  • un ressenti sur la fluidité de la navigation
  • une détection des bugs les plus récurrents et les plus embêtants

Pour obtenir ces informations, nous avons opté pour une navigation semi-guidée. L’utilisateur était libre de ses mouvements sur l’app, et racontait à voix-haute ce qui lui passait par la tête, et de temps en temps, nous demandions d’aller spécifiquement sur une fonctionnalité pour compléter l’expérience.

Nous lançâmes, donc, cette série d’entretiens.

A la fin de chacun des 5 premiers entretiens, nous prenions toujours un court moment avec le fondateur sur notre méthodologie, afin d’affiner le script. Et au terme de chaque jour de travail nous débriefions des apprentissages majeurs de la journée.

Au bout de 5 à 8 entretiens, nous avions déjà détecté le plus gros problème à corriger.

Au bout de 15, ce problème devenait aussi visible que le nez au milieu de la figure.

Au bout de 21 (oui nous en avions fait un p’tit dernier pour la route), nous mourrions d’envie de passer à l’étape d’après pour régler ce soucis qui avait concerné 100% des utilisateurs.

Débrief des interviews 🎵

« Je ne comprends pas trop comment ça fonctionne »

Voilà, le problème c’est que les utilisateurs, ne comprennent pas immédiatement le fonctionnement général de l’application. [je reprends la narration au présent, car c’est là où nous en sommes !] Les différents verbatims que nous avons récoltés à ce sujet ressemblent à cela :

  • [depuis la page d’accueil, dès les premières secondes] « Okaaay, donc là je vais lancer une recherche, mais je ne sais pas tellement ce que ça va donner. Mais c’est beau en tout cas ! »
  • [depuis la page d’un artiste, après quelques secondes de navigation] « Hmm… en fait je crois que j’ai pas trop compris le système de points. Je suis content de voir qu’il y a des contributeurs et que c’est participatif, mais je ne sais pas comment faire pour en gagner moi aussi« 
  • [depuis la page des récompenses, après plusieurs minutes de navigation] « Aaaaah d’accoord, donc en fait on créé des pages, on gagne des points et ensuite on peut échanger contre des récompenses… ça marche ! Mais c’est trop bien ! Pourquoi vous ne le dites pas dès le début ?« 

Ce sont des retours très encourageants : les utilisateurs ont systématiquement approuvé le concept et donné des feedbacks spontanés très riches sur ce qu’ils trouvaient de positif dans l’application. Il faut simplement mieux mettre en avant notre parcours clé. Il faut plonger l’utilisateur dans ce parcours clé dès sa première visite, dès ses premières secondes de navigation, pour lui faire comprendre et apprécier tout le projet de Festview en quelques manipulations.

Je décrirai précisément le projet de feature que nous avons élaboré grâce à ces retours dans les épisodes à venir. Pour la fin de cet opus je préfère terminer de détailler la fin de la méthode de récolte de feedbacks, très importante pour la suite.

En tout et pour tout, nous avons récolté 104 insights différents avec ces tests. Par 104 insights, il faut comprendre 104 remarques différentes qui ont été formulées sur Festview. Par exemple, les 21 utilisateurs qui ont chacun dit « le positionnement de l’app n’est pas clair pour moi dès la page d’accueil« , cela ne compte que pour 1 insight.

Naturellement, un insight qui a été formulé par plusieurs utilisateurs paraît plus important qu’un insight qui n’a été mentionné qu’une seule fois.

Grille de User Impact Score 🎵

Mais, pour être précis dans la priorisation, chaque insight doit être pondéré avec un User Impact Score. C’est-à-dire qu’il faut prendre en compte l’importance qu’avait cet insight pour l’utilisateur qui l’a formulé. C’est nécessaire car si tous les insights avaient le même poids, on pourrait se retrouver avec des incohérences comme :

"Je trouve que la couleur du bouton ne va pas avec le reste" x 21 utilisateurs

↓ a le même poids que ↑

"Je ne peux pas créer la page d'un artiste car le formulaire ne fonctionne pas" x 21 utilisateurs

Dans la majorité des cas on souhaitera donner un poids total plus important au second insight de cet exemple. L’utilisateur semble bloqué dans sa tâche, contrairement au premier insight, où il semblerait qu’il ne s’agisse que d’une préoccupation esthétique.

Pour arranger cela, on va donc multiplier par un score allant de 0 à 3 à chaque fois que l’utilisateur mentionne un bug ou une suggestion d’amélioration, en suivant cette grille :

En appliquant cette grille à l’exemple utilisé plus haut on obtiendrait :

« Je trouve que la couleur du bouton ne va pas avec le reste » x 21 x 1 = 21 points

« Je ne peux pas créer la page d’un artiste car le formulaire ne fonctionne pas » x 21 x 3 = 63 points

Il faut noter que tous les utilisateurs n’ont pas le même regard sur les problèmes qu’ils rencontrent. Certains ont par exemple des exigences particulières en termes de graphisme, tandis que d’autres seront davantage dérangés par la syntaxe ou la fluidité de la navigation. Il faudra donc être capable de mettre en avant ces différences de perception, comme dans ce nouvel exemple :

« Les artistes ne sont pas triés par ordre alphabétique » a été dit par 14 utilisateurs au total.

Pour 7 d’entre eux, c’était très dérangeant. Pour 5 autres, ce n’était pas grave. Enfin, les 2 derniers ont dit que ça pourrait aller, si seulement le tri était aléatoire, sans être surs que ça leur plairait.

Poids total de l’insight = (7 x 2) + (5 x 1) + (2 x 0) = 19 points

Pour Festview, nous avons terminé la phase de tri et de priorisation avec un user impact score total de 620 points pour l’ensemble des 104 insights relevés.

Tri des insights 🎵

Dans ProductBoard, nous avons ensuite rattaché chaque insight à des projets d’amélioration. Ces projets sont découpés :

  • …en plusieurs composants (components)
  • …chaque composants est découpé en fonctionnalités (features)
  • …chaque fonctionnalité est éventuellement découpée en sous-fonctionnalités (sub-features)

🟥Components : 11

🔴Features : 104

🔺Sub-features : 17

Les components sont triés de bas en haut selon leur poids. C’est grâce à ce tri qu’on identifie les projets de développement prioritaires.

Mais quels sont ceux qu’il faut commencer à traiter dès aujourd’hui ? Quels sont ceux qu’il faut remettre à plus tard ?

Combien peut-on en traiter simultanément ? Et pendant combien de temps ?

Prendre trop d’items simultanément pourrait s’avérer contre-productif. Et en prendre trop peu pourrait retarder la date de la prochaine version du produit…

Conclusion 🎵

Vision ⇒ Positionnement ⇒ Idées de parcours ⇒ Fonctionnalité minimale ⇒ Développement ⇒ Test ⇒ Pondération et tri des insights ⇒ [priorisation]

Ce parcours de product management quasi-scolaire établit un cadre méthodologique très saint : grâce à cette méthode, on acquiert chaque jour un peu plus de certitudes quant aux choix que nous faisons et pourquoi nous les faisons.
Dans cette partie, nous avons vu comment faire ressortir des idées d’améliorations sur le parcours clé, suite aux retours des utilisateurs. 104 idées qu’il est impossible de traiter simultanément. Il faut donc désormais prioriser.

Dans le prochain opus, 3 – Définir les objectifs stratégiques de Festview, nous verrons comment ce travail de recherche auprès des utilisateurs vient s’articuler avec l’avancement général du projet. Comment l’équipe définit un panels d’objectifs à atteindre pour un temps donné. Car c’est grâce à ces objectifs qu’elle pourra sélectionner un nombre correct d’items à délivrer pour l’application de manière à servir ces objectifs. On passera notamment par la méthodes des Objectives and Key Results – OKRs.

Outils

Comme promis, voici les outils utilisés dans cette phase de définition du parcours clé puis de recherche utilisateur.

  • Atelier story mapping : Miro, permet manipuler des post-its, à distance s’il le faut. L’outil dispose même de templates pour ce type de travaux
  • Booking des interviews : Calendly, permet de déclarer des disponibilités dans un calendrier et de laisser son contact choisir le moment qu’il préfère parmi ces disponibilités
  • Trame des interviews : Google Form. On ne le présente plus. Pour les questionnaires quanti directement remplis par les utilisateurs, j’aurais utilisé Typeform, bien plus classe
  • Visio avec les ßeta-testeurs : Whereby. Ancien appear.in, on ne peut pas faire plus simple : le site génère un lien, les utilisateurs qui cliquent sur ce lien se retrouvent dans la même pièce virtuelle en visio.
  • Report, pondération et tri des insights : ProductBoard. C’est le seul outil de gestion des insights que j’ai utilisé jusqu’à présent, je le trouve parfait. A l’exception de son prix, trop élevé après l’expiration du mois gratuit : 49$/mois/user. Sachant que pour un projet qui démarre, on n’utilise pas ce genre d’outils tous les jours après une phase de recherche. On peut cependant utiliser la version gratuite et exporter tout le contenu avant qu’elle n’expire.

#1 – 🔭 Consolider la vision de Festview

[Ce billet est le 1er volet de la Saga Festview – Mettre en ligne un Wikipédia de la musique]

Dans l’épisode introductif précédent, on a vu que :

  • Festview est un produit très ambitieux porté par un entrepreneur passionné de musique, un de mes meilleurs copains
  • La version ßeta qu’il a développée lui-même est élaborée, belle et fonctionnelle
  • Des zones d’ombres demeurent quant à son positionnement, ses fonctionnalités clés, ou ses différents types d’utilisateurs
  • Ces zones d’ombre bloquent le lancement de la v1 de l’application

Dans ce contexte, l’objectif est de déterminer quand et comment lancer la première version de Festview au grand public, en confiance. Et dans cet opus, je vais vous raconter pourquoi et comment nous avons commencé par consolider la vision du projet.

Don’t know why 🎵

Une conversation avec le CEO m’avait fait comprendre qu’il voulait procéder prochainement à son lancement. Il fallait finaliser la version ßeta en trouvant les ultimes corrections/améliorations/fonctionnalités qui allaient légitimer la fameuse v1.

A cette époque là j’avais déjà passé un peu de temps sur Festview, mais pas suffisamment pour me sentir capable d’aider. J’ai donc entamé une session détaillée de navigation sur le site pour apprendre à bien le connaitre et cibler les forces et faiblesses de l’app. A la fin je souhaitais donner une bonne poignée de suggestions d’améliorations majeures.

Mais un premier problème s’est présenté lors de cette session exploratoire : je n’ai pas compris ce qui était attendu de moi sur l’interface. Je ne savais pas ce que je faisais là. Pourtant, je voyais des boutons qui m’indiquaient des tâches à faire… Mais je ne comprenais pas le but.

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/b9355f56-3313-4e1a-963b-c15f188f387d/LandingPage_2019-11-21_at_13.51_1.png

Alors j’ai cherché à relire/re-comprendre le projet général de l’application. Je voulais me familiariser avec le but premier de Festview. Avec sa raison d’être. Je crois qu’en prenant connaissance de la vision d’un projet, on comprend mieux ce qui est attendu de l’utilisation du produit. Et donc, on repère mieux les décalages qui résident dans l’expérience utilisateur entre :

A. La vision du projet, ce que le produit devrait me faire faire

↑↓

B. Ce que le produit me fait faire en réalité

C’est donc essentiel pour prodiguer des conseils pertinents. Mais, deuxième problème : je ne trouvai rien sur le site. Je me tournai alors vers le fondateur pour obtenir des ressources, mais il n’en existait pas. Pas de vision rédigée et argumentée permettant d’expliquer la raison d’être de Festview.

Words Can’t Explain 🎵

Or c’est un sujet à prendre très au sérieux. J’étais tombé par hasard sur ce texte de Brian Tracy quelques jours avant, s’exprimant sur la Confiance en Soi à travers un parallèle corporate :

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/3b4077bf-577a-4b1f-b3ec-8689d1692cf7/Screenshot_2020-04-24_at_20.11.44.png

En synthèse : une boite a beaucoup plus de chance de réussir si elle pose noir sur blanc ses valeurs. C’est une manière d’exprimer ce que l’on a au fond de soi. Certains professionnels en ont même fait leur cheval de bataille, Simon Sinek en tête de file, urgeant les entreprises à trouver et exprimer leur « WHY ».

Et sans même besoin de mentionner trop de resources théoriques. Durant mes 3 précédentes expériences pro, j’ai senti l’impact de la présence d’une vision formulée et partagée au sein d’une équipe. D’ailleurs, de ces expériences, j’ai retenu qu’une vision revêt toujours les mêmes paramètres principaux. Et jouant sur ces paramètres, on augmente son efficacité. Voici, selon moi, les 6 paramètres majeurs d’une vision efficace qu’il faut avoir en tête lorsqu’on y travaille :

J’ai fait quelques recherches pour trouver des exemples de visions bien formulées avant d’en discuter avec le fondateur de Festview. Et j’ai adoré celles-ci, que je trouve particulièrement efficaces :

  • 🖥 Microsoft, à ses débuts : A computer on every desk and in every home.
  • 🚙 Tesla : To accelerate the world’s transition to sustainable energy.
  • 🚕 Uber : Uber is evolving the way the world moves. By seamlessly connecting riders to drivers through our apps, we make cities more accessible, opening up more possibilities for riders and more business for drivers.
  • 🌳 Greenpeace : Greenpeace is an independent campaigning organisation, which uses non-violent, creative confrontation to expose global environmental problems, and to force the solutions which are essential to a green and peaceful future. (Lol)
  • 🧳 Trip Advisor : To help people around the world plan and have the perfect trip.

Pour Festview le travail était déjà bien avancé ; le fondateur avait déjà des idées bien faites et une passion pour la musique toujours aussi dévorantes.
Le travail allait alors consister à consolider les bribes de vision qu’il m’avait transmises, en une seule vision écrite, claire et argumentée.

Pour être exact, nous avons rédigé une Plateforme de Marque. C’est un ensemble plus large qui décrit l’identité de l’entreprise. Concrètement, c’est un récapitulatif de : sa vision, sa mission, ses cibles, sa promesse, ses valeurs et sa personnalité. Oui, ça fait pas mal de termes légèrement fumeux quand on parle d’un business. Et il faut admettre que l’exercice de rédaction de tous ces éléments peut être un peu long et pénible. Nous avons donc fait du custom, pour rester légers et prendre du plaisir dans l’exercice.

Give me the night 🎵

Notre atelier a duré 2h. Une longue et passionnante conversation qui s’est conduite à l’aide d’une trame que j’avais construite et pré-remplie grâce aux inputs du fondateur, autour de ces 3 catégories :

  • Vision du projet
    • Approche historique de la musique en tant qu’art et industrie : où en est-on aujourd’hui ?
    • Quel problème de ce contexte souhaite-t-on adresser ?
  • Promesse & Produit
    • A quels publics s’adresse-t-on ?
    • Qu’est-ce que notre action leur apporte ?
  • Business model
    • Comment envisageons-nous d’être rentable ?

J’ai trouvé cet atelier GE-NIAL ! Passionné et passionnant !

Je résumerais les bénéfices de cette session de travail ainsi :

  • Un gain immédiat de confiance en Festview. Formuler la vision eut l’air aussi puissant qu’écrire une prophétie. Comme si, désormais, l’avenir ne pouvait plus être autrement. « Ça m’a fait du bien de voir que le projet avait encore du sens, avec une personne se sentant aussi impliquée tant sur le plan de la musique que sur le plan professionnel. Ça soulage énormément et ça te remotive à bloque » raconte mon ami.
  • Une cohésion de groupe très solide. Bon okay, quand on est 2 ce n’est pas compliqué ! Mais quand même. C’est bon de sentir que l’autre a la même façon de voir le présent et l’avenir.
  • Des idées nouvelles. Ce jour-là, nous avons notamment figé un élément clé des aspects de la relation avec nos utilisateurs. Un angle qui nous a boosté, tant on est convaincu de sa pertinence : « Donne à la musique, elle te le rendra bien. » Nous avons notamment validé à ce moment là que les contributeurs de l’encyclopédie musicale pourraient obtenir des cadeaux liés à la musique grâce aux points gagnés. Des places de concert. Des abonnements à Spotify. Des réductions sur des guitares ou des synthétiseurs… Le fondateur : « j’ai apprecié l’exercice parce qu’il m’a amené à sortir de ma bulle de réflexion et de redéfinir clairement l’objectif principal à atteindre (système de récompenses) ainsi que l’image qu’on souhaite faire ressortir« 

Pour être concret, voici en 3 images, l’output de cet atelier :

Pour les puristes, ce n’est pas une copie conforme d’une Plateforme de Marque, by-the-book. Nous avons mélangé plusieurs notions. Mais bon. Nous étions très à l’aise avec ces quelques paragraphes à la fin de la session, et selon moi c’est le principal.

Suffisamment à l’aise, en tout cas, pour que nous publions la partie Vision sur le site, dès la semaine suivante !

Reprenons les critères d’une vision efficace et voyons si nous les avons remplis. Cette vision est-elle…:

  • …sincère ? ✅ On ne peut pas faire mieux je pense. On avait des papillons dans le ventre à la fin de la matinée.
  • co-construite ? ✅ Le fondateur m’avait partagé ses idées, j’étais revenu avec une proposition, nous avons tout synthétisé en un atelier.
  • argumentée ? ✅ L’essentiel est argumenté. Certaines choses méritent d’être vérifiées et sourcées pour gagner en puissance.
  • claire et concise ? 🟠 Claire oui, concise, bof. Quand on en sentira le besoin, on se reposera pour essayer de synthétiser tout ça encore mieux. Idéalement, en deux ou trois phrases maximum.
  • partagée en interne ? ✅ Le seul salarié est au courant 😉
  • partagée à l’externe ? ✅ C’est publié et bien visible depuis la page d’accueil du site.

Pour la suite, nous comptons reprendre ce texte de temps à autre pour mettre à jour les données. Pour que les mots sonnent toujours justes et alignés avec notre positionnement. Il faut retenir que c’est un outil vivant qui suit le parcours de l’entreprise.

Je recommande vivement cet atelier sur la Plateforme de marque / vision. Ce sont 2h bien investies qui devraient améliorer l’alignement et l’engagement de ceux qui y participent.

Un petit conseil : ne pas s’imposer trop de rigueur sur la méthodologie ou l’output. Laisser son équipe prendre du plaisir dans la création d’un tel livrable est essentiel.

Et pour les outils, je recommande :

  • Miro, pour préparer un terrain de jeu visuel facile à manipuler le jour de l’atelier
  • Notion, pour une rédaction finale épurée

[le prochain opus 2. Définir et tester le parcours clé de Festview, porte sur la question fondamentale que doit se poser un product manager : Quel est le parcours clé de mon produit ? ]

Ressources :