Comme je l’ai écrit dans l’introduction de ma revue du livre de Marty Cagan, je suis généralement sceptique des ouvrages sur les méthodes « miracle ». Mais le livre de Teresa Torres revient souvent dans la liste des incontournables dans le domaine de la gestion de produit.

La spécialité de l’auteure est la découverte d’opportunités, i.e. la phase d’exploration et de recherches sur les besoins des clients. Elle la définit comme (ma traduction):

Un contact, au minium hebdomadaire, avec les clients:

• Par l’équipe qui construit le produit
• Pendant lequel on conduit des petites activités de recherche
• Dans le but de valider un résultat souhaité

L’équipe : on parle ici du trio gestionnaire de produit, membre de l’équipe de développement logiciel et designer de produit.

Solution versus résultat : un classique dans le monde informatique, on se focalise plus sur le comment (la solution, la fonctionnalité) et non l’objectif (le résultat attendu).

Les habitudes et états d’esprit à développer pour réussir une bonne pratique sont :

1. Être orienté résultat
2. Mettre le client au centre des pratiques
3. Collaborer entre équipes
4. Privilégier la représentation visuelle
5. Favoriser les expérimentations
6. Incorporer ces activités dans les process produit

Le support de ces pratiques que Teresa Torres mets de l’avant est l’arbre des opportunités, de leurs solutions et les tests pour les valider.

L’arbre des opportunités

En haut de celui-ci se trouve le résultat attendu. Ici l’auteure fait la distinction entre :

1. un résultat pour la compagnie qui dénote une valeur commerciale, exemple « améliorer la rétention »
2. un résultat produit qui est lié et impacte la valeur commerciale, « le chien aime la nourriture » (l’exemple est celui d’une entreprise de vente de nourriture pour chien par abonnement)
3. une métrique qui est spécifique à une fonctionnalité

On ne doit pas assigner le premier à une équipe produit car sa réussite dépend trop de l’effort d’autres équipes (marketing, support à la clientèle, etc.). On va préférer le résultat produit et réserver la métrique pour une équipe plus junior.

Construire l’arbre des opportunités

On commence par établir une carte de l’expérience client autour du problème, du résultat attendu. Chaque membre du trio va le faire individuellement puis mettre en commun le résultat sous forme visuelle avec une « carte de l’expérience ». Le formalisme est très léger ici, on parle de ronds/cercles qui représentent des moments, actions ou événements liés entre eux par des flèches. On peut construire une story map.

On peut alors conduire des interviews avec des clients. L’interview reste assez informelle pour éviter des biais. On veut que le client raconte une histoire sans qu’il ou elle essaie de nous faire plaisir.

L’auteure propose même un format de résumé de l’interview pour aider à se rappeler des points marquants.

Enfin on peut construire l’arbre qui permet de mettre en relation les opportunités produit : parent-enfant où les enfants représentent des sous-opportunités.

L’important est que cet arbre regroupe des opportunités, i.e. des problèmes pour le client et non pas des solutions, des objectifs business ou des sentiments liés au produit.

Choisir une opportunités sur laquelle travailler

Suivant l’esprit de l’agilité, on essaie de décomposer et de travailler sur le plus petit morceau qui va apporter de la valeur et ceci assez rapidement. On ne s’attaque non pas à un des noeuds dans l’arbre car on ferait l’erreur d’attaquer de front trop de choses — on descend à une feuille.

On évalue chaque opportunité sur 4 facteurs :

1. Le nombre de clients impactés et la fréquence du problème
2. L’importance pour le client
3. L’importance pour la compagnie
4. L’importance vis-à-vis du positionnement de la compagnie sur le marché

Cela reste un jugement, on ne va pas passer des mois à quantifier ces facteurs pour avoir des mesures précises. La découverte produit reste une activité qui se veut réversible rapidement (« 2-way door »).

Découverte des solutions

On peut faire des sessions de brainstormings, mais attention à l’effet de groupe qui est puissant. Il nivelle vers le bas la qualité des idées trouvées.

Là-aussi on va préférer des sessions individuelles puis regrouper les solutions. On peut itérer plusieurs fois et voter par un système de budget de points que chacun doit attribuer aux solutions.

Trouver et classer les hypothèses derrière les solutions

On ne teste pas des idées mais les hypothèses sous-jacentes aux solutions qu’on propose. Ceci afin d’éviter deux problèmes: le biais de confirmation et la surenchère dans notre attachement à une idée. Ce sont des défauts présents chez tout le monde. On sélectionne presque inconsciemment les données supportant nos préjugés sans tenir compte des résultats qui les contredisent. De plus, une fois sélectionnées, on a dû mal à revenir en arrière sur nos opinions, « on s’enfonce ».

Pour éviter le plus possible ces enjeux, au lieu de tester les idées de solutions, on teste les hypothèses sur lesquelles reposent ces idées.

Pour aider à les expliciter on peut reprendre la story map et lister pour chaque étape ce qu’il faut pour valider les hypothèses de désirabilité, viabilité, faisabilité (technique et juridique), facilité d’utilisation et d’éthique.

Exemple avec une plate-forme de vidéo en ligne qui veut proposer du sport. Une des étapes est « Notre plate-forme a des options disponibles d’événements sportif en direct pour nos abonnés ».

• désirabilité: notre plate-forme a les événements sportifs que nos abonnés veulent
• facilité d’utilisation: les abonnés savent où trouver les événements sportifs dans notre plate-forme
• faisabilité: nous savons quels événements sont disponibles à un moment donné
• faisabilité: on peut afficher seulement les événements qui sont en cours ou qui commencent bientôt

Une autre technique consiste à faire un pre-mortem où on liste ce qui peut mal se passer si on met en place une idée de solution.

On peut alors classer les hypothèses pour s’attaquer à celles pour lesquelles on a peu de données et qui sont les plus importantes.

Tester les hypothèses

On va privilégier la vitesse sur la précision. On veut pouvoir tester plus d’une dizaine d’hypothèses par semaine. Il faut bien sûr une infrastructure pour cela.

L’auteure détaille deux méthodes mais il en existe beaucoup d’autres. La première est de faire une mini-enquête avec une question, l’autre est d’exécuter des tests non supervisés où le client réalise une tâche tout en étant enregistré dans l’app.

Mesurer l’impact

Chaque hypothèse se voit attacher un critère chiffré qui indique qu’elle a été confirmée, par exemple 50 clients sur 200 font telle action (N.B. il faut choisir un chiffre qui prenne en compte que le prototype ne sera pas aussi bon que le produit final).

On doit aussi mesurer le résultat attendu final qui est désiré. L’exemple de l’ouvrage est celui d’une nouvelle fonction de recherche pour un site d’emploi d’étudiants en dernière année d’université. L’hypothèse est sur une des étapes du parcours (au lieu de demander quel type d’emploi ils souhaitent, on leur demande quels sont leurs domaines d’étude). Le résultat final est l’embauche de l’étudiant même si l’hypothèse plus immédiate est celle de l’utilisation de cette nouvelle fonction de recherche.

Bien sûr ces expérimentations se font sur de petits nombres, donc on est loin de la solidité d’une étude scientifique. Mais la gestion de produit est plus un art qu’une science. Il y a beaucoup d’intuition qu’on essaie au mieux, et dans des délais courts, de mettre à l’épreuve de la réalité.

Conclusion

J’ai beaucoup aimé ce livre. Il est assez court pour se lire en quelques jours. Il mériterait d’avoir un peu plus d’exemples mais d’autres ouvrages sur des points précis du parcours sont donnés en référence. L’auteure n’a pas peur de remettre en cause certaines pratiques courantes comme les sessions de brainstorming. Son discours est convaincant. J’ai sans doute laisser de côté beaucoup de détails et de subtilités dans ce résumé. Je vous invite à lire ce livre ou consulter le site de Teresa Torres.