• Le retour aux fondamentaux, le besoin
• Persona : identifier sa cible
• Priorisation et utilité marginale
• Conclusion : Time to market

Au cours du mois de janvier, j’ai publié une série d’articles sur les Principes d’Économie Politique de Carl Menger, et notamment sur ce que cette lecture m’a apportée en tant que Product Owner.

Pour retrouver mes notes sur Carl Menger, je vous invite à passer par ma publication de synthèse : Les Principes d’économie politique de Carl Menger : Le retour à l’individu.

§Le retour aux fondamentaux, le besoin

Plus que de réformer mes connaissances, Menger m’a surtout permis d’approfondir ma compréhension du Product Management : je peux désormais m’ancrer sur des fondements théoriques d’économie éprouvés.

Carl Menger justifie l’importance centrale de l’utilisateur et de ses besoins de part le caractère subjectif de ses préférences et de ses choix. Pour le Product Owner, cela démontre à quel point le contact direct avec les clients et utilisateurs est crucial : eux seuls peuvent nous donner les clés pour prioriser les évolutions du produit.

À plus grande échelle, cela explique l’importance de connaître son marché, pour les développements futurs du produit : le marché est au final constitué de l’ensemble des individus échangeant biens et services contre un prix représentant la valeur que ceux-ci leur apportent.

§Persona : identifier sa cible

Le Persona est le moyen à disposition du Product Owner pour se représenter les utilisateurs de son produit, basé sur des données réelles (utilisation de notre produit) et la recherche utilisateur. Sur le moyen d’identifier le profil type de notre utilisateur, je vous proposes un petit coup d’œil sur les sondages (Mener un sondage), où j’ai repris le pourquoi du comment de la segmentation de marché.

• Le persona permet de se représenter notre utilisateur type : on sait à qui on a à faire.
• Il nous permet de visualiser concrètement : pourquoi il utilise notre produit (leur objectif, ou “Job to be done”), quels sont les points de friction auquel il est confronté (“pain”) et ce qui le motive à venir et revenir sur notre produit (“gain”).
• Tout cela aide le Product Owner à identifier et prioriser les besoins sur lesquels l’équipe doit s’atteler en premier : ceux qui cause les plus grosses frictions, sur le parcours de notre utilisateur.

Au final, le Persona aide à la prise de décision, en apportant une meilleure visualisation de nos utilisateurs et une meilleure compréhension de ses besoins.

Menger aide à rationaliser l’usage du Persona : il nous rappelle que ce sont eux qui décident de leurs actions (leurs objectifs) et de leur motivation. Il nous rappelle que nous ne pouvons pas nous appuyer sur nos propres suppositions, mais sur les faits : les donnés d’utilisation et des enquêtes menées auprès des utilisateurs.

J’ai eu l’occasion d’échanger directement avec des utilisateurs trop peu souvent. Mais les rares fois où j’ai pu le faire furent les moments où j’ai vraiment pu améliorer ma compréhension de leurs usages de mon produit. J’ai pu bénéficier d’intermédiaires qui m’ont apporté une vision plus global des besoins, ce qui m’a permis d’avancer dans mon travail. Mais clairement, les échanges directs étaient d’un autre niveau, en terme de bénéfice.

De mon expérience personnel, j’ai également pu élaguer le format de base du Persona. Dans celui-ci, on cherche à l’incarner, avec une photo, et une identité complète (mais fictive). Cette démarche est censée humaniser l’utilisateur dans l’esprit des membres de l’équipe. Cependant, j’ai surtout observé que ces informations obscurcissaient plus qu’autre chose les données essentielles : les éléments clés de compréhension de l’utilisateur dans le cadre de notre produit. Par exemple, connaître l’age, le caractère ou les centres d’intérêts ne m’apportaient rien, pour une interface Cloud, mais connaître sa profession, ou son aisance avec les notions d’architecture m’ont permis de prioriser certains types de fonctionnalité plutôt que d’autres.

Finalement, le gros bénéfice, et sur lequel je compte le plus capitaliser des leçons de Menger, c’est un réel travail pour chercher des donnés fiables et exploitables sur les utilisateurs : donnés d’utilisation, formulaires de satisfaction, entretiens directement avec les utilisateurs, … Ce sont les donnés concrètes qui permettent de vraiment comprendre les objectifs, motivations, et difficultés rencontrées par les utilisateurs.

§Priorisation et utilité marginale

Dans la démarche Produit, nous sommes très attaché à des approches Agiles, comme Scrum ou Kanban, car elles favorisent les échanges fréquents avec les utilisateurs : en particulier en Scrum, nous devons livrer à chaque fin de sprint, et ainsi récolter des retours d’utilisation de notre produit (idéalement, le sprint se termine par une démo directement auprès des utilisateurs, à l’occasion de la revue de sprint).

Et toujours avec Scrum, la durée du sprint est fixée, et n’est pas censée évoluer. Dans la théorie, ce délai est relativement court : une semaine, deux semaines … maximum quatre. À chaque itération, nous avançons sur les fonctionnalités prévues pour répondre au besoin de l’utilisateur. Et à chaque sprint, l’équipe est en mesure de pivoter pour aborder un besoin différent, en fonction des retours utilisateurs.

À ce niveau, Menger nous apporte un argument de poids en faveur des sprints cours, et surtout des échanges fréquents avec les utilisateur, grâce à la théorie de l’utilité marginale : pour un besoin spécifique, plus nous apportons une solution satisfaisante, plus ce besoin se fait moins pressant … Jusqu’au moment où un autre besoin prend le pas.

Par exemple, sur une interface web, les tableaux peuvent souffrir d’importants défauts d’ergonomies qui en rendent l’utilisation quasiment impossible. Une fois ces défauts résolus, ajuster l’emplacement des actions dans ce tableau aura un impact d’autant moindre que les boutons ont déjà été rendus accessibles. À ce moment là, une autre fonctionnalité va probablement remonter, comme le support d’un autre parcours d’utilisation du produit, et qui n’est pas encore adressé.

Ainsi, L’utilité Marginale est le support théorique sur lequel repose en réalité toute la démarche de priorisation : lorsqu’un besoin atteint un niveau de satisfaction suffisant, il est beaucoup plus rentable de s’atteler à un autre besoin pour lequel notre produit peut apporter de la valeur aux utilisateurs.

§Conclusion : Time to market

Pouvoir se concentrer constamment sur les principaux besoin des utilisateurs nécessite deux choses :

• Connaître nos utilisateurs et leurs besoins, ce que permet le Persona.
• Connaître les priorités des utilisateurs à l’instant donné, ce que met en évidence l’utilité marginale.

À chaque fois que nous travaillons sur une solution, nous avons besoin de retours rapides :

• Est-ce que nous sommes partis dans la bonne direction ? Nous ne sommes pas dans la tête de l’utilisateur, et son besoin étant subjectif, lui seul pourra nous dire si notre solution est bonne. Si on attend trop pour savoir ce qui est bon, ce temps est potentiellement perdu …
• Une fois que notre solution satisfait, est-ce qu’on a besoin de la peaufiner, ou d’autres problèmes prennent le pas ? Là aussi, l’utilisateur seul sait.

C’est là qu’intervient le time-to-market : plus le délai entre l’identification du besoin et la proposition d’une solution est courte, plus vite nous validons le positionnement de notre produit, ou au contraire, plus vite pour savons où et comment pivoter.

Et chaque utilisateur étant unique, le seul moyen de comprendre ce qui fera le plus avancer le produit est de collaborer directement avec eux.

Il y aurait évidemment encore beaucoup à dire, sur la démarche produit, et notamment, sur les outils que j’affectionne en particulier, comme le Customer Journey Map ou le Story Mapping. Mais cet article est déjà assez long comme ça. J’y reviendrai donc plus tard ;-)