Leçons apprises sur les produits : une conversation avec Shreyas Doshi et John Cutler

Publié: 2021-07-13

En relativement peu de temps, Shreyas Doshi est devenu l'un des dispensateurs de conseils produits les plus populaires sur Twitter. Pourquoi? Son écriture est claire, humble et consciente de soi - des traits qui manquent souvent au milieu du tuyau d'incendie des prises chaudes. Son format de prédilection ? Fils. Et beaucoup d'entre eux. Entrelacés mais organisés. La sagesse d'une carrière emballée dans des chaînes de 280 caractères. Disponible pour tout le monde ici.

J'étais très curieuse de connaître la personne derrière la (bonne sorte de) folie. Nous avons donc organisé un entretien ! Nous couvrons des sujets tels que le leadership, devenir un meilleur auditeur, le rôle des cadres intermédiaires, la carrière et l'identité de soi, l'entêtement, le théâtre du calendrier et le traitement de vos tableaux de bord comme des produits.

Qu'est-ce qui s'est démarqué ? Shreyas possède une riche expérience en gestion de produits. Il a travaillé en tant que chef de produit de première ligne et responsable de chefs de produit dans des entreprises telles que Stripe, Google, Twitter et Yahoo. C'est un grand écrivain et orateur. Mais c'est son humilité et sa prévenance qui brillent vraiment. Il avertit les gens de ne pas copier aveuglément ses conseils et admet ouvertement qu'il a appris bon nombre de ces leçons à la dure.

L'entretien dure 1h30 (voir le lecteur audio ci-dessous). Si vous voulez vous déplacer, nous avons créé un aperçu de l'interview ci-dessous avec des horodatages. Pour chaque section, Shreyas a eu la gentillesse de fournir des liens vers des fils de discussion connexes.

Vous avez des questions de suivi pour Shreyas ? Veuillez tweeter vos questions, y compris @Amplitude_HQ, @shreyas et #shreyasinterview. S'il y a suffisamment d'intérêt, nous essaierons de planifier une AMA de suivi.

J'ai une question pour @shreyas et @johncutlefish #shreyasinterview Cliquez pour tweeter

Et si vous souhaitez en savoir plus sur la stratégie produit et le leadership en matière de gestion de produits, assurez-vous de télécharger une copie du manuel North Star. Il regorge de conseils et de cadres pour vous aider à avoir un impact immédiat sur votre entreprise et votre équipe.

Table des matières de l'entrevue

La transcription complète comprend des tweets associés pour le contexte. Merci à Shreyas de les organiser pour tout le monde!

  • Présentation [00:00:00]
  • "Ne croyez pas tout ce que j'écris…" [00:01:07]
  • Se comprendre [00:04:03]
  • Devenir un meilleur auditeur [00:05:13]
  • Transition IC vers gestionnaire [00:11:49]
  • Discuter de l'incertitude et de la culture organisationnelle [00:14:10]
  • L'encadrement intermédiaire et la « vraie vérité » [00:16:52]
  • Le rôle du leadership produit [00:18:01]
  • Identité professionnelle (et passage aux rôles de leadership) [00:21:56]
  • Le rôle du manager pour aider les gens à adopter des comportements non par défaut [00:25:39]
  • État d'esprit, principes et tactiques (et rester bloqué sur les tactiques) [00:30:29]
  • Les bases/fondements d'une équipe performante [00:35:11]
  • Pourquoi les équipes avec les bases rencontrées produisent-elles des produits médiocres ? [00:37:31]
  • Intentionnalité et obstination (avec la compagnie que vous voulez être) [00:39:24]
  • Intelligence analytique et créative [00:44:14]
  • Niveau d'impact, niveau d'exécution et niveau optique [00:49:13]
  • Biais cognitifs et vocabulaire partagé [00:54:37]
  • Traiter les tableaux de bord comme un produit [01:01:51]
  • Calendriers remplis, réactivité, identité de soi et habitudes positives/négatives [01:08:20]
  • Améliorer la situation actuelle (et l'écart par rapport à la pensée actuelle) [01:14:24]
  • LNO : effet de levier, tâches neutres et frais généraux [01:18:10]
  • Conclusion [01:21:23]

Transcription de l'entrevue

Présentation [00:00:00]

John Cutler : Bonjour, Shreyas.

Shreyas Doshi : Bonjour, John.

John Cutler : Comment ça va ?

Shreyas Doshi : Plutôt bien. C'est bon d'être ici.

John Cutler : C'est donc la deuxième fois que nous nous parlons. Et je me souviens quand on s'est parlé pour la première fois, tu étais genre, devrais-je continuer à faire ce truc sur Twitter ? Ou que diriez-vous d'un livre? Je ne sais pas combien de mois c'était. Je veux dire, on a l'impression que la période de la pandémie écrase les choses en général, mais cela fait un certain temps plus tard et les choses ont absolument explosé pour vous.

Donc, j'aime juste noter la différence depuis notre dernière conversation. Alors je suppose, félicitations.

Shreyas Doshi : Merci. C'était marrant. Il suffit d'écrire quelques réflexions sur le produit et ainsi de suite. 280 caractères à la fois.

John Cutler : Pour ceux qui ne connaissent pas, Shreyas Doshi, je vais donner l'introduction la plus rapide. C'est un chef de produit. Ainsi, plus récemment chez Stripe, il a une expérience chez Twitter et Google chez Yahoo. Est un écrivain prolifique. Et je pense que c'est tout.

Je voulais percer le voile de l'invincibilité, commencer si c'est d'accord. Parce que votre écriture est si concise. Quelle est l'erreur avec laquelle vous avez lutté ces derniers mois.

"Ne croyez pas tout ce que j'écris…" [00:01:07]


Shreyas Doshi : Ouais. Donc, une chose que j'aime dire à propos de mon écriture, c'est tout d'abord, ne croyez pas tout ce que j'écris et ne prenez pas tout ce que j'écris et mettez-le simplement en œuvre parce que vous aimez mes écrits, ou parce que la chose a un tas de likes , donc ça doit être vrai. John, c'est quelque chose qu'au cours de l'année écoulée, j'ai vraiment commencé à écrire sur mes réflexions sur les produits, la stratégie, les organisations et ainsi de suite.

Avant d'appuyer sur le tweet ou, ou sur le bouton d'envoi, la plus grande inquiétude que j'ai tendance à avoir est oh, voici les six façons dont ce que je viens de dire pourrait être nuisible, s'il est sorti de son contexte ou s'il est mis en œuvre dans le mauvais contexte. C'est une préoccupation constante que j'ai à propos de ce que j'écris, et parfois, une partie de la précision et peut-être une partie de la puissance de l'écriture, le cas échéant, peut sembler plus vraie qu'elle ne l'est réellement dans votre situation particulière.

L'écriture est loin d'être parfaite. Parce qu'il manque probablement beaucoup de nuances, même lorsque j'essaie de le rendre plus clair ou quelque part dans la bande de roulement. Alors c'en est un. La deuxième chose est que je, je pense que j'ai tweeté ceci il y a quelques semaines que vous savez, j'ai tendance à parler beaucoup de choses anti-patrons à ne pas faire. Et la raison pour laquelle j'en parle et parfois les gens me disent, oh, cela a créé une grande clarté. J'ai vu cet anti-modèle au sein de mon équipe, au sein de mon entreprise, en moi-même, au sein de mon manager, quel qu'il soit. Et comment y êtes-vous arrivé ? Et donc, j'ai tweeté ce point, qui est, vous savez, bon nombre de ces anti-modèles sur lesquels j'écris, j'ai été cet anti-modèle. À droite?

Je l'ai vu en moi.

Parfois, c'est juste pour quelques heures peut-être que, oh, j'entre dans cet anti-modèle comme, oh, je l'ai senti, et je l'ai arrêté, et j'ai réussi à l'arrêter. Parfois, j'ai eu un certain anti-modèle sur lequel j'écris depuis plusieurs mois. Et il y en a d'autres que j'ai depuis de nombreuses années et des choses que je ne fais pas vraiment bien moi-même.

Et donc il y a cet aspect de juste, vous savez, une grande partie de ce que j'écris, j'en ai vu des parties en moi, ou tout en moi pendant différentes durées. Et, je pense que la seule différence est peut-être que vous savez, c'est le genre d'auto-observation, n'est-ce pas ? L'une des choses que j'aime aussi partager est que nous pouvons parler de tactiques et nous pouvons parler de cadres, de structures et de modèles pour la gestion des produits.

Se comprendre [00:04:03]

Mais du côté soft, je pense qu'une chose très importante pour nous tous en tant que chefs de produit à réaliser, et pour nous améliorer en tant que chefs de produit, est de nous comprendre. Vous savez, le hub dont ils parlent, oh, comprenez l'utilisateur, comprenez le client, comprenez le marché, comprenez le concurrent.

Je suis d'accord avec tout cela. Mais comprenez-vous aussi. Commencez par vous comprendre. Maintenant, vous n'allez pas vous comprendre tout de suite. Mais si vous commencez par vous comprendre, vous constaterez que certaines de ces autres compréhensions de l'utilisateur et ainsi de suite deviennent plus faciles.

Il y a beaucoup, beaucoup de choses pour lesquelles je ne suis pas très doué. Tout récemment, je pense que j'étais, encore une fois, j'avais une conversation sur Twitter et quelqu'un m'a demandé oh Shreyas, comment doit-on bien se débrouiller au sein d'une organisation ?

J'ai dit, écoutez, je n'ai pas de réponse à cela, parce que j'ai été très mauvais pour gérer pendant de très nombreuses années. Andrew Yu m'avait envoyé un livre sur la gestion. Et donc j'ai dit, Hé, Andrew, tu devrais probablement répondre à ce tweet au lieu que je le fasse. Donc c'est juste un exemple d'une chose que vous savez, je n'ai pas tout à fait déchiffrée.

Devenir un meilleur auditeur [00:05:13]

John Cutler: Une chose que j'apprécie vraiment, c'est qu'à travers vos fils, vous êtes vulnérable et humble. Je me souviens d'un tweet que j'ai beaucoup aimé, où vous avez observé que votre jeune vous écoutait mieux et que vous avez glissé dans une période où vous n'écoutiez pas aussi bien.

Et cela a été extrêmement percutant pour moi. Parce que je pensais, j'ai traversé ces phases dans ma vie, et ce n'est pas une situation statique. Vous apprenez toujours. Je me demandais spécifiquement avec cette situation, à quoi ressemblait cette réalisation de soi? Vous savez, quand vous vous en êtes rendu compte et comment avez-vous compris cela ? Et puis quoi, quelles mesures avez-vous prises? Et vous avez commencé à le détailler dans le fil, mais ça m'intéresserait vraiment que vous l'expliquiez et que vous l'entendiez en personne.

Shreyas Doshi : Donc, j'avais l'habitude d'être un excellent auditeur quand j'étais jeune enfant. Plus tôt dans mon enfance, j'avais aussi une mémoire assez forte. Ce n'est plus le cas. J'oublie des choses tout le temps maintenant. Mais j'ai commencé comme ça. Et tant de choses à l'école, par exemple, ont été très tôt, faciles pour moi parce que j'écoutais juste ce que disait le professeur.

Et puis j'ai pu le retenir très longtemps. Cela a changé dans mon adolescence et au début de la vingtaine. Tu sais, je ne sais pas pourquoi. Ça a dû être exactement ce que tu as vécu dans ta jeunesse. Là où vous venez, à un moment donné, je me déconnecterais complètement à l'université.

Et je n'avais aucune idée, j'étais assis là physiquement, mais je n'avais aucune idée de ce qui se disait. Et cela a continué. C'est devenu ce modèle. Alors que lorsque j'ai commencé ma carrière en tant qu'ingénieur logiciel, ce n'était plus ce degré d'apathie à propos de ce qui se dit lors d'une réunion ou de ce que dit une autre personne. Mais je viens de perdre cette compétence, car je ne l'ai pas utilisée pendant cinq ou six ans à ce moment-là.

John Cutler : Y a-t-il eu un moment où vous vous êtes dit, attendez, j'ai perdu ça ? Comme, comment avez-vous, comment cela vous est-il apparu, ou était-ce comme une combustion lente. Ou peut-être était-ce un manager ou quelqu'un qui a partagé la nouvelle avec vous ? Comment, comment t'en es-tu rendu compte ?

Shreyas Doshi : Vous savez, John, je m'en suis rendu compte très tard. Donc je veux dire que j'étais dans l'état d'être un bon auditeur pendant environ 12 ans au début de ma carrière. Cela signifiait, bien sûr, que j'écoutais. Je traitais, et cetera. Mais j'étais dans ce mode du classique formant mes propres pensées. Formant ma réponse et préparant ma réponse. Ou, ne pas vraiment écouter ce qui a été dit, mais entendre ce que je voulais entendre.

J'ai donc été dans cette phase pendant au moins 12 ans dans ma carrière. À un moment donné, la principale réalisation pour moi a été que la clé pour comprendre l'autre personne va être de s'assurer qu'elle sache que je la comprends. À droite? J'ai donc commencé par cette première étape. Et c'était un genre très tactique, il n'était basé sur aucun principe. C'était une tactique comme d'accord.

John Cutler : Vous avez dû réfléchir dans votre tête que…

Shreyas Doshi : Oui. Pour être un bon manager, je dois m'assurer que l'autre personne comprend que je comprends ce qu'elle dit. C'est là que j'ai commencé. Et puis j'ai fait ça, et je dirais que ça m'a peut-être fait passer d'un quatre sur 10 à un six sur 10. Ce qui est bien. C'est une amélioration.

Mais alors, la prochaine grande réalisation, et le changement quantique que j'ai pu faire, c'est quand j'ai réalisé que lorsque vous écoutez juste ce qui se dit, et que vous êtes pleinement présent, les réponses se forment d'elles-mêmes. À droite? Je n'ai donc pas besoin de réfléchir pendant que vous parlez. Ou je n'ai même pas besoin de penser à comment je vais résumer ce que vous dites, juste pour m'assurer que je vous ai bien compris.

Je veux juste être présent à cent pour cent. Et je veux être curieux. C'était le changement. Était-ce une véritable curiosité et le développement de cette véritable curiosité, ainsi que la capacité de pouvoir être présent et de pouvoir en quelque sorte regarder mes parties, et de me ramener exactement aux mots qui étaient prononcés.

Puis quand j'ai fait ça, quand je l'ai approché à partir de cette curiosité et de cette présence authentiques, c'est là que j'ai vu, oh, wow, quand je fais ça, deux choses se produisent. La première est que je [00:10:00] trouve juste cette autre personne comme étant beaucoup plus intéressée par ce qu'elle dit. Et deuxièmement, la qualité de ma réponse est tellement meilleure.

Alors qu'auparavant, souvent, la réponse avait tendance à être, d'accord, je vous ai entendu, et compte tenu de mon rôle, c'est souvent, comme si je vous avais entendu, et voici mon conseil. Ou voici ma réponse. La réponse est devenue une question plutôt qu'une déclaration.

C'est ainsi qu'ils ont compris que je les comprenais vraiment. Et je faisais une véritable tentative pour mieux les comprendre. Ils m'ont dit quelque chose. J'étais vraiment présent. J'étais vraiment curieux. Et à cause de cela, je leur ai posé une question que je n'aurais pas posée autrement. Et cette question nous a permis de mieux comprendre la situation. Au fur et à mesure que j'ai commencé à faire cela, j'ai réalisé de plus en plus que, oh, c'est vraiment efficace. Poser des questions aux gens est tellement plus efficace, si ce sont les bonnes questions. Et, s'ils sont basés sur une compréhension profonde, ou aussi profonde que possible, de ce que l'autre personne essaie de dire à propos de la situation.

John Cutler : On dirait que vous avez développé quelque chose, au fil du temps, et que vous êtes devenu bien meilleur dans ce domaine. Par exemple, vous pouvez poser de meilleures questions en tête-à-tête, et cetera.

Shreyas Doshi : Bien sûr. Et, vous savez, j'ai été responsable des PM dans chacune des quatre entreprises dans lesquelles j'ai été PM. Trois de ces quatre entreprises, j'ai rejoint en tant que contributeur individuel, y compris mon employeur le plus récent, Stripe. Je me suis joint en tant que contributeur individuel, puis j'ai commencé à gérer des personnes.

Transition IC vers gestionnaire [00:11:49]


J'ai donc traversé cette transition d'IC ​​à manager. Beaucoup de gens passent par là une ou peut-être deux fois. Euh, et puis ils restent managers. Je l'ai parcouru plusieurs fois. Et ça ne me dérange pas d'être à IC là où ça a du sens. Donc ça a bien marché pour moi.

Chaque fois, cela a été différent. Parce que j'ai grandi en tant que manager. Je pense que lorsque j'ai commencé à gérer, cela faisait neuf mois que j'étais chef de produit. On m'a dit, oh, nous aimons ce que vous faites. Pourquoi ne dirigez-vous pas une petite équipe ? Avec le recul, je ne m'en étais pas rendu compte à l'époque, mais avec le recul, j'avais l'impression d'être un terrible, terrible gestionnaire de PM. Cela remonte à, vous savez, beaucoup de ces anti-modèles. J'ai été ça. Parce que je me souviens très tôt, j'étais tellement sûr que j'avais la réponse.

Et donc c'en était un. Et deuxièmement, je pensais que mon travail consistait à fournir la réponse. Si je rencontrais une résistance au sein de mon équipe pour accepter ou prendre cette réponse, alors je sentais que mon travail consistait à les convaincre par des moyens très analytiques, pourquoi c'est la bonne réponse, n'est-ce pas ?

J'étais juste horrible en tant que manager à l'époque. Et bien sûr, maintenant, j'adopte une approche très différente. Cela a beaucoup à voir avec juste, vous savez, cultiver cette véritable curiosité, je suppose, la maturité générale de la vie également. Mais aussi être capable de regarder mes pensées, et aussi de comprendre ce qu'un responsable PM doit faire.

Quel est leur travail et quel est leur rôle ? J'ai une meilleure compréhension maintenant, alors qu'auparavant on me demandait juste de commencer à gérer les gens, comme si je n'avais aucune idée de ce que j'étais réellement censé faire.

John Cutler : Quand vous pensez aux entreprises dans lesquelles vous avez été impliqué, je pense qu'une chose que j'ai remarquée à propos de certaines cultures d'entreprise, c'est qu'elles traitent très différemment les discussions sur l'incertitude. Dans certains, vous savez, il ne faut jamais, jamais mentionner l'incertitude à moins que vous n'ayez un plan absolu pour la réduire.

Et dans d'autres cultures, ils semblent beaucoup plus ouverts à un leader pour dire, je ne sais pas pour le moment. Alors, quel est votre plan de match pour cela? Comme vous avez traversé ces organisations, mais comment avez-vous compris la culture de la vulnérabilité pour les dirigeants ?

Parce que c'est évidemment important, mais cela se manifeste différemment selon les cultures.

Discuter de l'incertitude et de la culture organisationnelle [00:14:10]

Shreyas Doshi : J'aime que vous mentionniez la culture ici, John, parce que tout revient à cela. Il y a des cultures où. Oui, tu es censé être sûr. Et si vous n'êtes pas sûr, et si vous n'avez pas toute la justification, la justification analytique, vous êtes jugé incompétent.

Il y a d'autres cultures, où une certaine incertitude est considérée comme faisant partie de ce que nous faisons, c'est-à-dire, oui, nous ne saurons pas comment cela va se passer et c'est OK.

Cela ne signifie pas que la deuxième catégorie de culture est moins rigoureuse. Je dirais que c'est plus rigoureux. Parce que ce n'est pas basé sur des illusions sur des résultats mathématiques stricts basés sur certaines entrées. Il comprend le caractère aléatoire impliqué lorsque vous prenez un produit [00:15:00] et que vous le présentez au monde extérieur. Il comprend d'autres hasards, le système lui-même sur le marché et ainsi de suite.

Cela fonctionne dans ce genre de compréhension du monde réel de ces choses. Par rapport à certains idéalisés, vous savez, oh ouais, nous devrions être en mesure de le prouver sur une approche de type tableur. Stripe en est un bon exemple. Où, vous savez, nous aurions des critiques de produits où nos fondateurs, ou nos dirigeants, diraient, oui, il n'y a aucun moyen pour nous d'en être sûrs.

Laissez-nous comprendre ce que sont les commentaires des clients. Comprenons quel est le contexte du marché. Et sur cette base, nous prendrons la meilleure décision dans les circonstances. Mais, vous savez, nous n'avons pas à être certains que cela fonctionnera

John Cutler : D' accord. C'est une modélisation incroyable, non ? Comme d'un point de vue de leader. Et ça veut dire que ça va loin. Si un chef dit ça, c'est sûr.

Shreyas Doshi : Ouais. Ouais. Et, vous savez, il y a aussi la porte à sens unique classique, la porte à double sens, que j'ai vraiment vue pratiquée chez Stripe. C'est une décision que nous pouvons annuler. À droite?

Alors faisons-le. C'est bon. Si nous nous trompons, nous l'annulerons tout simplement. Le coût de son annulation ne sera pas substantiel. Et puis il y a peut-être d'autres décisions qui seront plus difficiles à annuler, ou que nous ne pouvons pas annuler. Passons en fait notre temps à bien faire les choses. Encore une fois, tout ce que je dis ici, John, semble évident, comme oui, bien sûr, vous devriez le faire dans la plupart des cas.

Comme, bien sûr, vous devriez le faire. La question est pourquoi cela ne se produit-il pas? Pourquoi la plupart des organisations sont-elles très imparfaites dans ce sens ? Et, je pense, vous et moi avons discuté de ce sujet du théâtre de certitude. Et, et je pense que cela a beaucoup à voir avec la sécurité psychologique que la culture crée pour les cadres intermédiaires en particulier.

L'encadrement intermédiaire et la « vraie vérité » [00:16:52]

La façon dont je vois les cadres intermédiaires, c'est qu'ils sont la façon dont l'organisation s'assure que vous êtes en mesure d'accéder à la vraie vérité. Il y a la vérité sur le terrain et, vous savez, les gens qui travaillent très directement sur cette vérité. Et puis, quand ils verront cette vérité, ils la transmettront aux cadres intermédiaires. Et puis la gestion intermédiaire agit comme ce mandataire, juste entre la vérité que vous voyez sur le terrain. Et puis la vérité que les dirigeants d'entreprise voient à une échelle macro.

Je pense donc qu'il est vraiment important que les cadres intermédiaires se sentent libres d'exprimer les vérités qu'ils voient des deux côtés. Sans avoir à craindre que leur travail soit compromis, ou que leur position soit compromise, ou que leur réussite professionnelle soit compromise.

Et s'ils peuvent le faire, c'est, je pense, la clé pour débloquer une meilleure sorte de flux de vérité dans les deux sens au sein d'une organisation.

John Cutler : La gestion intermédiaire n'est pas qu'un seul niveau. Dans de nombreux cas, il s'agit de plusieurs couches. Alors, comment faites-vous pour que la vérité circule dans les deux sens à travers deux ou trois couches de, de cela ?

Le rôle du leadership produit [00:18:01]

Shreyas Doshi : La première observation est que nous ne parlons pas vraiment de ce qu'est le travail, et quel est le rôle d'un chef de produit. À droite?

Mon observation est que la plupart de ces chefs de produit ont, vous savez, une expérience formidable, d'excellents CV. Si vous leur demandez, quel est votre rôle ? Genre, quel est votre vrai rôle ? Ils vont lutter. Et je ne les blâme pas parce que, vous savez, personne ne leur a appris quel est leur rôle. Alors ils ont juste commencé à faire des choses et ensuite quoi qu'ils fassent, si ça marchait, s'ils obtenaient une validation externe, ils en faisaient plus. Et puis ils ont supprimé les choses pour lesquelles ils n'avaient pas obtenu de validation.

Donc, d'une manière ou d'une autre, nous sommes arrivés à un certain style, ou à une certaine approche, ou à une définition de rôle implicite. C'est maintenant si profondément ancré dans leurs habitudes qu'ils ne peuvent pas tout à fait le décrire. Comme, d'accord, mon rôle est X, Y et Z.

Et je pense que c'est tellement important. Une fois que vous avez compris le rôle, ce que vous devez faire devient clair, n'est-ce pas ? Ce que vous devez faire, c'est permettre le succès du produit à travers les autres, n'est-ce pas ? C'est effectivement ce que vous devez faire quelque part en tant que chef de produit dans l'encadrement intermédiaire.

Et afin de permettre en quelque sorte le succès de ce produit à travers d'autres, et j'en parle en termes de création d'équipes autogérées, n'est-ce pas ?. Il est donc vital de créer des équipes autogérées. Idéalement, en tant que chef de produit, vous savez, vous n'êtes pas seulement comme éteindre des incendies et devoir vous présenter à huit avis parce que vous devez être là, et vous devez tout vérifier, et rien ne se passe sans que vous soyez là.

Et je sais que c'est la réalité de nombreux chefs de produit, notre travail au quotidien, c'est pourquoi c'est souvent très stressant. Et je coache assez régulièrement de nombreux chefs de produits de ce type, et il est [00:20:00] surprenant pour eux qu'il ne soit pas nécessaire qu'il en soit ainsi. Il n'est pas nécessaire que ce soit la façon dont vous faites, vous savez, littéralement 40 réunions ou 50 réunions par semaine.

Il y a cette blague que j'ai entendue plusieurs fois. C'est comme, oh, alors vous êtes un chef de produit, donc vous ne serez jamais à votre bureau, n'est-ce pas ? Comme si vous alliez toujours être dans des réunions. Ha ha. Nous acceptons cela comme une réalité. Je rejette absolument cette prémisse. En fait, en tant que chef de produit, vous devriez passer beaucoup de temps sur votre bureau. Et si vous ne le faites pas, cela signifie que vous ne remplissez pas le deuxième aspect de votre rôle, qui est de créer des équipes autogérées. À droite?

Je pense donc que cela revient à une sorte de compréhension du rôle. Et une fois que vous aurez compris le rôle, vos actions seront très différentes en termes de façon dont vous déléguez, comment vous dites non seulement, eh bien, je n'aime pas cette approche de ce flux que vous me montrez, mais j'aime quelque chose d'autre, mais dites plutôt, regardez ici, voici comment je pense à cela.

Voici comment je pense aux objectifs de l'utilisateur. Voici comment je pense aux objectifs de conversion que nous avons. Et puis voici peut-être quelques principes à considérer. Voici peut-être quelques mesures à rechercher pour déterminer quelle est la bonne réponse, n'est-ce pas ? Comme c'est la conversation que vous devez avoir en tant que chef de produit avec votre équipe, parce que c'est ainsi que vous créez une équipe autogérée par rapport à oh, Bob, Bob aime juste un flux de page unique, n'est-ce pas ? J'aime ou des étapes d'une seule page. Et comme ça, c'est juste une bizarrerie de Bob. Et donc assurez-vous simplement que c'est le chef de produit qui dit au designer, assurez-vous simplement de le faire, n'est-ce pas ? Comme, mais le pourquoi de cela manque. Il s'agit plutôt de, oh, si vous voulez réussir l'examen de Bob, vous devrez le faire. à droite. Ce qui n'a pas de sens parce que maintenant vous avez créé un peu le contraire d'une équipe autogérée.

Identité professionnelle (et passage aux rôles de leadership) [00:21:56]

John Cutler : Une chose qui me vient aussi à l'esprit, c'est que souvent les chefs de produit semblent apprécier cette nature nébuleuse de leur rôle, à commencer même par l'IC PM. Ils s'identifient presque comme le métamorphe. Genre de se pousser dans tout ce qui doit être fait.

Et je peux imaginer que cette personne, quand elle devient réalisatrice, monte en grade. Peut-être que parfois ils ne peuvent pas lâcher prise. C'est peut-être une chose qui conduit à une incapacité à clarifier leur rôle.

Shreyas Doshi : Oh, vous savez, John, ce que vous venez de dire résonne si fortement. Je veux partager deux choses en réponse à cela. Le premier, c'est que vous avez cet exemple classique. Et encore une fois, c'était moi il y a de nombreuses années. C'était moi il y a 12, 13 ans. Chef de produit apparemment compétent, quelqu'un qui est vraiment doué pour le travail de base de la gestion de produit.

À qui a-t-on dit, d'accord, nous voulons que vous gériez les PM. Bon, maintenant, ce qui se passe dans cette situation est vraiment intéressant. Et je pense que si cela arrive à beaucoup, beaucoup de PM compétents. Ce qui les rend alors des chefs de produit un peu moins compétents, du moins le premier ou le second…

John Cutler : Êtes-vous en train de dire que les PM deviennent de moins en moins compétents à mesure qu'ils progressent dans une organisation ?

Shreyas Doshi : Eh bien, les exigences, la barre change. À droite? Ainsi, par exemple, dans mon cas, j'étais encore en train de développer et de développer mes compétences de base en gestion de produits. Ce n'était pas entièrement construit, mais on m'a demandé de gérer, ce qui est bien, cela se produit également dans de nombreuses autres fonctions. Mais le défi, c'est que je n'étais pas là mentalement non plus, n'est-ce pas ?

Comme si je savais que j'avais ces lacunes, et quelque part en moi, j'avais toujours cette volonté de prouver que je suis un très bon chef de produit. Pas un manager de chefs de produit, mais un très bon chef de produit. Et la façon dont cela s'est manifesté avec mon équipe est, vous savez, quelque chose se produit et je me dis, oh, ce n'est clairement pas la bonne réponse. C'est ainsi que nous devons penser cela. Par exemple, surveillez mon langage. À droite? Comme ce sont les mots que j'utilisais.

Et ce que je faisais vraiment, maintenant je le comprends, je ne le comprenais pas à l'époque. Ce que je faisais vraiment, c'était juste essayer de me prouver que je l'avais toujours. Et essayer de prouver et de montrer aux autres, tout comme à quel point je suis formidable dans le travail de contributeur individuel d'IC. Ah, et je vois cela avec les chefs de produit, en particulier au cours de leurs trois ou quatre premières années, tout le temps lorsqu'ils se lancent dans la gestion des chefs de produit. Ils essaient toujours de jouer le rôle de gestion de produit, le rôle de base du CI, plutôt que le rôle de gestionnaire.

Et puis cela crée toutes sortes de défis pour eux-mêmes. Parce que, vous savez, lorsque vous adoptez ce genre d'approche IC, vous allez être le manager qui dit, [00:25:00] oh oui, je dois aller à cette réunion. Pouvez-vous s'il vous plaît m'inviter. Parce que vous avez besoin de ce contexte sur le terrain pour pouvoir vous faire une opinion sur la stratégie produit ou la direction produit, n'est-ce pas ?

Versus, développer la compétence pour comprendre cela à travers votre peuple. Et puis ça agace la personne de votre équipe parce que c'est comme, pourquoi mon patron se présente à cette réunion ? Cela n'a aucun sens. Et oh, mon patron est un micromanager. Ou regardez, oh, parce que mon patron se présente à cette réunion, je dois maintenant jouer à cette réunion au lieu d'être simplement vulnérable, moi-même, en posant des questions légitimes et authentiques et ainsi de suite.

Le rôle du manager pour aider les gens à adopter des comportements non par défaut [00:25:39]

Je vais vous dire une chose liée à ce sujet dont nous discutons qui me vient à l'esprit, c'est de voir le rôle du manager, en particulier dans le contexte de la gestion des produits, de voir le rôle du manager, le rôle de directeur, le rôle de VP, le rôle de CPO comme être d'aider les gens à comprendre quand ils devraient adopter leurs comportements non par défaut.

Prenons un exemple précis. Vous trouverez, vous savez, quelque part dans un article de blog, ou peut-être un fil Twitter, ce genre de, oh, voici ce dont un chef de produit a besoin pour…

John Cutler: Soit dit en passant, nous aurions pu en être conjointement responsables. Je pense donc que nous pouvons,

Shreyas Doshi : Absolument. C'est le truc où je me dis, oh, je suis nerveux d'appuyer sur envoyer…

John Cutler : … J'ai des cauchemars à ce sujet, alors je vais tenir mon…

Shreyas Doshi : Bien sûr ! Prenons donc un article de blog hypothétique sur ce que les chefs de produit sont censés faire. Et c'est comme si un chef de produit était là pour son équipe. Le chef de produit débloque l'équipe. Le chef de produit vérifie avec l'équipe ce dont l'équipe a besoin et fournit ce dont elle a besoin pour qu'elle puisse être efficace.

Ils peuvent être efficaces. Un chef de produit s'assure qu'il effectue des vérifications régulières avec des ingénieurs individuels pour s'assurer qu'ils obtiennent ce dont ils ont besoin bla, bla, bla. À droite. Vous pouvez donc imaginer ce genre d'article de blog hypothétique.

Et dire que je suis un chef de produit, ou un nouveau chef de produit, et dire, d'accord, tout cela a du sens. Et je vais commencer à faire ça. Et, devinez ce qui se passe ? Comme si j'avais commencé à le faire, et ça marche très bien. Les gens disent, oh, vous savez, Alice a rejoint notre équipe en tant que PM. Et ça a été incroyable. C'est une différence jour et nuit. Je ne peux pas croire que nous fonctionnions sans PM, et c'est incroyable, plus de PM, vous savez ?

Assurons-nous de reconnaître Alice pour nos contributions en tant que chef de produit, et cetera, et cetera. À droite. D'accord. Fonctionne très bien. Alors maintenant que se passe-t-il ? Si je suis le chef de produit, j'en fais mon comportement par défaut. Parce que c'est ma première année de travail. Je ne connais rien à la gestion des produits dans divers contextes différents.

Je suppose que je reçois la validation de ces actions. Je dois donc faire le même nombre ou plus de ces actions, n'est-ce pas ? Now, transport me to a different team. Or a different company. Okay. Now, in this company, or on this team, let's just say on this team, well the engineers are very independent. They are already talking to customers directly, right?

They're talking to sales directly to understand requirements. They are talking to marketing. You know, the designers are doing end to end research and validation as well as again, kind of very customer centric. And it's generally a very high agency team, right?

Like again, the tech lead, or the lead designer, isn't afraid to go to the VP or the CEO and ask questions or ask for what they need and whatnot. À droite? You can bring in this product manager, who's performing these defaults, in this situation, what happens, right?

Same product manager, different teams. And the feedback is, oh, you know, we think Alice needs to create more room for ideas. We think Alice can sometimes create an unnecessary obstacle for us. We think that is a lot more process. We think there are many more check-ins than there need to be. We don't have to provide status on a daily basis for what we are doing, et cetera, et cetera. À droite? Same product managers, same actions, different contexts. Doesn't work. So with this now let's get back to the thing I've been mulling over recently, which is where is the failure here?

I don't think the failure is at the level of the PM. It's not Alice's failure. It's the manager's failure, right? It's the manager's responsibility to help a PM understand the context within which they are [00:30:00] operating and then nudge them towards non-default behaviors.

John Cutler: It's funny you had that conversation. I think there was a thread with Dee Hawk where he said, I talk about principles and these deep things, and you actually made the point where you said most people just want to get ahead.

You know, so talking about principles is a little tougher. I'm paraphrasing. I think I remember this in the back of my mind. But I thought what was interesting — that point — is it's also the toughest thing, right?

Mindset, principles, and tactics (and getting stuck on tactics) [00:30:29]

Shreyas Doshi: So, so a couple of thoughts there. One is it does depend on where one is at, right? There are three things that one needs to understand and use in order to get really good at something.

There's mindset, there's principles, and tactics, right?

People often will start with tactics. Which is here is a recipe for how to run this meeting, right? Here's the template for a product review. Here's a template for a product strategy doc, or what have you, right. Tactics are amazing. You need tactics to figure out the basics of a role and to be productive in that role and to learn by doing right. So tactics are really, really important.

What happens though, is for many people, they get stuck at tactics for the majority, if not the entirety, of their career. And that's where there is a problem. À droite? Which is once you have reached a certain degree of proficiency, you are not going to be able to, you know, seek the 37th tactic for doing this thing in order to actually be effective. À droite. And, and so what you need at that point, is a better understanding of the principles. Because with the principles, what you will do is you'll know which tactic to employ. But even more amazingly, once you start understanding these principles, you can create your own tactics, right?

And then mindset is the most important thing. All of us know we need to do certain things. I know I need to write that PRD, why am I not writing that PRD? And instead, spending my time on Slack, and replying to email, and convincing myself that I'm being productive by doing that.

And there is a very good reason why I'm not writing that PRD. I need to understand myself. I need to understand what is really going on. What I'm really fearful of when I'm avoiding writing that PRD that I really should be writing. So there's much more to mindset than that, but the point is to achieve the highest degree of competence in a certain field — and particularly, I think, I can only speak for product management really to achieve the highest degree of competence in product management — you do need to understand each of these three extremely well.

Depending on the context, some of this is just not possible. Look, a lot of what I talk about the implicit background there is it's, we're talking about you know, like Marty Cagan calls it empowered teams, right? Where people are given the right tools, and the freedom to arrive at the right answer. Without taking tremendous personal risk in order to do so. I have been fortunate to have largely worked at organizations where the teams have just been empowered by default. My perspective comes from that. I frankly don't know what it's like, and what success is like, in environments where teams are not empowered, where individuals are not empowered. A lot of what I might say in that context can probably be boiled down to, grow as much as you can in the environment, such that now you will have the optionality to move to an empowered environment where you can really exercise your skill and achieve, hopefully greater potential.

But even as I say that I'm in two minds, right? Like, I feel like, okay, it makes sense to try to grow as much as one can, based on the cards one is dealt. À droite? It seems to make sense to do that. My own personal experience. I was very early in my career. I was in these highly disempowered teams. That's sort of what I tried to do, but again, I'm a sample size of one. What works for me doesn't necessarily work [00:35:00] for everybody. So that part of me says, okay, yeah, maybe this should work. But the other part I'm not quite sure about is just like is it possible in every environment where teams are disempowered? .

The basics/foundations for a high-performance team [00:35:11]

There are some basics that you need to have in order to have a chance of being a high-performance team or a successful team. Without those basics, yeah, with survivorship bias, you can find one team that managed to, against all odds, to succeed without those basics. But we can't really bank on that. À droite. Because we have one life, we have, you know, we are single threaded. We can't run a hundred simulations and then just pick the winning simulation. À droite. Or even like thread, like do three jobs on a given day. À droite. And see which one, see which one worked out better. And just like, uh….

John Cutler: A multivariate job experiment. That's really

Shreyas Doshi: So, so we can't do that. So, you know, any kind of like, oh, there's all these problems and they, yet we succeeded. So learn from us. À droite. Like there's very little to learn from that in my opinion. Because you're so single-threaded as a team, as a person, as a company it makes sense to just make bets that have a high expected value.

So let's assume that the basics are met. And what are some examples of basics that you have the right people in the right roles as an example, Right. It doesn't have to be the world's best people doing whatever, but at least there is some match to what the job is, and the people, who are supposed to do the job, as one thing.

You might even put a certain bar of empowerment. It doesn't necessarily have to be the highest empowered team ever. Because like that could have its own issues. But like a certain bar of empowerment. So anyway, you can make up some reasonable basics around, okay, any team or any situation needs to satisfy these basics, for it to have a shot at creating something that makes an impact, creating something that's remarkable.

Okay. Now that these basics are covered, what's next? What do we need to do to increase the probability that we can meet our potential as a team? You know, as a thinker I have been thinking a little bit about a lot of my writing and what the general theme is. And one of the themes that I've been able to extract after the fact, is that really I'm trying to answer the following question in many different ways.

Why do teams with the basics met produce poor products? [00:37:31]

And the question is why do smart teams with sufficient resources– by resources I mean, money, all of that, right, not number of people necessarily– so why do smart teams with sufficient resources still produce mediocre or poor products? The current environment, again, sort of certainly you know, with startups and high growth tech companies, is that we all like to think we have smart teams. In this current funding environment, we do have somewhat sufficient resources in most cases, perhaps too many resources in some cases, and yet, many teams are not as successful as they ought to be.

And so why does that happen? À droite? I don't think I've answered that question just for myself. First trying to do this for myself, and then for everybody else. But I think the answer lies in a lot of different things that we just talked about. Around, oh, you know, one of the aspects of success is understanding the truth.

A lot of this goes back to things like decision-making, how do you collect inputs, how do you determine outputs? How do you get to those outputs? And then what are the right outcomes for us to achieve? Are we being sufficiently both logical and creative about how we get there?

I don't have an answer to sort of like the overall question of what distinguishes, you know, either poorly performing teams or high-performing teams and how are they different. I like to think about it as like, you know, this concept of assuming the basics are met, what needs to happen in order to maximize chances of success? And that's where I think context also plays a pretty large role.

Intentionality and stubbornness (with the company you want to be) [00:39:24]


John Cutler: What I've observed, at least in some of the companies that I admire the most is that someone is around who is just really stubborn about something, you know. They are stubborn about maybe engineering quality, or they're stubborn about connecting with customers. So anyway, that's, I'm offering that up as maybe an area that I'm looking into. That's what I've been thinking a lot about lately is stubbornness. We should connect our threads of research on this because I think it'd be interesting.

Shreyas Doshi: Yeah. I want to take that and do a live mashup of what you're talking about, uh, with this other idea that I [00:40:00] often bring up in conversations with startups, particularly as they're kind of starting to think about scaling that product development efforts. As they're thinking of adding product management. One of the questions I will often ask is what type of company do you want to create? Concretely. This is in the context of, you know, oh, I'm looking to scale my engineering team, looking to scale my product management. And I ask people to be quite intentional about what type of company you want to…

John Cutler: Because it's easy to give non-answers to that. I've heard a lot of non answers to that question.

Shreyas Doshi: Yes. And as it pertains to product work, right? Like what is going to be your focus? So that's one way to look at it. Do you want to be a customer focused company? Do you want to be an infrastructure focused company? Do you want to be a growth focused company? Do you want to be a product focus company?

Do you want to be a sales focused company…

John Cutler: I want it all…

Shreyas Doshi: And exactly, right!

Like, so that's what people say quite a bit. But then they start getting it, which is like, oh Yeah, Okay. I like, I need to be like, as a founder, my company is my product. And so I need to be quite opinionated or stubborn– so, this is where I'm connecting to your stubbornness– about what I want to create.

Because what happens is you, you can't have it all. And if you're not intentional about it, you are focused on something it's just, you don't know what it is and then there's confusion, right. Like for yourself and for others. And so you take examples, right? It takes time to go through this conversation because, you know, it's, it's an odd

John Cutler: It starts out very high level too. It's like…

Shreyas Doshi: Right, it's, it's very high level…

John Cutler : … et ensuite vous devez vous éloigner et prendre un café et comme, attendez, nous devons descendre d'un autre niveau.

Shreyas Doshi : D'accord. À droite. Et, et comme, donc ce que j'ai observé, c'est que 10 minutes en 20 minutes en 30 minutes, il y a généralement un moment d'ampoule pour le fondateur. Parce que le fondateur est généralement aussi très proche de ce qu'il veut faire. Donc, encore une fois, c'est une de ces choses où poser la question est la principale valeur ajoutée, pas nécessairement la réponse.

Mais si vous prenez des exemples, cela devient plus clair, qui est Google, par exemple, et certainement pendant la période où j'étais là-bas, c'était il y a environ 10, 10 ans, était une entreprise très axée sur l'infrastructure. C'était leur objectif implicite. Quand j'ai parlé à un ingénieur et que j'ai dit, c'est ce dont l'utilisateur a besoin, comment pourrions-nous procéder pour le construire ? La réponse serait, oh, c'est très intéressant. C'est un problème incroyable. Je vais devoir construire cette infrastructure backend. Il va me falloir six mois pour construire cette infrastructure backend. Et puis vous aurez cette fonctionnalité. Et en tant que produit, bien sûr, j'irais attendre, mais cela semble très long à aimer, ce n'est pas une fonctionnalité massive.

Comme, non, non, non. C'est comme ça qu'on fait les choses, non ? Comme, nous avons besoin d'avoir l'infrastructure. Et encore une fois, il n'y a pas de mauvais ou de bon choix. J'aime aussi le souligner. À droite. C'est comme, vous savez, vous avez Facebook, qui est très, au moins certainement me semble de l'extérieur et des gens à qui j'ai parlé, c'est une entreprise très axée sur les métriques.

Ils prennent des décisions basées sur ce qui déplace les métriques en grande partie. Et c'est pourquoi Google et Facebook fonctionnent très différemment. En interne, ils fonctionnent très différemment en raison de cette orientation.

Le choix facile à faire est oh, nous voulons être axés sur le client. Et puis je dois rappeler aux gens que, d'accord, si vous, si vous dites que vous voulez être une entreprise axée sur le client, mais que vous vendez des logiciels d'entreprise, sachez qu'avec le temps, ce que vous deviendrez réellement est un entreprise axée sur la vente. Et encore une fois, il existe des exemples d'entreprises extrêmement prospères qui se concentrent sur les ventes.

Donc, je ne dis pas que c'est nécessairement un mauvais choix. Mais le simple fait d'être intentionnel à ce sujet et de le rattacher à votre point d'entêtement, c'est une façon de voir les choses, n'est-ce pas ? C'est comme ça, c'est comme ça qu'on fait les choses. Je sais que cela semble plus négatif que cela ne devrait l'être, ou cela fonctionne pour nous, n'est-ce pas ? Cela fonctionne avec la culture que nous avons. Cela fonctionne avec les personnes et les compétences que nous avons embauchées, etc. Et cela peut être assez puissant, surtout si vous le faites intentionnellement.

Intelligence analytique et créative [00:44:14]


John Cutler : À quelques reprises dans notre conversation, vous avez mentionné ce mot analytique. Et puis vous avez parlé de l'alternative à cela, peut-être une intelligence créative. Pourriez-vous approfondir cela un peu?

Et plus précisément, je pense à mon travail quotidien, où nous pensons à la mesure. Et une chose que j'ai observée, c'est qu'il y a une énorme différence entre utiliser la mesure pour contrôler les gens, ou contrôler le récit, ou obtenir la réponse parfaite, et utiliser la mesure pour apprendre. Ils se sentent très, très différents.

Quelle est la différence entre l'intelligence analytique et l'intelligence créative dans votre esprit ?

Shreyas Doshi : A la base, ils s'appuient les uns sur les autres.

Cependant, ce n'est pas ainsi que la plupart de l'industrie le voit. Et je pense que les pratiques de diverses entreprises, y compris les entreprises très prospères [00:45:00], ont souvent tendance à considérer l'une comme meilleure que l'autre. Et c'est généralement - et encore une fois, mon contexte est en grande partie, vous savez, des entreprises basées dans la vallée ou des entreprises similaires à la vallée, peu importe où elles se trouvent géographiquement - c'est que d'une manière ou d'une autre, nous avons tendance à considérer les raisons analytiques comme étant extrêmement importantes et correctes.

Nous avons tendance à ne pas tenir compte de la création de produits, et nous avons tendance à ne pas tenir compte de l'instinct et du jugement et de divers autres types d'aspects

John Cutler : Il y a une dualité, n'est-ce pas ? Comme nous exagérons aussi beaucoup l'instinct des gens, l'instinct de certaines personnes, mais je sais ce que vous voulez dire.

Shreyas Doshi : Ouais. C'est donc un type de problème intéressant qui, je pense, revient encore une fois à cette question centrale, par exemple, pourquoi des équipes intelligentes dotées de ressources adéquates produisent-elles toujours des produits médiocres ou médiocres. Ce que nous oublions, c'est que de nombreuses équipes et de nombreuses cultures d'entreprise font qu'il est très difficile pour les gens de trouver des idées créatives. Encore une fois, dans des entreprises très prospères dans l'ensemble.

Où cela commence-t-il en grande partie ? Ça commence dans la réunion, non ? Donc, vous prenez votre réunion de produit typique à n'importe quel niveau. Vous allez rencontrer, dans la plupart de ces entreprises, vous allez apparaître comme beaucoup plus compétent si vous montrez cinq graphiques différents. Vous montrez quelques tableaux. Et puis quelques aperçus qualitatifs. Et puis vous dites, et donc voici ce qui doit arriver. Je ne pense pas qu'il y ait quoi que ce soit de mal à cela. À droite.

Mais ce qui se passe avec cette approche, et cet état d'esprit, c'est que vous êtes donc les, les conclusions ou les recommandations sont en fait assez contraignantes. Ils sont dans cette boîte. Vous ne savez pas qu'ils sont réellement comme dans cette boîte. Mais ils le sont, n'est-ce pas ? Maintenant, si vous permettiez l'intelligence créative de la même manière, que se passerait-il si les conclusions contiendraient des idées farfelues, n'est-ce pas ? Comme quelque chose qui ne découle pas strictement des données, qu'elles soient qualitatives ou quantitatives. Peut-être que c'est même dans cette enveloppe du genre, oh, nous n'avons pas de convictions fortes à ce sujet, mais nous devrions essayer cela. Ce qui se passe, encore une fois, lors de la réunion, lors d'une réunion d'examen de produit, c'est que le chef de produit aura des regards confus ou étranges lorsqu'il proposera une idée créative.

Ou n'importe qui, je choisis juste le chef de produit comme un rôle, mais l'ingénieur ou qui que ce soit. Deuxièmement, ils recevront probablement des commentaires par la suite de la part du gestionnaire de like – et la façon dont ce serait présenté comme n'étant pas tellement, n'apportez pas d'idées créatives, car personne ne veut dire cela – ce serait comme si vous deviez sauvegarder votre proposition avec des données.

Vous devez mieux sauvegarder les choses, et c'est donc le retour que je vous donne en tant que manager, n'est-ce pas ? Ce phénomène se produit très régulièrement même au sein d'entreprises très performantes. Et cela empêche les équipes de créer ces produits qui réalisent réellement le potentiel, euh….

John Cutler : Quelqu'un a récemment déclaré que nous avions trop de prises de décision concernant les hippopotames dans mon entreprise. Nous devons utiliser des données, n'est-ce pas ? Nous devons utiliser des données pour faire disparaître les hippopotames. Et puis j'ai dit, eh bien, qu'est-ce qui va se passer quand vous avez une idée de l'intestin?

Et ils ont dit, eh bien, bien sûr, vous savez, bien sûr, nous allons utiliser la même approche. Nous devons avoir toutes les données pour le faire. Et je me disais, écoute, ton problème n'est pas les hippopotames. Parce que finalement vous allez vouloir avoir des idées créatives.

Si vous n'avez qu'une idée, c'est terrible. Si vous avez 50 idées, c'est paralysant. Vous en avez peut-être trois ? Et mon ami Dan North a dit, non, tu en veux sept. Parce que la première, la première est votre idée, les deux, trois ou quatre deuxièmes idées soutiennent essentiellement votre idée. Donc vous en voulez sept parce qu'au quatrième, le cinquième, le sixième et le septième sont quand vous sortez de votre zone de confort

Niveau d'impact, niveau d'exécution et niveau optique [00:49:13]

Shreyas Doshi : Ouais. Un cadre qui, à mon avis, est un cadre très fondamental qui couvre la plupart des contextes de produits, et certainement tous les contextes de produits que j'ai rencontrés, que je pense que nous devons mieux reconnaître, est ce que j'appelle le cadre fondamental du travail sur les produits.

Donc, nous faisons tout ce travail sur les produits, n'est-ce pas ? Comment devrions-nous penser cela? Comment pensons-nous à ce travail de produit? L'idée que j'ai eue récemment était qu'il y a trois niveaux de travail sur les produits. Il y a le niveau d'impact. Il y a le niveau d'exécution. Et puis il y a le niveau optique. Et de nombreux défis [00:50:00] au sein des équipes de produits, des cultures de produits, sont dus à une inadéquation ou à une incompréhension du niveau auquel nous avons une discussion. Ou le niveau auquel nous opérons.

Souvent, vous constatez qu'une personne de l'équipe opère et réfléchit au niveau de l'impact. Et une autre personne pense au niveau de l'exécution. Mais ils ne parlent pas de ça. Ils plaident la minutie de la situation, n'est-ce pas ? Ainsi, un exemple classique est un PM qui travaille très dur. Pour ainsi dire, un PM opérant au niveau de l'exécution travaille très dur contre toute attente.

Ils n'ont pas reçu de bonnes cartes, mais ils ont créé ce produit, n'est-ce pas ? Comme le produit est une réalité. Ils sont contents. L'équipe est contente. L'ingénierie, la gestion des produits, la conception, la science des données, tout cela, les personnes travaillant sur le produit principal, sont très enthousiastes à l'idée de construire quelque chose.

À droite. Et ils l'apportent à votre examen exécutif, n'est-ce pas. Ou une revue de lancement. Bien sûr, il y a une démo impliquée dans l'examen du lancement. Et encore une fois, la tactique n'a pas d'importance, comment elle est effectuée de manière synchrone ou asynchrone. Le fait est qu'il est examiné. Vous avez un directeur de produit qui opère au niveau de l'impact. Et donc le chef de produit regarde le produit, et le message de base est que ce n'est pas assez bon.

John Cutler : Le compteur de menace se déclenche.

Shreyas Doshi : Les niveaux de cortisol augmentent.

John Cutler : …augmenter…

Shreyas Doshi : Et le PM est frustré, peut-être que le responsable des PM est également confus. Pouvez-vous imaginer toutes les difficultés auxquelles nous avons dû faire face pour arriver ici ? Nous devrions juste être autorisés à lancer cela. Je sais que ce sont tous ces défauts, mais non, non, non, non. Nous devrions juste être autorisés à lancer cela.

Donc, le problème ici est l'exécutif - ils opèrent au niveau de l'impact et ils pensent à l'impact sur la marque, d'accord, du lancement d'un produit de cette qualité, c'est-à-dire inférieur à la barre qu'ils ont eue . Et c'est une situation intéressante parce que les gens commencent immédiatement à parler de correctifs, n'est-ce pas ?

C'est comme, oh, vous savez, peut-être que nous changeons cette chose ou la deuxième chose - encore une fois, tout cela est important d'en parler - mais il est d'abord important de reconnaître cette inadéquation. Et je dirai aussi que ça va être difficile pour le PM, ou le responsable de l'ingénierie, ou le responsable de la conception. Il va être difficile pour les gens là-bas de signaler cela, d'accord, juste du point de vue de la sécurité psychologique.

Ainsi, la façon dont les cadres peuvent mieux fonctionner, et cela s'applique aux personnes à tous les niveaux, est de reconnaître pourquoi l'équipe est fière de ce qu'ils ont fait, ils ont en fait exécuté contre vents et marées. Et, et ils opèrent à ce niveau d'exécution. Et puis appelez explicitement - au lieu de dire, ah, ce n'est pas assez bon, ou cela ne respecte pas la barre ou quoi que ce soit - c'est génial au niveau de l'exécution, cela ne suffit pas au niveau de l'impact, comment pourrions-nous vous atteindre savez, un meilleur résultat ici?

La dernière chose que je dirai à ce sujet, dans le cadre de l'exemple ici, est que vous constatez que dans de nombreux endroits, les gens optimisent le niveau d'optique lorsqu'ils travaillent sur des produits. Le PDG ou le fondateur ou un dirigeant puissant qui a un instinct, ou une idée créative, que les gens engloutissent. À droite? Bob a dit ça, alors allons travailler là-dessus parce que, c'est vraiment…

John Cutler : … et ils ont été très décisifs. C'est comme si, bien sûr, ils étaient décisifs. Ils sont le PDG et vous les écoutez tous.

Shreyas Doshi: Ensuite, l'autre chose, c'est que les conversations parallèles sont souvent, ouais, je ne pense pas que ça va marcher. Mais comme, c'est ce que Bob veut, alors nous allons le faire. Et cela ne doit pas toujours être du haut vers le bas d'ailleurs. À droite? Comme c'est aussi parfois la direction opposée. À droite? Vous construisez quelque chose, et vous le présentez comme ayant plus de succès qu'il ne l'est réellement afin de gérer l'optique.

Donc je ne dis pas que l'optique est mauvaise. En fait, vous devez gérer un certain nombre d'optiques, juste pour pouvoir exprimer fidèlement l'impact de votre travail et la qualité de votre exécution. Le niveau optique devrait aider les deux autres niveaux. Et donc vous devez faire suffisamment de travail là-bas. Mais il existe de nombreuses équipes qui optimisent principalement pour l'optique.

Les gens parlent d'incitatifs et de la façon dont les gens suivront essentiellement les incitatifs. Etc. Je n'utilise pas le langage incitatif. Je pense qu'une question plus fondamentale ici est de savoir dans quelle mesure votre culture et votre organisation incitent les gens à gérer vers l'optique, par rapport à la gestion vers l'exécution ou la gestion vers l'impact.

Biais cognitifs et vocabulaire partagé [00:54:37]

John Cutler: Donc, une partie de mon voyage avec le monde des préjugés cognitifs, parce que j'étais super dedans à un certain moment. J'ai commencé à essayer de rechercher des façons dont nous avons été efficaces pour contrer les biais cognitifs, même lorsque nous en sommes conscients. Et cela n'a pas fait grand-chose pour ma capacité à lutter contre le sophisme des coûts irrécupérables à chaque fois que je l'ai rencontré. Qu'avez-vous vu ne pas fonctionner, et qu'avez-vous vu fonctionner en termes [00:55:00] d'essayer de contrecarrer ces choses ?

Shreyas Doshi : Je pense donc qu'il s'agit du vocabulaire partagé que vous créez pour l'équipe. Et je pense que le vocabulaire partagé est juste un autre sujet qui est beaucoup plus large que les simples biais cognitifs, qui je pense est tellement vital.

Si vous voulez que votre équipe soit en bonne santé, ou plus saine, pensez peut-être au vocabulaire commun de votre équipe concernant le travail que vous faites ? Et je ne parle pas seulement des mots à la mode de l'industrie comme Scrum ou quoi que ce soit d'autre, n'est-ce pas ? Comme, je veux dire, non, non, non. Quel est le vocabulaire que vous ne voyez pas dans la littérature standard sur la gestion des produits, mais que vous allez partager avec l'équipe. Pourquoi cela fonctionne-t-il dans le contexte des biais cognitifs, c'est qu'il est très difficile pour quelqu'un de dire Bob, vous êtes la proie d'une erreur de coût irrécupérable, ou d'une heuristique de disponibilité, ou quoi que ce soit d'autre. Il est très difficile dans la plupart des organisations pour quelqu'un de pouvoir…

John Cutler: … pas de discussion sur les réunions à tarif standard, vous dites, ce n'est pas comme, merci, ouais, je voudrais juste souligner le sophisme des coûts irrécupérables… la réunion zoom s'arrête assez rapidement. Si cette personne commence…

Shreyas Doshi : Exactement ! Euh, et c'est comme, oh, cette personne ne travaille pas bien avec les gens. Ou peu importe. À droite. Comme les gens reçoivent…

John Cutler : … ils ont lu trop de livres. Euh,

Shreyas Doshi : Ils reçoivent des étiquettes assignées. Je pense donc qu'il est important de le faire savoir. C'est pourquoi je ne parle pas de biais cognitifs individuels. Je parle généralement de nos biais cognitifs au niveau des équipes. À droite. Parce qu'alors c'est beaucoup plus facile d'avoir cette conversation du genre, en tant qu'équipe, cela peut nous arriver. Nous pouvons être la proie du sophisme de l'orientation de l'exécution. C'est là que nous décidons de faire quelque chose que nous savons facile à exécuter, même si ce n'est peut-être pas la bonne équipe à exécuter, mais cela nous donne la satisfaction de commencer. Et la satisfaction de créer quelque chose.

Une fois que vous faites savoir à tout le monde, et ensuite en tant que leader - la responsabilité de ce que je vais dire incombe entièrement au leader - c'est de dire, écoutez, je vais devenir la proie de cela. Et en tant que groupe, nous pouvons être la proie de cela. Je veux simplement établir l'attente que nous en parlerons. Et nous le signalerons lorsque nous verrons cela se produire.

Ce n'est pas une faiblesse si nous le signalons. C'est en fait le contraire de cela. Que nous sommes capables d'être conscients de ce qui se passe réellement, et peut-être de prendre une meilleure décision ou de parvenir à une meilleure conclusion. Et donc je pense que le vocabulaire partagé, et puis ce que je viens de dire est alors une responsabilité partagée

Je déteste généralement le mot responsabilité, mais c'est un sujet tout à fait distinct. Mais j'aime bien cela dans ce contexte, qui est une sorte de responsabilité partagée en équipe autour de rappels mutuels et de rappel en équipe des erreurs que nous pourrions commettre. Ou un manque de clarté que nous pourrions avoir.

Par exemple, il y a ce projet que je faisais récemment, qui était un projet extrêmement ambitieux avec beaucoup d'inconnues. J'ai partagé avec l'équipe dès le départ, en fait dans ce cas, j'ai partagé deux choses. L'un était lié au biais cognitif, qui est, écoutez, nous allons probablement être la proie de ces, ces, ces biais cognitifs ou biais cognitifs d'équipe.

Et soyons simplement conscients de ceux-ci. La deuxième chose que j'ai signalée était également - les détails ne sont pas importants, mais c'était une situation très complexe, plusieurs équipes impliquées, et ces équipes n'avaient pas beaucoup travaillé les unes avec les autres. C'était un peu comme travailler pour la première fois.

Et donc j'ai partagé avec eux que l'une des principales choses qui va nous gêner ici, c'est que nous n'allons pas être directs et ouverts les uns avec les autres, en particulier au-delà de ces frontières d'équipe. Cela va probablement, plus probablement, empêcher ce projet de fonctionner que toute sorte d'erreurs analytiques que nous commettons.

Je l'ai rendu encore plus explicite avec ce groupe. Je suis plus préoccupé par notre capacité à bien travailler les uns avec les autres, à être direct les uns avec les autres et à comprendre les points de vue de chacun, que toute autre chose. N'importe lequel des autres types de choses analytiques dont nous parlons, c'est-à-dire, oh, comment pouvons-nous nous adapter à ces trois options de navigation dans cet espace limité ou quoi que ce soit d'autre. Cela ne déterminera pas notre succès. Ce qui va déterminer nos succès, c'est si nous sommes prêts à avoir des conversations difficiles les uns avec les autres à propos de ce genre de choses ? Et sommes-nous disposés à nous écouter les uns les autres et à écouter les points de vue de chacun ? L'autre tactique que j'aime est, je précise aussi, je veux aussi dire que peut-être que vous pensez que c'est une conversation idiote à avoir parce que c'est très moelleux, n'est-ce pas ?

Comme si ce n'était pas des trucs analytiques. Mais si vous pensez cela, alors ma demande [01:00:00] est de m'en parler. Nous devons tous être ouverts les uns avec les autres. Si vous trouvez que ce n'est pas une utilisation utile du temps, alors c'est la première chose dont vous avez besoin pour m'ouvrir. Et donc…

John Cutler : Vous anticipez leur scepticisme à l'idée que vous les exhortiez à… J'aime ça !

Shreyas Doshi : Ouais.

John Cutler: Vous essayez de couvrir toutes vos bases ici, essentiellement.

Shreyas Doshi: L'autre chose que j'ai dû faire dans cette situation est comme, parce que encore une fois, je n'avais pas travaillé avec certains des membres de l'équipe avec lesquels nous allions travailler, c'est que j'ai ensuite mis en place, vous savez, des tête-à-tête avec certains des membres clés de l'équipe, juste pour le souligner à nouveau. C'est comme, écoutez, c'est ma préoccupation en tant que chef d'équipe.

Et généralement pour apprendre à les connaître suffisamment pour qu'ils ressentent la capacité et l'agence de s'ouvrir et de partager quand les choses ne fonctionnent pas. Donc, vous savez, c'est un exemple d'aller à l'encontre des valeurs par défaut. Généralement, j'évite ce genre d'enregistrements individuels réguliers, n'est-ce pas ? Nous ne cessons d'ajouter et, dans une certaine mesure, cela prend en quelque sorte le dessus sur votre calendrier.

John Cutler : Vous ne vous seriez pas fait beaucoup d'amis si vous aviez fait cela chaque semaine, au cours des cinq dernières années. Je pense que la partie brillante de cette réponse est que lorsque les gens apprennent les biais cognitifs, c'est fou. Ce qu'ils font, c'est qu'ils sont toujours comme, eh bien, cela explique le comportement fou de tout le monde. Ah. Maintenant, je sais pourquoi les dirigeants se comportent comme ils le font. C'est comme tout le monde d'abord, quand on pense aux biais cognitifs, tout le monde subit un biais d'attribution fondamental, n'est-ce pas ?

Shreyas Doshi : Je pense que si vous ne voulez pas croire si, si en tant qu'individu ou en tant qu'équipe, vous ne voulez pas croire à la plupart des biais cognitifs, peut-être que ce n'est pas grave. Tant que vous en croyez fermement deux : le biais de confirmation et le biais d'attribution fondamental.

Traiter les tableaux de bord comme un produit [01:01:51]

John Cutler : Oui !

Changer de vitesse juste pour un petit moment, je voulais te demander ça depuis très longtemps. Vous aviez cette idée de traiter les tableaux de bord comme un produit. Comme quelle a été l'inspiration pour cela, cette pensée?

Shreyas Doshi : C'était une collection de quelques observations différentes que j'ai faites au fil des ans sur la façon dont les tableaux de bord sont utilisés. Et comment les gens en général, les équipes produit, pensent aux tableaux de bord.

John Cutler : …les personnes très analytiques dont nous parlons.

Shreyas Doshi : Ouais. Et c'est comme, oh. vous êtes censé avoir un tableau de bord. Donc très bien, je vais avoir un tableau de bord. Permettez-moi donc de partager quelques-unes de ces observations que j'ai faites en cours de route.

Premièrement, il existe de nombreux PRD qui sont écrits sur une fonctionnalité ou un produit non trivial, qui ne couvrent pas à quoi ressemblera le tableau de bord pour cette fonctionnalité ou pour le produit. Et c'est bien. Par exemple, ce que je demande n'est pas ici en tant que maquette détaillée.

Montrez-moi une liste à puces, non ? Par exemple, voici les mesures que nous allons suivre pour comprendre les mesures d'utilisation, c'est-à-dire, comment cette fonctionnalité est-elle utilisée ? Que font les utilisateurs avec ça ? Et, le second étant l'impact. On se concentre parfois beaucoup sur les mesures d'impact et pas assez sur les mesures d'utilisation.

John Cutler : Absolument.

Shreyas Doshi : Mais genre, je dirais que genre…

John Cutler : N'appelez pas cela une métrique de succès. Car alors parlons de sécurité psychologique ! Tout est fait à ce moment-là. Indicateur de performance clé, vous savez, c'est…

Shreyas Doshi : Oui.

John Cutler : … tant pis pour le moment.

Shreyas Doshi : Encore une fois, le vocabulaire est très important. C'est un excellent point. Il doit appartenir au chef de produit ou à la personne qui remplit ce rôle.

John Cutler : Vous avez besoin de beaucoup de connaissances dans le domaine pour obtenir cela, n'est-ce pas ?

Shreyas Doshi : C'est vrai.

John Cutler : … il y a la nature unique de l'utilisation .

Shreyas Doshi: Et la plupart, la plupart des équipes ont l'autre catégorie de métriques, qui est la métrique de santé. Parce que généralement, les équipes d'ingénierie s'assureront qu'elles disposent de la bonne instrumentation et du bon tableau de bord pour cela.

C'est la première observation, c'est comme si nous ne spécifions pas cela de manière adéquate. à droite. Donc, la deuxième chose est de supposer qu'une équipe spécifie cela, et un tableau de bord, ou un e-mail de métriques, peu m'importe ce que c'est. Comme si quelque chose se construisait et commençait maintenant à vous donner un aperçu des choses qui comptent. Comment les gens l'utilisent, quelle est l'adoption, quel est l'impact, c'est tout, super.

La deuxième observation que j'ai faite est que personne ne regarde ce tableau de bord.

John Cutler : Je peux confirmer cette dynamique basée sur quelqu'un qui propose l'un de ces outils que beaucoup d'entre eux ressemblent à des arbres qui tombent dans la forêt. Il y a des cimetières de tableaux de bord. Disons-le ainsi.

Shreyas Doshi : Bien sûr. Si c'est vous et votre équipe, ne vous sentez pas mal. C'est 90% de ce que j'ai rencontré à différents moments. À droite. Ouais. Nous avons consacré tous ces efforts à la création de ce tableau de bord. Presque personne ne le regarde.

Donc, c'était le deuxième type d'observation. En remarquant cela, ce que j'ai réalisé, c'est, oh, attendez une minute. Nous ne faisons pas à notre tableau de bord des métriques, [01:05:00] ce que nous disons est la bonne chose à faire pour nos produits. Il y a donc un certain type d'auto-référence ici. Autrement dit, vous savez, si nous construisons un produit, vous savez clairement que la bonne chose à faire est de suivre son utilisation, de suivre les mesures, etc.

Donc, si vous visualisez le tableau de bord, qui vous donne un aperçu de votre produit, pourquoi ne pas le considérer comme le produit lui-même. Et suivez les métriques d'utilisation de votre tableau de bord. Comme un simple compteur, par exemple. Combien de personnes ont consulté ce tableau de bord que nous avons passé une tonne de temps à créer la semaine dernière.

À droite? Juste quelque chose d'aussi simple que ça, juste un nombre de vues, par exemple. Et puis vous pouvez regarder cela et voir, oh, attendez une minute, personne ne regarde réellement les métriques. Cela crée donc deux possibilités. La première est qu'il n'est pas utile en termes d'informations ou de prise de décision. Ou il y a un problème, d'accord, comme avec nous et comme ça, nous devons le résoudre. Mais vous ne pouvez commencer à le faire que si vous y pensez en quelque sorte comme un produit, n'est-ce pas ?

Une fois que vous commencez à penser au tableau de bord en tant que produit, bien sûr, vous allez ensuite créer des exigences pour le tableau de bord et l'intégrer au PRD d'origine. C'est comme, c'est ce que nous devons suivre. C'est pourquoi nous devons le suivre. C'est ainsi que nous allons le suivre. Et puis vous instrumenterez évidemment les choses dans le tableau de bord de manière à comprendre son utilisation, etc.

Et la dernière partie que je dirai, c'est qu'une grande partie de tout cela n'est pas une intention ou une compétence ou quoi que ce soit d'autre. Je ne pense pas que ce soit parce que les gens sont incompétents que ces choses arrivent. Je pense que c'est parce que c'est dur. Je pense que c'est en fait aussi simple que la friction, non ? C'est encore une autre chose que vous devez penser à faire pendant votre journée bien remplie. Vous savez que c'est la bonne chose à faire. Pour aimer voir vos métriques d'utilisation de temps en temps. Ou du moins, référez-vous à eux lorsque vous allez prendre la prochaine décision.

Mais il y a des frictions. Il y a une charge cognitive qu'il faut gérer. Et donc maintenant, encore une fois, en y pensant comme un produit, vous pouvez maintenant commencer à y penser en termes de comment éliminez-vous la friction ? Parce que c'est ce que nous faisons dans nos propres produits, n'est-ce pas ? Par exemple, nous réfléchissons à la friction de l'utilisateur et comment l'éliminons-nous ?

Et cela ouvre des perspectives intéressantes. Comme l'une des habitudes que j'ai depuis de nombreuses années, à ce stade, j'ai mes onglets d'épingle dans Chrome. Et j'ai mon email, et mon Slack, et mon calendrier, qui sont épinglés. L'une des autres choses qui sont épinglées est mon tableau de bord principal des métriques. Alors c'est là. Je n'ai pas besoin d'ouvrir un nouvel onglet, de saisir une URL, c'est juste là. Une autre chose que j'ai remarquée, c'est que les gens adorent les métriques de messagerie. Pourquoi? Parce que ça supprime les frottements, n'est-ce pas ? Ça se voit juste. Et il y a ce genre de contrat que nous avons au moins conclu avec nous-mêmes selon lequel nous devrions regarder les e-mails. Donc, ce qui finit par se passer, c'est que les gens regardent beaucoup plus attentivement les mesures qui sont envoyées par courrier électronique que, en quelque sorte, les mesures qu'ils doivent rechercher de manière proactive.

Donc, souvent, pour des projets importants, je dirais, oh, vous savez, envoyons également un e-mail récapitulatif. Cela peut être aussi simple que quelques statistiques de haut niveau et juste un lien vers le tableau de bord. Même ce lien qui vous est envoyé par e-mail vous facilitera grandement la tâche et éliminera les frictions. Au lieu d'avoir à y penser et à le faire.

Calendriers remplis, réactivité, identité de soi et habitudes positives/négatives [01:08:20]


John Cutler : Quand vous voyez ces calendriers de personnes, et que vous voyez ces PM qui sont en mode réactif tout le temps. Qu'ils n'ont même pas un moment pour penser à ce genre de choses. Quel est le premier conseil que vous leur donnez ? Comment régnent-ils cela?

Shreyas Doshi : J'ai passé les cinq premières années de ma carrière de Premier ministre dans un état de stress extrême et dans une certaine mesure sur la défensive, tout le temps. Je dois m'assurer que les choses ne s'effondrent pas. C'est tout ce que je fais, et cela me prend toute mon énergie. Et je pense qu'une grande partie de cela est, bien sûr, que j'étais probablement beaucoup moins compétent dans le rôle. Et donc les choses me prenaient plus de temps, et ainsi de suite. Et donc je ne veux pas négliger cela, vous savez, qu'il y a une courbe d'apprentissage, et il y a un coût à cette courbe d'apprentissage. Et c'est un voyage que tout le monde doit traverser. À droite. Alors. Ouais.

Je ne pense pas que ce soit nécessairement une mauvaise chose. Vous utilisez le mot habitude et je pense que c'est là le problème. Ce qui se passe, c'est qu'à cause de ces premières années, nos années de formation en tant que chef de produit, nous prenons certaines habitudes. En supposant, par exemple, que nous soyons en fait assez bons dans ce que nous faisons, nous voyons le succès. Et donc vous pensez certainement, d'accord, ouais, je semble faire les bonnes choses. Et donc je devrais faire plus de ces choses. Cela aide vraiment d'avoir des entretiens individuels avec chaque ingénieur de l'équipe sur une base hebdomadaire, de vérifier avec eux ce qui se passe, puis de se connecter avec eux à un niveau personnel, et cetera, et cetera. Je vais donc en faire de plus en plus. Génial. Cela fonctionne lorsque vous avez 10 ingénieurs dans l'équipe, maintenant vous avez plus de portée. Maintenant il y en a 20, puis il y en a 30. [01:10:00] Quoi, qu'est-ce que tu fais ?

John Cutler : N'est- ce pas ? Pendant ce temps, ils se targuent, s'identifient, d'avoir de si bonnes relations avec chaque ingénieur. Le trou noir un-à-un de…

Shreyas Doshi : oui. Et donc John I, et comme, je pense que cela a déclenché quelque chose d'intéressant, c'est-à-dire, je pense que c'est peut-être deux choses. C'est son habitude et son identité. C'est ce que je suis. C'est comme ça que je fais les choses, hein. Oh, cette chose dont vous parlez, ou cette chose dont parle cette autre personne ?

Non, non, non, non, ça ne me va pas. À droite. Comme je suis différent. C'est mon identité, c'est ainsi que je fonctionne. Il y a donc l'habitude et l'identité. Et je vois tout le temps des gens dans des situations où c'est complètement ingérable. Ils ne savent pas quoi faire.

Ils pensent juste que c'est comme ça. Parfois, leurs managers leur diront, ouais, c'est comme ça le travail de PM. Regardez mon agenda, c'est encore pire ! Et puis il y a aussi ce petit peu de comparaison, qui est comme, oh, dont le calendrier est pire. Et comme, cette personne est plus un PM, non ?

C'est si difficile à cause de la question de l'habitude et de l'identité. Il est difficile pour les gens d'accepter qu'il existe une voie alternative ici. Si vous pensez au public, il écoute ça, chaque fois que ça sort. Il y aura certainement un groupe de personnes qui diront, oui, tout ce qui est discuté ici ne s'applique pas à ma situation. Et cela ne s'applique pas à mon entreprise à cause de mon patron, à cause de cette raison, parce que mon équipe est différente, parce que quoi que je sois différent, j'ai de plus grandes ambitions, peu importe. Donc, vous savez, ce que je dirais, c'est que cela ne peut pas être résolu tant que vous n'acceptez pas qu'il existe en fait une meilleure solution.

Vous devez comprendre que vous voulez résoudre ce problème, plutôt que de penser que c'est comme ça. But once you start entertaining that thought, that there are other ways that this problem can be solved or at least should be mitigated, now we can talk. À droite? So now we are at a smaller part of the audience that is really stressed, but it's perhaps more open to sort of exploring those ways.

And then what I would say this goes back to the role of a product manager and particularly the role of a product leader. Remember we talked about building self managing teams. À droite. Well, what happens when you actually build self managing teams? You have to do less management, right? Because they're self managing. That's sort of the goal. Now, it doesn't solve the problem because how do we get to the goal?

The way one needs to think about these situations is you know, yes, I can stay on top of everything. And you know, in some cases, like we talked about, the context requires you to stay on top of everything. But, you don't have to make that your default, and you don't have to do it in every single situation.

So one of the things I like to tell, especially new managers, is assume there are things you are not going to be on top of. Because then you will have to go to every single meeting. You'll have to accept every single input in order to, sort of, figure out what to do.

So assume that's not going to happen. And what you need to do is to figure out ways in which now you're going to get those inputs through people on your team. And you are going to organize your one-on-ones in a way that you're able to get those inputs. You're, uh, you're going to organize rituals on your team, whether it's product reviews, or other rituals on execution check-ins or what have you, in order to get the right signal .

This is all easy for me to say, but it is hard to do, and it requires practice. And it requires trying to identify your unique style of doing it, et cetera, et cetera. But the beautiful part, when you cannot like, do this, and do this with some degree of success, is now all of a sudden you are able to be much more useful, and much more effective, right?

You are able to get more clearly to the thing that matters, right? You are able to help your team members. You are kind of like coaching them through experience around expressing to you the stuff that matters. À droite. And then you are able to also give them the independence, and the leeway, to be able to operate on their own versus kind of handling them through all of this.

Improving the current situation (and gap vs. present thinking) [01:14:24]

So, concretely, the common sort of argument I hear is yeah, yeah, things are horrible right now, but it's because I don't have a full team. Like I have this four or five head count. Once I get these people, and get them to be productive, things will be better. And guess what happens? You get those four or five engineers on the team, or four or five PMs on the team if you're a PM manager. Situation is worse, not better. But at that time, it's like, oh, you know the problem is we are not organized properly. My team should not [01:15:00] belong to this organization. It should be in this other part of this organization. And that's what's creating the problem for me. You know, so it's like this, kind of, basically we are on the treadmill forever right?

I'm not discounting the validity of these reasons. What I am suggesting is that regardless of external factors, which we should try to improve, and we should feel high agency towards making the organization better, and improving whatever situation we are in. But we need to also be very cognizant of how I can best manage the current situation I'm in. Versus like, basically I noticed that especially the managers and product managers that tend to get extremely stressed, and let the work affect all parts of their personal lives and whatnot is… they're constantly looking for the next thing that is outside of them that's going to fix this issue. And then that results in burnout, that results in frustration when it doesn't happen. And they don't pay enough attention to, okay, given this current situation, what do I need to do differently?

John Cutler: My friend Jabe Bloom has this interesting thing, which is gap thinking versus present thinking. And he makes the point that standard business school, standard consulting is all about the gap. What's the current thing? Exactly where do we need to go? How are we going to get across that particular gap?

Like that's a very tried and true way to think about it. And then he presents this other idea that present thinking is not adverse to thinking ahead. It's like, what's going on right now? What do we visualize as the better version of right now? Where do I have agency to act right now? Instead of just the gap, you know, it's like there and you have to go across it. It's kind of like little mini gaps, right. But the one part, the one thing you said that really resonates there is, you know, in some ways, as humans by, gap thinking is always a way to also “other” the problem.

It's the tendency of people to combine gap thinking with fundamental attribution bias, which is like, not only is there a big gap that we need to get across and there's the perfect plan to get across it. But the road involves other things in the org that have to happen, et cetera, to make it to it.

So I don't know if that's, I've liked that distinction between gap thinking and present thinking. One thing that's hard is that a good chunk of modern business is centered around gap thinking. What's the gap, bring me solutions, not problems, you know, like how are we going to get across the gap all the time? Alors…

Shreyas Doshi: Yeah, that resonates a lot. One other thing I want to share around this topic of PM stress and this constant feeling of inadequacy, and I'm not doing enough to move the product forward, and and my schedule is crazy, and I'm just not able to perform at the level I need to et cetera, et cetera. All of which, by the way, again, a common theme is this was me for the first five PM career. And I used to share all of this with my wife all the time and like, you know, huge kudos to her to just like, listen…

John Cutler: She taught you how to listen…

LNO: Leverage, Neutral, and Overhead Tasks [01:18:10]

Shreyas Doshi: Exactly. So I think one key thing that was a turning point for me was the understanding of —uh, and I don't even know where I read it, it was some blog posts that I read and what I'm about to share is a paraphrasing of that, I can't find the blog post anymore for whatever reason— but it's what I termed as the LNO framework for PM effectiveness. Which is the observation that there are three kinds of tasks that I tend to do as a PM.

There's a leverage task, there's a neutral task, and then there's an overhead task. The leverage task, you know, as the name suggests, gives greater than what you put in. The neutral task will give you the same. And the overhead tasks will give you less. What most PMs do, and certainly what I did during those highly stressful days of my career as a PM, was I approached every task, any given task in the same way. Which is, oh, I'm going to try to do an awesome job. I was like some, you know, inner perfectionist, et cetera, et cetera. So I would spend a ton of time without understanding whether this is a leverage task, a neutral task, or an overhead task, right?

And, and what's right for the company you work for– and certainly for your team and very likely for you– is for you to understand that upfront. And then, you know, adjust the amount of energy and the amount of time based on that understanding. And I think what that does is, it certainly did for me, is it means spending more time and exerting more energy on certain things.

Because now you understand that this is a leveraged task. So instead of spending two hours on writing that, you know, completing that PRD, maybe you ought to spend four hours today to do that. Now of course, that extra two hours have to come from somewhere else. So find out [01:20:00] what are your neutral tasks or overhead tasks.

And so one example of, you know, usually a neutral, sometimes an overhead task, is you will get some requests for certain reports from finance, like, what's our 24 month projection for how the product is going to– like how much headcount do you need or whatever. Now, you know, I look at those things and, you know, there's the perfect way of doing it. And I see all these sometimes PM leaders, especially going to these meetings, and talk about all the analytical stuff of what's going to happen in September of 2022. And, November of 2023. And people are having all these discussions. Again, it goes back to, oh, we think we, we have certainty around what's going to happen.

They end up spending a ton of time on all of these things. And, what I typically do is like, again, usually– you know, sometimes it's an exception– but usually when I get these requests, I get them done in five, 10 minutes. À droite.

Like these, these are the assumptions. Voici. And if you need something more detailed, then please let me know how this is going to materially change, you know, things from a budgeting perspective or something else.

So that's just an example of where you kind of get back that time. And what I found is that as I started doing more and more of this, and on a tactical level what I would do is I created the to-do list, I would actually prefix the task just as a reminder to myself with L, N, or O .Right?

So when I started doing the task, I was like, okay, this is a leveraged as to how I'm going to approach

Conclusion [01:21:23]

John Cutler: I love that. I love ending with something really actionable. And so that's something that I'm going to do with the rest of my day too. To do these things. But, Shreyas, I wanted to thank you. We could have gone on for hours cause there's just so much, uh, so many questions I have. And I'm amazed too, about your ability to weave in and out your frameworks too. So you've actually inspired me thinking about how to be more actionable in these types of conversations. Because you've left people with specific frameworks, but we also went really deep into everything about intentionality, and culture, and stuff. So I really, really appreciate it.

And I'm super grateful for the opportunity to chat with you. And yeah, we'll stop now. But we should do it again at some point. Maybe people will have questions. Maybe we could do a follow-up like rapid fire, uh, answers to those questions if that would work for you.

Shreyas Doshi: Yeah, I would love that this was a blast. Vous avez raison. We could have gone on for hours and this is fun stuff. So thanks for that.

John Cutler: I want to leave people with that one thing that Shreyas opened with. We've both probably learned the hard way. So when you see us tweeting assume that we've made the mistake 55 times, and we've had to work through it, context always matters, that would probably be like a footnote on those things. And three, I loved your statement too. You know, if you're in an unhealthy environment, you know, don't just assume you can just jump in. I think taking care of yourself, that's my theme, you know, as the tail end of the pandemic, is that people need to take care of themselves too.

Product Analytics for Dummies