Personas dans le management de produit

La gestion de produit est une question de décisions. Des décisions sur les opportunités à saisir, les problèmes qui méritent d'être résolus, les fonctionnalités qui apporteront le plus de valeur, les meilleurs compromis en termes de délai de mise sur le marché et les clients les plus importants. Même si tu ne prendras jamais les bonnes décisions à 100%, tu devrais avoir raison sur la plupart d'entre elles pour que ton produit puisse devenir un succès.

Les personas (profils utilisateurs) comme outil

Un de mes outils préférés pour les décisions difficiles, ce sont les Personas (aussi appelés User Profiles). Pour tous ceux qui ne savent pas ce que sont les Personas : c'est une technique pour capturer les enseignements clés des interviews utilisateurs et clients, identifier et comprendre qui sont les différentes personnes qui utiliseront notre produit. Les Personas décrivent un utilisateur imaginaire mais extrêmement plausible et ses caractéristiques – en particulier ses comportements, ses opinions et convictions ainsi que ses objectifs.

Cet outil a été mentionné pour la première fois en 1998 dans un de mes livres préférés, The Inmates are Running the Asylum d'Alan Cooper. Si tu n'as pas encore lu ce livre, tu devrais le faire. C'est un classique pour les product managers, designers et développeurs.

Personas dans différents domaines

Il est tout à fait possible que vos designers utilisent déjà des personas dans leur processus de conception. La communauté du design semble avoir adopté cette technique, car la plupart des équipes de design que j'ai rencontrées travaillent avec cet outil. Chaque équipe a ses propres idées sur ce qui fait de bonnes personas et sur le degré de formalisme à adopter lors de leur création, mais à mon avis, c'est tout à fait normal.

Peut-être que votre service marketing travaille déjà avec des personas. L'utilisation des personas est très similaire dans les deux cas et les deux approches sont pertinentes, mais elles ne sont pas totalement identiques, car elles servent deux objectifs bien différents. L'équipe marketing cherche à déterminer comment atteindre au mieux le public cible et toucher ses émotions sous-jacentes. Les designers s'intéressent davantage aux objectifs des utilisateurs et à leur comportement en ligne.

Pour un product manager, cela devrait être particulièrement utile.

L'utilisation correcte des personas

Mais bien que ce soit un outil très puissant, les personas sont souvent utilisés beaucoup trop tard dans le processus de définition/découverte produit, car ce sont généralement les designers qui portent tout cela, mais ils sont la plupart du temps impliqués bien trop tard dans le processus.

Pour exploiter le vrai potentiel des personas, les product managers doivent être fortement impliqués dans la création et la priorisation des personas, et particulièrement dans les interviews utilisateurs et les travaux de recherche nécessaires. La création des personas devrait se faire en collaboration entre le product manager et l'interaction designer – et si tu as la chance d'en avoir une – également avec ton équipe de User Research. Mais quoi que tu fasses, ne délègue pas cette tâche. Pour la même raison que le product manager doit être présent à chaque test d'utilisabilité, il doit aussi être présent à chaque interview utilisateur. Le product manager a besoin d'une compréhension profonde de la cible, qui ne se développe qu'en parlant avec autant d'utilisateurs et de clients que possible.

C'est pourquoi j'essaie d'amener les product managers à participer activement à la création des personas et à m'assurer qu'ils terminent ce travail le plus tôt possible dans le processus.

La communauté du design a déjà tellement écrit sur les personas que je ne veux pas tout répéter ici. Cependant, je voudrais mentionner quelques points spécifiques, car ils sont particulièrement pertinents pour les product managers.

Les personas en tant qu'outil de gestion de produit présentent plusieurs avantages :

•  Les personas aident à prioriser ce qui est important. Par exemple, si vous avez décidé de cibler « Mary » pour cette release et qu'une fonctionnalité donnée est importante pour « Mary », alors vous devriez la mettre en œuvre. Mais si la fonctionnalité était destinée à « Sam », elle ne sera pas implémentée. Comme vous pouvez le voir, il est important non seulement de décider à qui cette release est destinée, mais aussi à qui elle ne l'est pas. Une erreur courante est de vouloir satisfaire tout le monde avec un produit et de finir par ne satisfaire personne. Ce processus peut aider à éviter exactement cela.

• L'une des erreurs les plus fréquentes des équipes produit est de se confondre avec les clients. J'ai déjà écrit sur ce sujet, mais ce que j'apprécie vraiment avec les personas, c'est qu'elles nous aident à aborder ce problème très répandu.

• La plupart des produits ont différents types d'utilisateurs – différents utilisateurs finaux, managers, administrateurs, etc. – et on suppose rapidement qu'il suffit d'implémenter quelques fonctionnalités pour toutes ces personnes, ce qui ne fait que créer un énorme chaos. C'est en partie un problème de design, mais les personas peuvent aussi aider à prioriser l'importance de ces différents utilisateurs et à identifier où une expérience utilisateur distincte pourrait être nécessaire.

• Les personas sont vraiment efficaces pour expliquer à toute l'équipe produit à qui le produit est destiné, comment ces utilisateurs vont l'utiliser et pourquoi c'est important pour eux.

• Fondamentalement, les personas (comme les principes du Manifeste / principes produit) ont le grand avantage de rassembler l'équipe autour d'une vision commune. Il y a littéralement des milliers de détails à clarifier avant la release d'un produit. Le product manager (ou designer) ne peut pas tous les traiter. Si tous les managers, designers, développeurs, testeurs, etc. ont vraiment intégré les principes produit et les personas, ils seront bien plus à même de prendre la bonne décision lorsqu'ils sont confrontés à une question ouverte.

Pièges liés aux personas auxquels il faut faire attention

• Certaines équipes créent des personas, mais ne franchissent pas l'étape suivante, à savoir prendre la décision difficile de déterminer quelles personas sont prioritaires. Ce n'est pas une bonne idée de dire qu'un produit est destiné à tout le monde. Vous vous mentez à vous-même. Même si c'est extrêmement difficile pour la plupart des product managers, j'essaie vraiment de les encourager à orienter chaque release vers une seule persona. Ce n'est pas que cette release ne puisse pas également bénéficier à d'autres personnes, mais votre focus devrait être de faire un excellent travail pour ce type d'utilisateur spécifique.

• Parfois, les équipes créent des personas basées sur des suppositions et des stéréotypes concernant les utilisateurs, mais ne prennent pas le temps de discuter avec de vrais utilisateurs et de vérifier si ces utilisateurs théoriques existent réellement. J'ai souvent été surpris à ce sujet. Tellement souvent que j'ai appris à considérer mes premières impressions uniquement comme des théories et à ne me forger une véritable opinion qu'après avoir effectivement parlé avec les utilisateurs.

• Une question fréquente est de savoir si vous devriez faire tester vos prototypes uniquement par les personas principales. Bien sûr, vous devez vous assurer que votre produit est excellent pour ceux à qui il est destiné. Cependant, vous devriez également faire tester par quelques personnes en dehors des personas principales, car vous n'aurez probablement pas la chance que seules ces personnes utilisent votre produit. Pour les tests de prototypes, vous devriez donc toujours avoir à disposition toute une série d'utilisateurs potentiels.

Si vous ne l'avez pas encore fait, vous devriez envisager de créer une persona décrivant un utilisateur typique de votre cible principale pour votre prochaine release, puis réfléchir si cet outil ne pourrait pas vous aider à prendre toutes ces décisions difficiles.

Ce texte provient du blog de Marty Cagan et a été traduit par nos soins en français.

Exigences non fonctionnelles

=> Comment mets-tu en œuvre les exigences non fonctionnelles sous forme de User Stories ?

Avantage concurrentiel du temps

=> Comment Scrum te procure-t-il un avantage concurrentiel ?