Se lancer en Research en tant que Product Manager

Comment as-tu pris conscience de l’importance de la Research dans le cadre du Product Management ?

Victor : Pour moi le déclic s’est opéré quand j’ai commencé à bosser sur des trucs qui me plaisaient vraiment. Quand ton produit te plait, que tu as vraiment envie que ça marche, tu sais qu’il faut que tu ailles voir tes utilisateurs. Donc tu te forces à le faire, même si ça induit le fait de sortir de sa zone de confort. C’est vraiment quelque chose que j’ai appris sur le tas : il faut accepter de se dire “je vais aller parler à quelqu’un, et cette personne va peut-être me dire des choses qui ne me plaisent pas”, mais ça vaut toujours le coup car ça sécurise une grande partie de notre job.

En parallèle, il y a une tendance de fond liée à l’évolution de nos métiers : avant on fonctionnait avec des cycles en V où tout le développement était fait d’un coup, maintenant que nous fonctionnons en agile on se rend vite compte qu’on ne peut pas se passer de Research à chaque sprint. C’est particulièrement vrai quand on travaille sur des produits digitaux, où on va avoir tendance à travailler de manière incrémentale. Chaque incrément est une occasion de faire de la Research et d’alimenter le sprint suivant !

Sortir des features sans les avoir fait valider par ses utilisateurs, c’est le meilleur moyen de se planter.

En quoi la Research est-elle importante pour le Product Management ?

La Research nous permet de sécuriser nos développements.

Je pense que c’est une évidence quand on est Designer ou que l’on travaille dans l’UX de manière plus large, mais moins quand on est PM car un PM est par définition très impliqué dans la conception du produit. Nous travaillons beaucoup avec les équipes de développement et cette partie technique crée un attachement émotionnel au produit : on l’aime et on on se dit naturellement que les autres vont l’aimer également.

Et c’est là qu’il faut selon moi réussir à changer d’état d’esprit et se concentrer non pas sur le produit mais sur le problème que nous résolvons. C’est de ça dont il faut tomber amoureux. Le produit n’est qu’une façon de l’adresser. C’est ce que nous apporte la Research : s’intéresser d’abord à l’utilisateur, et ensuite seulement notre produit devient important, mais ça vient dans un second temps. En étant orientés “problèmes à résoudre,” on est moins attachés au produit, qui devient juste un medium pour apporter une solution. Cela nous permet d’être meilleurs dans ce que nous proposons, d’être plus itératifs et de sécuriser la valeur que nous apportons.

Et puis cela nous permet de moins prendre à coeur les choses : quand ça ne marche pas, ce n’est pas grave, on va itérer et on va essayer de trouver de meilleures solutions !
‍

Se lancer en Research peut parfois sembler compliqué. Par où commencer ?

Je pense qu’il faut commencer “petit”, avec des projets simples, pour monter en confiance et en compétences.

Par exemple, se donner comme premier objectif d’aller voir 1 ou 2 utilisateurs par semaine, et réaliser auprès d’eux un petit entretien, que l’on n’appelle d’ailleurs même pas “entretien”. Cela permet de désacraliser le process, de se mettre moins de pression.

Bien sûr il faut quand même avoir préparé cet échange en amont. Moi ce que je fais généralement c’est que j’oriente la discussion autour de 4-5 pain points que j’ai identifiés au préalable et que je veux vérifier. L’échange me permet de comprendre ceux que l’utilisateur souhaite résoudre, mais aussi plus largement ce qui fait qu’il dort mal la nuit, ce qui l’embête, ce qui n’est pas pratique dans son quotidien…

Ensuite, une fois l’entretien réalisé, j’essaye de formaliser mes notes sous la forme de “user stories” : it’s hard for me to [insérer le job que l’utilisateur souhaite réaliser] because [insérer le pain point]. Et ensuite j’essaye de formuler l’hypothèse sous-jacente ainsi que les implications pour le produit.

Pour résumer, je pense que pour commencer il n’y a pas besoin de faire un énorme protocole de Recherche très compliqué. Réfléchir à quelques hypothèses à tester, aux formulations que l’on va employer pour ne pas biaiser les réponses (voir notre article sur le sujet) suffit pour se lancer.
‍

Comment structures-tu tes entretiens ?

J’architecture l’échange en deux temps : problèmes puis solutions. Tout d’abord le fonctionnement actuel et ses problèmes, et ensuite la partie solution. C’est très important de ne pas se cantonner aux problèmes liés à l’existant, mais également de faire de la prospective sur des pistes de solution. C’est d’ailleurs assez valorisant pour le participant d’être associé à la réflexion autour des solutions au passage.

En introduction, c’est important de rappeler le contexte et d’adopter une posture de Researcher : l’objectif n’est pas de vendre mais de comprendre. Il faut également mettre les participants dans de bonnes prédispositions : souvent, c’est une interaction sociale qui n’est pas habituelle pour eux.
‍

Que dois faire un PM qui souhaite monter en compétences sur la Research ?

Se préparer psychologiquement à se prendre un bash [rires] !

Plus sérieusement ça arrive parfois au début, mais ce n’est vraiment pas très grave. Le mieux c’est de se lancer rapidement, et d’apprendre sur le terrain. On se rend vite compte que les une ou deux mauvaises expériences sont négligeables au regard de ce que nous apporte la Research.

Un moyen de rapidement apprendre peut être d’observer des Researchers. J’ai fait pas mal de Research en solo, mais j’ai également eu l’occasion de suivre des Designers et de faire du “shadow” : participer à leurs projets m’a permis de mieux comprendre leur méthodologie et j’ai trouvé cela c’est très instructif.

Enfin, les réseaux sociaux sont une super source de contenu pédagogique gratuit : notamment LinkedIn, Twitter et Reddit. À titre personnel, je suis notamment Teresa Torres qui est une référence sur le sujet… et qui est en plus une PM de formation !