Comment les équipes produit peuvent développer l’empathie grâce à l’expérimentation | par Netflix Technologie Blog | octobre 2022

Comment les équipes produit peuvent développer l’empathie grâce à l’expérimentation |  par Netflix Technologie Blog |  octobre 2022

Une conversation entre Travis Brooks, chef de produit Netflix pour la plate-forme d’expérimentation, et George Khachatryan, PDG d’OfferFit

Noter: Je connais George depuis un petit moment maintenant, et comme nous avons beaucoup parlé de la philosophie de l’expérimentation, il m’a gentiment invité à leur bureau (virtuellement) pour leur série de conférenciers virtuels. Nous avons eu une conversation amusante avec son équipe et nous avons réalisé que certaines parties de celle-ci pourraient également faire un bon article de blog. Nous avons donc édité un peu conjointement pour plus de longueur et de clarté, et publions ici ainsi que sur Le blog d’OfferFit. J’espère que vous apprécierez le résultat. – Travis B

George Khachatrian : Travis, pourriez-vous nous en dire un peu plus sur votre parcours et comment vous êtes arrivé à votre poste actuel ?

Travis Brooks : Je suis chef de produit (PM) pour la plateforme d’expérimentation. Mon travail consiste donc à m’assurer que tous les outils et infrastructures dont nous disposons chez Netflix pour l’expérimentation font ce qu’ils doivent faire, et à établir la feuille de route pour l’année prochaine ou plus pour ce que nous construisons.

J’ai commencé en physique, mais j’ai fini par ne pas faire ça. Au lieu de cela, j’ai commencé à diriger une ressource d’information pour la littérature sur la physique des particules. L’une des choses auxquelles nous nous sommes heurtés était que nous n’avions pas vraiment assez d’utilisateurs pour mener des expériences. Nous étions tous des physiciens expérimentaux dans l’âme et nous voulions prendre des décisions sur une sorte de base de principe, mais nous n’avions pas suffisamment d’utilisateurs pour obtenir une signification statistique.

En même temps, j’ai eu l’opportunité d’aller rejoindre Yelp en tant que premier chef de produit là-bas pour la recherche, où il y avait beaucoup plus d’utilisateurs. C’est ce que j’ai fait et j’ai passé du temps à développer des algorithmes de recherche et des moteurs de recommandation chez Yelp.

Je suis arrivé chez Netflix il y a environ trois ans et j’ai d’abord dirigé une équipe de scientifiques des données responsables de l’expérimentation frontale – essentiellement tout ce que vous voyez sur la plate-forme Netflix. Et puis l’année dernière, j’ai été le PM pour l’ensemble de notre infrastructure et plateforme d’expérimentation.

George Khachatrian : Ainsi, au cours de la dernière décennie, de nombreuses entreprises technologiques ont de plus en plus adopté la conception centrée sur l’utilisateur – c’est en quelque sorte devenu la sagesse acceptée. Et de nombreuses entreprises non technologiques essaient également de plus en plus d’être centrées sur le client dans leur réflexion. Comment définiriez-vous la conception centrée sur l’utilisateur et quel rôle pensez-vous que l’expérimentation y joue ?

Travis Brooks : Permettez-moi de dire d’abord que je parle ici de mes propres expériences. Je ne parle pas pour Netflix.

Mais ce que je peux dire, c’est qu’en gros, je pense que la conception centrée sur l’utilisateur est vraiment une question d’empathie. Et en tant que personne qui a été à la fois un gestionnaire de projet utilisateur et un gestionnaire de projet d’outils, avoir de l’empathie pour votre utilisateur est l’un des traits fondamentaux qui définissent une bonne gestion de produit. Ainsi, lorsque nous disons « centrée sur l’utilisateur », nous disons simplement : « Hé, penchez-vous vraiment vers l’empathie ».

Lorsque vous construisez des choses, que vous soyez un concepteur visuel, ou un concepteur d’API, ou un PM, ou toute personne qui construit quelque chose, essayez de vous mettre à la place de l’utilisateur. Et si vous pouvez le faire, pas seulement au début lorsque vous écrivez les spécifications, mais tout au long du processus, vous faites un meilleur produit à la fin.

Dans l’acte de construire, nous avons tendance à être vraiment fascinés par le problème technique et à résoudre ce problème. Et en fait, il est probablement nécessaire de perdre de vue ce que l’utilisateur final va vivre afin de construire la meilleure solution technique. Donc, pour créer des produits efficaces pour l’utilisateur, nous avons besoin que la perspective de l’utilisateur soit mise au point assez régulièrement – “Oh, attendez, voici ce que l’utilisateur final va expérimenter” Ou, “Oh ouais, en fait, nous n’avons même pas besoin pour résoudre ce problème technique vraiment difficile et intéressant là-bas, car l’utilisateur final ne fera l’expérience de cette partie qu’ici. Pour moi, c’est ce que signifie la conception centrée sur l’utilisateur.

Comment nous assurons-nous que dans tous les aspects, qu’il s’agisse d’une API ou de la conception visuelle frontale, nous centrons l’utilisateur ? Comment vont-ils expérimenter ce produit ? Quels sont leurs points douloureux ? Ce que nous faisons est-il réellement lié à cet utilisateur final ?

George Khachatrian : Et quel rôle l’expérimentation joue-t-elle, le cas échéant, dans la construction de l’empathie ?

Travis Brooks : C’est vraiment le rôle d’un PM – s’assurer que l’équipe qui construit quelque chose maintient ce niveau d’empathie envers l’utilisateur. Mais ensuite, vous devez vous demander : “Comment le PM sait-il ce que veulent les utilisateurs ?” Droit? Ils ne sont pas magiques. Un bon PM ne sort pas complètement formé de la tête de Zeus avec toute la connaissance de ce que veulent les utilisateurs. Comment obtiennent-ils ces connaissances ? Je pense qu’il y a quatre façons.

1. L’une d’entre elles est d’envoyer un MP à un produit que vous utilisez vous-même. C’est le moyen le moins cher et peut-être le moins fidèle de développer l’empathie. “D’accord, eh bien, je suis un utilisateur, donc je sais ce que les utilisateurs ressentent parce que j’utilise le produit”. C’est une basse fidélité parce que c’est un N de 1, et vous n’êtes certainement pas un utilisateur typique. Vous êtes PM. Vous avez une manière différente d’interagir avec les produits que la plupart des gens.

2. Généralement, la prochaine chose que les gens font est qu’ils commencent à parler aux utilisateurs. Et s’ils sont intelligents, ils commencent à parler à des gens qui ne leur ressemblent pas. “Hé, comment utilisez-vous ce produit ? Qu’est-ce que vous appréciez ? Qu’est-ce que tu trouves douloureux là-dedans ? A quelle fréquence l’utilisez-vous? Pourquoi ne l’utilisez-vous pas plus ? À quand remonte la dernière fois que vous l’avez utilisé? Qu’est ce que tu essayais de faire? Y êtes-vous parvenu ? – toutes ces questions de recherche d’utilisateurs typiques que posent les PM. De très bons chercheurs utilisateurs se lancent dans ce type de recherche qualitative, et c’est un excellent moyen de développer une empathie plus large, à un niveau de fidélité plus élevé, que simplement “J’utilise mon produit”.

3. Ensuite, vous arrivez à une échelle où vous avez beaucoup d’utilisateurs, et leur parler devient un art de “Comment puis-je obtenir un échantillon représentatif de cette large population?” Et vous commencez à vous inquiéter que leur mémoire ne soit peut-être pas parfaite. Les utilisateurs déclarent eux-mêmes comment ils utilisent les choses, mais ce n’est pas vraiment la façon dont ils utilisent les choses. Nous savons que les gens ont beaucoup de biais cognitifs de cette façon. Alors vous commencez à entrer dans les données d’observation, et vous dites, « eh bien, d’accord, les gens déclarent qu’ils utilisent le produit une fois par semaine. Si je regarde les données, je peux voir que les gens utilisent le produit trois fois par semaine, donc je peux dire que ce qu’ils rapportent n’est pas tout à fait ce qui s’est passé. L’ajout de cette couche de données d’observation rend la recherche des utilisateurs beaucoup plus fidèle. Bien sûr, cela coûte plus cher et peut prendre du temps, des efforts et des investissements.

4. Mais même cette couche de données d’observation ne vous aide pas vraiment à comprendre comment les gens utilisent le produit au niveau d’un lien causal profond. Le jeu final d’essayer de comprendre l’utilisateur est, “si je fais X, les utilisateurs répondent de cette façon”. Et le seul moyen d’établir ce lien de causalité – peut-être pas le seul moyen, mais le moyen le plus fiable, le plus fidèle – est de montrer un échantillon aléatoire de vos utilisateurs X et de voir en quoi ils diffèrent du reste de vos utilisateurs qui n’ont pas ‘t see X. C’est le cœur de l’expérimentation : un coût élevé, une haute fidélité, une vitesse sans doute inférieure, un moyen de développer l’empathie. Ce n’est probablement pas le premier endroit où vous allez vous tourner pour développer l’empathie, mais vous allez y arriver et vous devrez éventuellement l’avoir dans votre arsenal.

Différentes échelles d'utilisation exigent différentes méthodes d'apprentissage
Différentes méthodes d’apprentissage fonctionnent de manière optimale à différentes échelles, il est donc utile de les avoir toutes dans votre arsenal.

George Khachatrian : Ouais. Vous parlez donc de l’importance de bâtir une culture d’expérimentation. Pouvez-vous expliquer quels seraient, selon vous, les principaux éléments d’une telle culture ?

Travis Brooks : Je pense qu’avoir un sens de l’humilité est super important. Si vous lisez nos articles de blog, ou les articles de quiconque effectue des tests à grande échelle comme Microsoft, vous voyez qu’ils testent et que la plupart de leurs traitements échouent. Et ce sont des traitements de concepteurs experts, de PM et d’ingénieurs qui ont le meilleur contexte, la meilleure recherche d’utilisateurs. Surtout que votre produit mûrit, il est difficile de l’améliorer. Même un produit moins mature est difficile à améliorer, car il s’avère que notre intuition est plutôt bonne. Nous comprenons ce dont les utilisateurs ont besoin. Ce n’est tout simplement pas un mécanisme très fiable. Donc, la plupart des traitements que nous proposons échouent, ce qui signifie que vous devez faire preuve de beaucoup d’humilité.

Vous ne pouvez pas épouser vos idées et dire : « Je vais faire une expérience ; cela va époustoufler le monde. Et vous finissez par perdre beaucoup de temps et d’efforts à essayer de montrer que votre traitement est bon, même s’il ne l’est pas. Vous manquez l’image plus grande, qui est, “Hé, vous avez essayé quelque chose. Cela n’a pas fonctionné. Que pouvez-vous apprendre de cette expérience pour éclairer le prochain traitement ? »

Les cultures où les gens peuvent vraiment réussir dans l’expérimentation impliquent beaucoup d’humilité, ce qui encourage ce type d’approche itérative. “Je suppose que cela ne fonctionnera pas parce que je peux voir d’après l’histoire que la plupart de ces choses ne fonctionnent pas. Ce que je vais faire, c’est le diffuser et je vais en tirer des leçons. Peut-être que j’aurai de la chance et que ça marchera tout de suite, mais peut-être que je ne le ferai pas. J’apprendrai des deux prochains tests et j’arriverai à un endroit où je pourrai réellement résoudre ce problème.

L’autre chose qui me semble importante, c’est d’avoir une culture de débat ouvert, où les décisions sont prises au grand jour. Plus votre prise de décision est ouverte, plus les données vocales sont fortes. Lorsque la prise de décision est confinée, dans le bureau d’une personne ou dans la tête d’une personne, c’est difficile. Souvent, lorsque les gens débattent et qu’ils ne sont pas d’accord, ils se tournent vers les données, car il est beaucoup plus difficile d’être en désaccord avec cela. Et donc si vous voulez une culture d’expérimentation, si vous voulez des données, ayez un débat ouvert. Avoir une prise de décision ouverte. Ensuite, les gens voient plus clairement qu’ils ont besoin de données, qu’ils ont besoin d’expérimenter.

Alors oui, je pense que l’humilité et la prise de décision ouverte sont vraiment importantes.

Facebook
Twitter
LinkedIn
Pinterest

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.