On le sait, un produit digital qui marche est un produit qui colle aux besoins de son utilisateur. Pour le Product Manager, s’appuyer sur des données tangibles, fiables et pertinentes est déterminant au moment de la prise de décision, et pour la tenue de son produit. C’est là que la recherche utilisateur entre en jeu. Comment faire travailler ces deux expertises complémentaires en bonne intelligence ? Martin Dujol, Product Manager chez nous, partage son point de vue aiguisé sur la question et ses retours de terrain. Presque en immersion. Vous allez voir, on s’y croirait.
Il y a près de deux ans, j’ai décidé que la recherche utilisateur serait mon sujet de mentoring. Pourquoi ? En tant que Product Manager, je me dois d’être bon en termes de Delivery, c’est le coeur de mon travail. Mais les années passant, j’ai régulièrement éprouvé un vide autour d’une question simple : pourquoi ? Cette interrogation était régulièrement mise de côté, mal abordée, la phase de Discovery était on ne peut plus réduite. J’ai vu en la recherche utilisateur une discipline raisonnée et puissante pour m’aider à répondre à cette fameuse question qu’on posait bien trop souvent étant enfant, et qu’on tend à oublier une fois adulte.
Depuis, j’ai appris quelques astuces, eu la chance d’assister à des études utilisateurs en live et d’en réaliser par moi-même (on ne s’improvise pas Researcher !). Tout cela m’a conforté dans la valeur que peut apporter la recherche utilisateur à un produit ou un projet.
Je suis convaincu qu’il faut créer un pont entre la recherche utilisateur et le Product Management. Cette conviction vient d’un constat autant sur l’organisation des équipes que sur les personnes qui les composent.
Intégrer la recherche utilisateur dans un contexte mouvant
Dans les entreprises, les projets informatiques (90’s), numériques (2000’s), digitaux (2010’s) ne sont pas figés et voient couramment leurs méthodes de travail et les rôles évoluer. Typiquement, l’arrivée de “nouvelles” expertises dans une structure orientée IT a son lot de difficultés : incompris, mal intégrés, considérés comme de simples centres de coût (l’ayant moi-même vécu en tant que testeur)… alors qu’ils sont à forte valeur ajoutée. Les Designers et les Researchers sont régulièrement confrontés à ce problème, quand bien même leurs métiers sont loin d’être nouveaux.
Changer ou ne pas changer ma manière de travailler ? Ca peut être fun, parlons-en à Bruce.
L’équipe marketing a historiquement une place dans la recherche utilisateur : elle se concentre généralement sur ce que déclare faire le consommateur (moins sur ce que fait réellement l’utilisateur), utilisant des méthodes et outils partagés avec d’autres équipes… ou restant leur exclusivité. La mise en place d’organisations centrées produit chamboule le périmètre d’action entre les équipes Produit et le Marketing, cette dernière restant régulièrement celle qui dirige le produit.
HiPPO + Quanti, un cocktail loin d’être quali
Le métier (client, sponsor) a des difficultés à cerner la valeur de la recherche utilisateur. D’autant plus quand il a l’habitude de décider en mode HiPPO (Highest Paid Person Opinion) avec des données quanti et que les approches agile et produit sont appliquées sans véritablement remplacer le mode projet fortement ancré… Le quanti (donnée chiffrée, mesurable) est important, mais insuffisant, d’autant plus que son interprétation est rapidement subjective sans une bonne prise en compte de son contexte (“Figures don’t lie, but liars do figure”, disait le statisticien américain Carroll D. Wright… que ce biais soit conscient ou non !).
Il y a un repli naturel – voire d’autodéfense – sur le Delivery, d’autant plus avéré lors d’une crise interne ou plus globale. Dans ma carrière, j’ai personnellement expérimenté la confrontation QA vs Delivery et UX vs Delivery. Les frictions Research vs Delivery sont une réalité pour les researchers. Quand bien même le métier perçoit l’intérêt de la recherche utilisateur, il craint ce spectre ou fantôme qui lui coûtera plus qu’il ne rapporte : “ça semble cool … mais pas le temps ni le budget ! #déso”. La compréhension limitée des différentes méthodes peut en être une des causes : Recherche = testU… alors que c’est bien plus que cela.
La réalité du quotidien du Researcher dans la team produit
Qu’en est-il de ceux qui travaillent au quotidien pour délivrer un produit ? J’ai pu en discuter avec nos experts du Product Management et de la Research (directeurs de pôles et directeurs conseil) comme avec mes collègues opérationnels dans le produit et la recherche utilisateur. Ces entretiens m’ont permis de remonter plusieurs insights stratégiques et terrain que je vous partage.
La connaissance du métier de l’autre et les modes de communication en équipe posent question :
- chacun connaît bien son métier, généralement son périmètre… et a déjà fort à faire. Nous sommes naturellement moins conscients de ce qui se passe “chez l’autre” : nous restons silotés dans la pratique ;
- malgré une écoute naturelle et mutuelle, le Researcher ne connaît/comprend pas forcément tous les rôles, les responsabilités, enjeux et contraintes du PM. Et vice-versa ;
- chacun communique avec son propre langage, ce qui peut amener à deux définitions différentes d’un même terme ;
- la recherche utilisateur comprend plus d’une dizaine de méthodes différentes, chacune étant plus ou moins adaptée selon le contexte d’utilisation du produit, qu’on veuille récupérer une donnée quanti ou quali, que l’utilisateur agisse ou déclare comment il agit. Comment le PM peut-il s’y retrouver quand il ne connaît pas ce domaine ?
Mais pourquoi tu n’as pas validé mes maquettes ultra-stylées ?!
Car il ne savait pas que c’était basé sur des conclusions béton venant de ma Recherche !
On observe des enjeux de collaboration spécifiques à l’expertise Research au sein d’une organisation produit :
- le Researcher court après le PM pour s’assurer que son travail soit réellement utilisé, qu’il ait un impact. Moins la recherche est utilisée dans l’immédiat, plus elle a de chances d’être oubliée ; le travail du Researcher est balayé par une décision du client prise au doigt mouillé, malgré tous ses efforts pour se baser sur des faits et les efforts du PM pour soutenir ces résultats ;
- le Researcher va travailler avec les mêmes personnes, mais pas forcément dans le même contexte organisationnel : il peut faire partie d’une équipe décentralisée et sera sollicité ponctuellement, être pleinement intégré dans une équipe produit… chaque approche a ses avantages et inconvénients, ce choix cornélien étant en bonne partie tributaire de l’historique de la société (le legacy) ;
- quand bien même la communication entre experts est fluide, les outils pour la recherche utilisateur sont souvent silotés entre les équipes UX, Research et Marketing… et sont encore moins connectés à ceux du PM.
Les livrables peuvent être difficilement actionnables, peu adaptés à l’objectif ou non compris par le PM qui en fait l’usage :
- une recherche utilisateur doit répondre à l’objectif du PM. Réaliser un test utilisateur avec les collègues du bureau d’en face, le fils du N+2 et la cousine geek serial beta-testeuse n’est pas forcément la meilleure approche. La recherche utilisateur doit aider à répondre à l’enjeu du PM (qui n’est d’ailleurs pas sa seule source) ;
- les rapports sont denses, difficilement exploitables. Exemple vécu avec un rapport d’étude d’excellente qualité, mais pas du tout actionnable : j’ai passé des heures à lire, relire, lire encore… pour tenter d’enrichir mon backlog. Une pépite d’information, complexe à transformer. Un cas de figure décourageant pour tout consommateur de recherche utilisateur ;
- le PM a connaissance du constat, mais n’a ou ne comprend pas les arguments supportant cet enseignement. Information fondamentale pour justifier sereinement les futures décisions prises à partir de ces constats… et convaincre le client.
User Research x Product Management : travailler en bonne intelligence
Un des principaux objectifs de la recherche utilisateur est « d’améliorer le produit et le design, en travaillant avec les équipes pour tirer profit des enseignements de la recherche dans la prise de décision », mais également de favoriser « le partage de connaissances et le savoir qui en découle, […] en s’assurant que la connaissance est stockée et valorisée de manière efficace au sein de l’organisation »*.
Je suis convaincu qu’il faut proposer une recherche utilisateur orientée produit, c’est-à-dire rendre la Research actionnable pour un Product Management plus efficient.
Un point de vue partagé par nos Directeurs Conseils, Product Managers, Product Owners et Chefs de Projets chez Devoteam Creative Tech qui s’appuient sur la recherche utilisateur et sont convaincu.e.s de sa valeur. Ils disent notamment qu’ils ne peuvent plus s’en passer une fois qu’ils ont essayé. Ils m’ont également confié voir la différence quand la recherche utilisateur est trop ponctuelle ou absente. Et celles et ceux qui n’ont pas eu l’opportunité de l’expérimenter sont en grande majorité conscients de sa valeur : la recherche utilisateur peut les aider à mieux comprendre l’utilisateur, prioriser les besoins, être plus serein dans la direction prise par leur projet ou produit… Un mindset qui fait partie intégrante de l’ADN de Devoteam Creative Tech.
Bienvenue dans la team PM x Research ! On t’apprendra à comprendre l’étude ethno tout en maîtrisant le perfect split, pour le bénéfice de ton produit (et de ta souplesse).
Un exemple d’action concrète pour bien comprendre? Nous avons récemment organisé un webinar sur l’Atomic Research. Cette approche récente initiée par Daniel Pidcock et Tomer Sharon est une application avancée de la recherche utilisateur orientée produit, en particulier sur les enjeux du livrable et du référentiel de recherche utilisateur (alias le Repository).
Mais plus globalement, comment agir pour concrétiser cette idée, par quoi démarrer ? Vaste sujet sur lequel nous partagerons notre approche avec vous dans un second article à paraître prochainement !
Crédits photos : King Lip @ Unsplash
*Source : https://dovetailapp.com/blog/how-to-become-a-ux-researcher/