L'économiste

Imaginez que vous demandez à un ingénieur en structure : « Puis-je installer une bibliothèque lourde sur ce mur? » Un bon ingénieur répond : « Oui, si vous la vissez dans les montants en bois. Pas dans le plâtre. » Un ingénieur moins expérimenté commence à expliquer les calculs de charge, les types de murs et les facteurs de sécurité. Tout ce qu’il dit est correct. Et vous ne savez toujours pas quoi faire avec votre bibliothèque.

Beaucoup de titulaires d’un doctorat en économie postulent à des postes de scientifique des données. Ils connaissent l’inférence causale mieux que presque tout le monde dans l’industrie : doubles différences, variables instrumentales, contrôle synthétique. Ils ont passé des années à se demander : « Cet effet est-il réel, ou est-ce autre chose? » Les équipes produit ont besoin de cette rigueur.

Ce qui manque, ce n’est généralement pas le savoir. C’est la rapidité, le sens du produit et une réponse courte pour quelqu’un qui doit décider cette semaine. En recherche, une réponse rigoureuse dans six mois convient. Dans une équipe produit, une réponse rigoureuse vendredi vaut souvent mieux qu’une réponse parfaite en mars. L’entrevue de Rahul montre les deux côtés.

RM

La personne candidate

Rahul Mehta

Économiste, doctorat et postdoctorat, en transition vers l'industrie

• Doctorat en économie (travail)
• 2 ans de postdoctorat
• Stata, R, Python
• Toronto

• Chercheur postdoctoral, Centre for Labour and Migration Research, Northgate University, de 2024 à aujourd’hui
• Doctorat en économie, Northgate University, 2024. Thèse : la formation linguistique et l’emploi des nouveaux arrivants
• Article : « Cours de langue gratuits et emploi des nouveaux arrivants : résultats d’une expansion provinciale » (doubles différences, étude d’événement, contrôle synthétique), en révision
• Article : rendement de la formation en apprentissage, avec la distance jusqu’à un centre de formation comme instrument
• Enseignement de l’économétrie à des étudiants à la maîtrise (3 trimestres)
• Stata, R, Python (pandas, statsmodels), SQL (projets de cours), LaTeX

Ce que Thandiwe voit avant l’appel

Thandiwe lit le CV avec intérêt. Les méthodes causales sont exactement celles que l’offre nomme sans les expliquer. Et le sujet de la thèse, la formation linguistique, est proche de l’univers de Parlo.

Elle voit aussi ce qui manque : aucun produit, aucune partie prenante, aucun délai plus court que celui d’une revue scientifique. Chez Parlo, un scientifique des données travaille seul avec un gestionnaire de produit. La question n’est donc pas : « Rahul connaît-il l’inférence causale? » C’est : « Peut-il l’utiliser assez vite et l’expliquer assez simplement pour qu’un gestionnaire de produit puisse agir? »

Sa courte liste :

• Dans son article, comment a-t-il su que l’effet était réel? (Elle s’attend à une bonne réponse.)
• Dans le cas Parlo, part-il de la décision ou de la méthode?
• Peut-il formuler une recommandation en quelques phrases, tout en exprimant l’incertitude?
• Sait-il ce que « bon » signifie pour une application par abonnement : apprentissage, engagement, revenus, coût?

Termes de cette page

• Doubles différences (DiD) : comparez le changement dans un groupe traité au changement dans un groupe semblable non traité, pendant la même période. Le second changement retire ce qui se serait produit de toute façon, comme l’effet de la saison. Cette méthode fonctionne seulement si les deux groupes auraient évolué en parallèle sans le traitement (« tendances parallèles »).
• Étude d’événement : une méthode de doubles différences qui montre l’écart pour chaque période avant et après le changement. Les écarts avant le changement devraient être proches de zéro. Sinon, les groupes évoluaient déjà différemment.
• Contrôle synthétique : lorsqu’une seule unité reçoit le traitement (une province, un pays), créez-en une « copie ». Combinez des unités non traitées, avec différents poids, qui lui ressemblaient bien dans le passé. Comparez ensuite l’unité réelle à sa copie après le changement.
• Variable instrumentale : un élément qui modifie le traitement, mais qui influence le résultat seulement par ce traitement. On l’utilise quand on ne peut pas mener une expérience.
• Erreurs-types regroupées : quand les personnes d’un même groupe (une province) se ressemblent, leur nombre surestime la quantité d’information indépendante disponible. Vous calculez l’incertitude par groupe.
• Rétention au jour 30, utilisateurs actifs hebdomadaires (WAU), puissance, consultation prématurée des résultats, effet de nouveauté : consultez les termes dans L’analyste.

L’entrevue

Minutes 0 à 5 : l'ouverture

Thandiwe(intervieweur) :

Bonjour Rahul. Je suis Thandiwe, scientifique des données principale. Merci d’être là. D’abord, parlez-moi d’un travail qui a changé une décision. Je vais poser beaucoup de questions pour approfondir. Ensuite, un vrai problème de Parlo, puis vos questions. Aucun outil d’IA ici, c’est seulement une conversation. D’accord?

Rahul(personne candidate) :

D’accord. Je dois dire que, dans le milieu universitaire, « changer une décision », c’est… pas toujours clair. Mais je vais essayer.

Thandiwe(intervieweur) :

Ça va, racontez-moi comment ça s’est passé.

Minutes 5 à 20 : l'article, puis l'approfondissement

Rahul(personne candidate) :

Alors, mon article principal. En 2017, deux provinces ont rendu leurs cours de langue gratuits pour les nouveaux arrivants. Avant, il fallait payer. La question était : est-ce que ça les aidait à trouver un emploi? J’ai utilisé une enquête nationale auprès des nouveaux arrivants. J’ai comparé les deux provinces aux autres provinces, avant et après. Donc, une différence de différences. Le résultat principal : deux ans après l’arrivée, le taux d’emploi était plus élevé d’environ 3 points de pourcentage. L’intervalle était large, à peu près de 0,5 à 5,5.

Thandiwe(intervieweur) :

Et la décision?

Rahul(personne candidate) :

Une des provinces a réévalué le programme en 2025. Elle l’a maintenu, et le rapport citait mon article. Mais il citait aussi six autres études. Donc, je ne peux pas dire que mon article a changé la décision. Honnêtement, je ne sais pas.

Pourquoi cela fonctionne

Rahul n’affirme rien qu’il ne peut prouver, même sur sa propre contribution. C’est exactement ainsi qu’il aborde les données. C’est un bon signe pour ce poste.

Thandiwe(intervieweur) :

D’accord. Comment saviez-vous que les 3 points étaient réels? Que les deux provinces n’étaient pas simplement différentes?

Rahul(personne candidate) :

Trois choses. D’abord, une étude d’événement, donc la différence pour chaque année avant 2017. Elles étaient toutes proches de zéro. Les provinces évoluaient donc en parallèle avant. Ensuite, un placebo : j’ai fait la même analyse sur les personnes qui parlaient déjà anglais ou français à leur arrivée. Elles n’ont pas besoin des cours. Et pour elles, aucun effet. Troisièmement…

Thandiwe(intervieweur) :

Continuez.

Rahul(personne candidate) :

Troisièmement, les erreurs-types. Seulement deux provinces avaient reçu le traitement. Les erreurs-types habituelles par groupe ne sont pas fiables avec si peu de groupes. J’ai utilisé un wild cluster bootstrap, un rééchantillonnage adapté aux données groupées. Même ça n’est pas parfait avec seulement deux provinces traitées. J’ai donc aussi vérifié avec un contrôle synthétique, en utilisant les autres provinces comme donneuses. Le résultat était semblable, un peu plus petit.

Ce que l’intervieweur vérifie

La réponse est approfondie et correcte. Avec seulement deux provinces traitées, les méthodes habituelles sous-estiment l’incertitude. Même les meilleures méthodes ont des difficultés. Rahul connaît ces deux limites et vérifie avec une deuxième méthode. Peu de gens en dehors de l’économie connaissent cela. Thandiwe pourrait approfondir, mais elle a vu assez de rigueur. Ce qu’elle doit apprendre maintenant est différent.

Thandiwe(intervieweur) :

Très clair. Si vous recommenciez, avec ce que vous savez maintenant?

Rahul(personne candidate) :

Hmm. Je pense que j’écrirais la version courte d’abord. Les responsables des politiques à la province m’ont dit qu’ils lisaient seulement la première page. J’ai passé deux ans sur la méthode et un après-midi sur la première page.

Pourquoi cela fonctionne

Cette réponse est précieuse, et Rahul la donne de lui-même. Il sait déjà que son point faible est la version courte. Thandiwe va tester exactement cela dans l’étude de cas.

Minutes 20 à 32 : le cas Parlo et une très longue première réponse

Thandiwe(intervieweur) :

D’accord, voici notre vraie situation. Il y a cinq semaines, nous avons lancé « Talk with Pip », pour pratiquer la conversation avec une IA. Nous l’avons offert à 20 % des nouveaux utilisateurs. Le nombre d’utilisateurs actifs par semaine dans ce groupe a augmenté d’environ 6 %. Mais la rétention au jour 30 des nouveaux utilisateurs a baissé de 31 à 29 %. Notre gestionnaire de produit veut l’offrir à tout le monde avant janvier. Si vous étiez notre scientifique des données, que feriez-vous?

Rahul(personne candidate) :

D’accord. Ma première inquiétude, c’est que les 20 % ne soient pas comparables au reste. Un lancement auprès d’un groupe n’est généralement pas aléatoire. Je voudrais donc construire un scénario contrefactuel crédible. Ce que je ferais, c’est un contrôle synthétique. On prend le groupe traité et on construit une combinaison pondérée de groupes non traités. Par exemple, des cohortes de différents pays ou de différentes semaines. Cette combinaison reproduit la rétention du groupe traité dans la période avant le lancement. Ensuite, on compare après le lancement. Et je voudrais au moins huit ou dix périodes avant pour ajuster les poids. Puis des tests placebo, où on fait comme si chaque groupe donneur avait été traité. On vérifie si l’effet du vrai groupe est inhabituel par rapport à la distribution des placebos. Et ensuite, pour l’inférence…

Thandiwe(intervieweur) :

Mm-hm.

Rahul(personne candidate) :

…et pour l’inférence, j’utiliserais le classement du rapport entre l’erreur après et l’erreur avant. Parce qu’avec le contrôle synthétique, les erreurs-types habituelles ne s’appliquent pas. Ensuite, pour vérifier la robustesse, une différence de différences avec les cohortes non traitées. Avec une étude d’événement pour vérifier les tendances avant le lancement. Et peut-être, s’il y a quelque chose qui pousse les gens à utiliser Pip sans influencer directement la rétention… Comme une notification envoyée au hasard. Ça pourrait servir d’instrument pour mesurer l’effet de l’utilisation réelle de Pip…

Les trois minutes suivantes, en bref

Rahul continue pendant environ trois minutes. Il explique comment choisir l’ensemble des groupes donneurs et combien de périodes avant le lancement suffisent. Il décrit aussi une deuxième vérification de robustesse. Tout ce qu’il dit est correct pour le problème qu’il imagine. Puis son image vidéo se fige.

Rahul(personne candidate) :

…et ça nous donnerait un résultat beaucoup plus crédible…

Thandiwe(intervieweur) :

Désolée Rahul, votre image s’est figée quelques secondes. Je vous ai perdu après « ensemble des groupes donneurs ». Mais en fait, est-ce que je peux vous arrêter un instant?

Rahul(personne candidate) :

Oui, bien sûr. Désolé, j’ai beaucoup parlé.

Thandiwe(intervieweur) :

Ça va. Vous avez supposé que les 20 % n’étaient pas choisis au hasard. Pourquoi?

Rahul(personne candidate) :

Dans mon expérience, un lancement auprès de « 20 % » est généralement un choix. Une région, ou les utilisateurs les plus actifs.

Thandiwe(intervieweur) :

Ici, c’était aléatoire, selon l’identifiant utilisateur, dans notre outil d’expérimentation. Mais seulement sur iOS, parce qu’Android n’était pas prêt. Donc, 20 % des nouveaux utilisateurs iOS.

Rahul(personne candidate) :

Ah. Pause. D’accord. Alors je résolvais le mauvais problème. Si c’est aléatoire à l’intérieur d’iOS, nous avons une expérience. Nous n’avons besoin de rien de synthétique pour cette comparaison. J’aurais dû demander d’abord.

Où cela tourne mal

La première réponse de Rahul a duré environ quatre minutes. Elle reposait sur une hypothèse qu’il n’avait pas vérifiée. Une question au départ, « Comment les 20 % ont-ils été choisis? », aurait révélé la répartition aléatoire. La majeure partie de son plan devenait alors inutile. Son inquiétude était en partie justifiée, comme il le découvre une minute plus tard. Le tableau de bord de Kenji compare effectivement des groupes différents. Mais la solution était une question, pas une étude. Dans une entrevue avec étude de cas, posez d’abord une ou deux questions. Donnez ensuite une première réponse courte, puis proposez d’approfondir : « Je peux détailler n’importe quelle partie. »

Pourquoi cela fonctionne

La phrase suivante de Rahul compte. Il ne défend pas son plan. Il dit : « Je résolvais le mauvais problème », et change immédiatement de direction. Beaucoup de gens trouvent cela difficile après une longue réponse. Consultez Acquérir de vraies compétences et apprendre à les expliquer.

Minutes 32 à 50 : la rigueur et le vendredi

Thandiwe(intervieweur) :

D’accord. Donc, avec une répartition aléatoire sur iOS. Qu’est-ce qui vous inquiète maintenant?

Rahul(personne candidate) :

Les 31 %. Qui est dans ce groupe?

Thandiwe(intervieweur) :

Tous les autres nouveaux utilisateurs, les mêmes semaines. Les deux plateformes. Ça vient du tableau de bord de Kenji.

Rahul(personne candidate) :

Alors la plateforme influence la comparaison. Les gens qui ont choisi un iPhone ne sont pas un échantillon aléatoire de vos utilisateurs. Différents pays, peut-être un revenu plus élevé, peut-être plus souvent une pièce calme pour parler. Je m’attendrais à ce qu’ils restent plus longtemps de toute façon, avec ou sans Pip. La répartition aléatoire est à l’intérieur d’iOS. La comparaison correcte, c’est donc iOS avec Pip contre iOS sans Pip.

Thandiwe(intervieweur) :

Vous avez raison, les utilisateurs iOS restent plus longtemps, chaque mois. Sur iOS sans Pip, les mêmes jours, c’est environ 33 %.

Rahul(personne candidate) :

Donc la baisse est d’environ 4 points, pas 2. La plateforme en cachait la moitié. Et encore une chose. Même les 4 points répondent seulement à « quel est l’effet de Pip sur les nouveaux utilisateurs iOS fin août ». Pas à « quel est l’effet de Pip sur tout le monde en janvier ». Pour les utilisateurs Android, l’effet pourrait être différent. Même son signe pourrait être différent.

Pourquoi cela fonctionne

C’est le point le plus important de tout le cas. Peu de candidats l’expriment aussi clairement. Rahul le souligne deux fois. D’abord, le tableau de bord compare des utilisateurs iOS à un groupe composé surtout d’utilisateurs Android. La plateforme cache donc une partie de la baisse. Quand la composition de deux groupes diffère, un total peut vous induire en erreur. Dans un cas extrême, le résultat s’inverse : c’est le paradoxe de Simpson. Ensuite, une répartition aléatoire rend la comparaison équitable seulement à l’intérieur du groupe réparti. Elle ne rend pas le résultat valable pour d’autres personnes ou une autre saison. Les économistes appellent cela la validité externe.

Thandiwe(intervieweur) :

Quoi d’autre?

Rahul(personne candidate) :

Pardon, je peux demander ce que signifie exactement « rétention au jour 30 »? Actif le jour 30?

Thandiwe(intervieweur) :

Au moins une séance dans la semaine précédant le jour 30. Donc entre le jour 24 et le jour 30.

Rahul(personne candidate) :

Alors aujourd’hui, seules les personnes inscrites dans les premiers jours peuvent avoir cette mesure. Combien?

Thandiwe(intervieweur) :

Environ les cinq premiers jours. Environ 2 400 dans le groupe Pip. 9 600 sur iOS sans Pip. Le groupe du tableau de bord de Kenji compte environ 25 000 personnes. Sa page indique moins 2 points, avec p autour de 0,04.

Rahul(personne candidate) :

Je vais calculer rapidement pour iOS. Une rétention autour de 30 %, donc l’erreur-type pour 2 400 est d’environ… 0,9 point. Pour 9 600, environ la moitié. Ensemble, environ 1 point. Donc moins 4, plus ou moins 2. À peu près de moins 6 à moins 2. C’est loin de zéro. Le résultat du tableau de bord est à la limite, mais c’est la mauvaise comparaison de toute façon.

Thandiwe(intervieweur) :

Et les gens ont regardé le tableau de bord plus d’une fois.

Rahul(personne candidate) :

Sourit. Chaque matin, j’imagine?

Thandiwe(intervieweur) :

Rit. Chaque matin.

Rahul(personne candidate) :

Alors son 0,04 ne veut pas dire grand-chose. Avec des consultations quotidiennes, le risque d’un faux résultat « significatif » dépasse plusieurs fois 5 % à un moment donné. Si on veut regarder chaque jour, il faut un test séquentiel, avec un seuil plus strict à chaque consultation. Mais la comparaison iOS est à environ quatre erreurs-types de zéro. Les consultations répétées ne peuvent pas expliquer ça. Je crois donc qu’il y a une vraie baisse, pour ces utilisateurs. Ce que je ne crois pas, c’est que ça nous renseigne sur Android ou janvier.

Ce que l’intervieweur vérifie

Le calcul mental de Rahul est correct. La racine carrée de 0,3 × 0,7 ÷ 2 400 est d’environ 0,009, soit 0,9 point. L’erreur-type combinée est d’environ 1 point. Les consultations répétées affaiblissent une valeur p limite comme 0,04. Elles ne font pas disparaître un résultat situé à environ quatre erreurs-types de zéro. Rahul distingue clairement les deux.

Thandiwe(intervieweur) :

Un autre fait : le nombre de leçons terminées a baissé dans le groupe Pip.

Rahul(personne candidate) :

Intéressant. Alors les leçons pourraient être le mécanisme. Pip remplace les leçons, et les leçons font revenir les gens. Mais un avertissement : ne comparez pas la rétention « pour les utilisateurs ayant le même nombre de leçons ». Les leçons ont lieu après le traitement. Si vous les contrôlez, vous retirez une partie de l’effet que vous voulez mesurer. Et vous pouvez créer un faux effet.

Pourquoi cela fonctionne

Cet avertissement est subtil et correct. Une variable modifiée par la fonctionnalité elle-même, comme les leçons terminées, ne doit pas servir à « égaliser les groupes ». Cela fausse la comparaison que la répartition aléatoire avait rendue équitable. Beaucoup d’analystes expérimentés font cette erreur. Consultez Comparer des options.

Thandiwe(intervieweur) :

Bien. D’accord. Maintenant. C’est vendredi. Kenji vient vous demander : « Est-ce que je peux le lancer pour tout le monde? » Que lui diriez-vous vendredi?

Rahul(personne candidate) :

Je dirais que l’estimation de moins deux points de pourcentage du tableau de bord est biaisée par la plateforme. Sa valeur p n’est pas valide à cause des consultations répétées. La comparaison à l’intérieur d’iOS donne environ moins quatre, avec un intervalle d’à peu près moins six à moins deux. Ce résultat résiste aux consultations répétées. Toutefois, cette estimation se limite aux utilisateurs iOS inscrits fin août. Sa validité externe pour les utilisateurs Android et la cohorte de janvier est donc inconnue. Et le résultat des utilisateurs actifs par semaine pose un problème : la mesure inclut le traitement lui-même…

Thandiwe(intervieweur) :

Je vous arrête. Kenji a deux minutes entre deux réunions. Il n’est pas statisticien. Qu’est-ce qu’il entend?

Rahul(personne candidate) :

Longue pause. Il entend… que je ne sais pas.

Thandiwe(intervieweur) :

Peut-être. Essayez encore. Plus court.

Rahul(personne candidate) :

« Les données suggèrent un effet négatif sur la rétention des utilisateurs iOS. Mais nous ne pouvons pas encore le généraliser aux autres utilisateurs. »

Thandiwe(intervieweur) :

Et il dit : « D’accord. Alors, je peux le lancer ou pas? »

Rahul(personne candidate) :

Hmm. Je dirais que c’est sa décision, pas la mienne. Je peux lui donner les données.

Thandiwe(intervieweur) :

C’est sa décision. Mais il vous demande une recommandation. Ici, le scientifique des données en donne une.

Rahul(personne candidate) :

Pause. D’accord. « Je recommande… de ne pas le lancer pour tout le monde maintenant. Parce que la rétention a baissé sur iOS, probablement à cause de Pip, et nous ne savons pas pour Android. Nous pouvons faire un test bien conçu et en savoir plus dans… quelques semaines. » Je ne suis pas sûr pour les semaines. Il faudrait que je calcule.

Thandiwe(intervieweur) :

C’est mieux. Merci.

La limite

Voici la limite de Rahul. Ce ne sont pas les statistiques. Tout ce qu’il a dit vendredi était correct. Sa limite consiste à transformer des affirmations correctes en recommandation utile à une personne occupée. Son premier réflexe était de décrire les données. Son deuxième était de dire « c’est sa décision ». Les deux sont normaux en recherche, où le chercheur présente les résultats et le lecteur décide. Dans une équipe produit, le scientifique des données doit aussi dire « Je recommande… ».

Une meilleure réponse

Voici ce dont Kenji a besoin, en environ 30 secondes :

« Ma recommandation : ne le lançons pas encore pour tout le monde. Les gens aiment Pip, l’utilisation augmente. Mais chez les nouveaux utilisateurs iOS, la rétention baisse d’environ 4 points, et je crois que cette baisse est réelle. Votre tableau de bord indiquait 2 parce qu’il compare iOS à Android. Nous ne savons encore rien sur les utilisateurs Android ni sur ceux de janvier. Si la baisse les touche aussi après un lancement général en janvier, nous perdrons beaucoup d’abonnés. Alors, cherchons la cause. Les leçons ont baissé, c’est donc ma première hypothèse. Ensuite, testons une version modifiée dès lundi sur la moitié des nouveaux utilisateurs iOS, avec des règles fixées d’avance. Vous aurez une réponse fin novembre, avant janvier. »

Tout le contenu de la version prudente de Rahul se trouve dans cette réponse. La différence est l’ordre : la recommandation d’abord, la raison en termes d’affaires, puis une date. Vous pouvez garder les détails techniques pour les questions de suivi. Kenji les demandera s’il les veut. Consultez Expliquer vos décisions.

Thandiwe(intervieweur) :

Encore une question. Si vous deviez choisir une mesure principale pour le nouveau test, laquelle?

Rahul(personne candidate) :

Chaque mesure ici est un indicateur indirect. Ce que nous voulons vraiment, c’est l’apprentissage, et vous ne le mesurez pas bien.

Thandiwe(intervieweur) :

C’est vrai. Choisissez-en une quand même.

Rahul(personne candidate) :

La rétention au jour 30. Avec les leçons et… la conversion au forfait payant comme mesures secondaires. Et je commencerais à donner le test de classement à un échantillon aléatoire. Comme ça, dans six mois, vous pourrez mesurer l’apprentissage.

Thandiwe(intervieweur) :

Et le coût? Chaque conversation nous coûte environ quatre cents. Les grands utilisateurs en ont 20 ou plus par semaine.

Rahul(personne candidate) :

Je n’ai pas du tout pensé au coût. Vingt fois quatre cents, c’est 80 cents par semaine. Environ 3,50 $ par mois pour un grand utilisateur. S’il utilise le forfait gratuit, c’est une vraie dépense. Donc, le coût par utilisateur devrait être un garde-fou. Désolé, c’est une lacune pour moi. En recherche, personne ne paie par conversation.

Où cela tourne mal

Rahul n’a jamais posé de question sur le coût, les revenus ou le forfait payant avant que Thandiwe les mentionne. Un scientifique des données en produit y pense sans qu’on le lui demande, parce que le gestionnaire de produit le fera. Son calcul était rapide et correct une fois la question posée. La lacune concerne sa première question, pas sa compétence.

Thandiwe(intervieweur) :

Et si Kenji le lance quand même sur Android, sans répartition aléatoire? Pourriez-vous encore faire quelque chose d’utile?

Rahul(personne candidate) :

Sourit. Là, nous sommes dans mon monde. Oui. Une différence de différences. Les nouveaux utilisateurs Android avant et après le lancement, comparés aux nouveaux utilisateurs iOS sans Pip pendant les mêmes semaines. Le groupe iOS retire l’effet saisonnier, si les deux plateformes évoluent en parallèle. Je vérifierais ça sur les semaines précédentes, comme dans mon article. C’est moins solide qu’une expérience. Mais bien mieux que « la rétention a baissé après le lancement », parce que ça reflète surtout la saison.

Retour à son point fort

C’est exactement là que ses méthodes aident une équipe produit. Une fonctionnalité a été lancée sans expérience, et une question arrivera de toute façon. Il choisit un plan simple, nomme son hypothèse et explique comment la vérifier. Le contrôle synthétique conviendrait à une autre situation. Par exemple, un lancement dans un pays entier, avec d’autres pays comme donneurs.

Minutes 50 à 60 : les questions de Rahul et la conclusion

Rahul(personne candidate) :

Je peux demander combien de temps est consacré à la recherche, et combien aux questions du gestionnaire de produit?

Thandiwe(intervieweur) :

Honnêtement, peu de recherche au sens où vous l’entendez. Environ un tiers concerne les tableaux de bord et les questions ponctuelles. Le reste, c’est surtout des expériences et des analyses comme celle-ci, avec des délais de quelques jours ou semaines.

Rahul(personne candidate) :

Et est-ce possible de publier? Même parfois?

Thandiwe(intervieweur) :

Pas vraiment. Peut-être un article de blogue une fois par année.

Rahul(personne candidate) :

D’accord. Merci d’être directe. Ça m’aide.

Pourquoi cela fonctionne

Les bonnes questions ne servent pas seulement à impressionner la personne qui vous interviewe. Elles permettent aussi de vérifier si le poste vous convient. Rahul apprend quelque chose d’important pour sa propre décision. Consultez Une entrevue est une conversation dans les deux sens.

Thandiwe(intervieweur) :

D’accord, notre temps est écoulé. Merci, Rahul. Votre remarque sur les différences entre utilisateurs iOS et autres utilisateurs était la meilleure que j’ai entendue pour ce cas. Mira vous contactera cette semaine.

Rahul(personne candidate) :

Merci. Et encore désolé pour la longue première réponse.

Après l’appel : les notes de Thandiwe

Candidat : Rahul Mehta. Étude de cas produit, 60 minutes.

Preuves solides

• Inférence causale. Excellent. Réponses justes sur le petit nombre de groupes, les tests placebo et les tendances préalables. Meilleur point de toute l’étude de cas, tous candidats confondus : les utilisateurs d’iOS forment un groupe sélectionné. Le tableau de bord (iOS comparé aux deux plateformes) masque donc la moitié de la baisse. Même le résultat équitable de 4 points pourrait ne pas s’appliquer à Android ou à janvier. A calculé l’erreur-type de tête, correctement. A bien averti de ne pas contrôler le nombre de leçons terminées.
• Honnêteté. N’a pas prétendu que son article avait eu un impact. A changé de direction immédiatement quand son hypothèse s’est révélée fausse.

Quelques preuves

• Statistiques des expériences. Connaît bien les consultations prématurées des résultats, la puissance et les tests séquentiels. N’a pas conçu le nouveau test en détail (durée, répartition); nous avons manqué de temps.

Aucune preuve

• SQL et tableaux de bord au quotidien. Projets de cours seulement; l’entretien de présélection était satisfaisant.

Préoccupations

• Communication avec un gestionnaire de produit. Première réponse au cas : quatre minutes sur une méthode, fondée sur une hypothèse non vérifiée. À « que diriez-vous à Kenji vendredi? », a eu besoin de trois essais et d’un encouragement pour formuler une recommandation.
• Compréhension du produit. N’a pas abordé les coûts, les revenus ou la conversion sans qu’on le lui demande.

Recommandation : non pour ce poste. Dans notre équipe, il serait souvent seul avec un gestionnaire de produit. Aujourd’hui, ses lacunes en communication se feraient sentir chaque semaine. Sa rigueur est réelle et rare. Je serais heureuse de le revoir dans un an ou deux, ou pour un poste davantage axé sur la recherche. Veuillez lui donner une rétroaction détaillée; il en fera bon usage.

La suite

Simone était d’accord avec la recommandation de Thandiwe. Le seul poste vacant est allé à une autre personne. Mira a appelé Rahul pour lui proposer un appel de rétroaction avec Thandiwe, et il a accepté.

Pendant l’appel, Thandiwe a été précise. Elle lui a dit que son point sur iOS était le meilleur de tout le processus. Elle lui a parlé de sa première réponse de quatre minutes et des trois essais pour la réponse du vendredi. Elle lui a suggéré un exercice : pour chaque analyse, écrire d’abord trois phrases pour une personne qui ne lira rien d’autre.

Trois mois plus tard, Rahul a rejoint l’équipe de recherche économique d’une grande banque. Son travail consiste à estimer l’effet des changements de politiques sur la clientèle. Deux semaines après son arrivée, il a écrit à Thandiwe. Il lui a dit qu’il avait commencé sa première présentation à un directeur par une recommandation. Le directeur lui avait demandé d’autres analyses du même genre. Il l’a remerciée pour sa rétroaction honnête.

Un « non » ne veut pas toujours dire « pas assez bon ». Parfois, il veut dire « pas ce poste, pas encore ». Rahul a utilisé la rétroaction et a trouvé un poste qui avait précisément besoin de sa rigueur. Voir La chance joue aussi un rôle.

Ce qu’il faut retenir

• Posez des questions avant de concevoir votre plan. Le plan de quatre minutes de Rahul reposait sur une hypothèse : les 20 % n’étaient pas choisis au hasard. Une question lui aurait évité une grande partie de ce travail.
• Donnez une première réponse courte, puis proposez d’en dire plus. « Je ferais X, surtout à cause de Y. Je peux approfondir n’importe quelle partie. » La personne qui mène l’entrevue choisit la suite.
• Un scientifique des données fait des recommandations. Décrire les preuves représente la moitié du travail. « Je recommande…, parce que…, et nous en saurons plus d’ici… » représente l’autre moitié.
• La rigueur est une force quand elle change la décision. Le point de Rahul sur iOS comptait parce qu’il changeait ce que Kenji devait faire. Les détails de sa méthode ne changeaient pas la décision.
• Pensez aux coûts et aux revenus sans qu’on vous le demande. Dans une entreprise de produits, chaque fonctionnalité a un coût, et le gestionnaire de produit posera la question.

Si votre profil ressemble à celui de Rahul

Vos compétences en inférence causale sont rares et précieuses. Vos lacunes concernent la rapidité et les réponses courtes. Les deux s’améliorent avec la pratique.

1. Exercez-vous à la « réponse du vendredi » chaque semaine. Prenez un article que vous connaissez bien. Écrivez une recommandation pour un gestionnaire occupé en trois phrases : quoi faire, pourquoi et quand vous en saurez plus. Dites-la à voix haute en moins de 30 secondes. Voir Expliquer vos décisions.
2. Exercez-vous aux études de cas produit avec un chronomètre. Consacrez les deux premières minutes uniquement aux questions. Donnez ensuite une première réponse d’une minute. Demandez à un ami de vous arrêter après 90 secondes.
3. Apprenez le côté produit d’une application par abonnement : forfaits gratuits et payants, conversion, rétention, coût par utilisateur. Pour chaque cas, demandez-vous : « Comment cette fonctionnalité génère-t-elle des revenus ou des coûts? »
4. Apprenez à connaître les expériences en ligne aussi bien que les quasi-expériences : taille d’échantillon et puissance, consultations prématurées des résultats, effets de nouveauté et mesures garde-fous. Revoyez Comparer des options en pensant à un test produit.
5. Renforcez vos compétences en SQL avec des requêtes sur la rétention et les cohortes. Voir Le temps et le classement.
6. Réécrivez votre CV pour l’industrie. Placez la décision ou la question en premier, puis la méthode. « Mesuré si des cours de langue gratuits augmentaient l’emploi (différences de différences) » se lit mieux que la méthode seule. Voir Les éléments d’un portfolio.