Извлеченные уроки о продукте: беседа со Шреясом Доши и Джоном Катлером

Опубликовано: 2021-07-13

За относительно короткое время Shreyas Doshi стал одним из самых популярных распространителей советов по продуктам в Twitter. Почему? Его письмо ясное, скромное и самосознательное - черты, которых часто не хватает среди огненного шланга горячих дублей. Его формат выбора? Потоки. И много их. Переплетены, но организованы. Вся мудрость карьеры, упакованная в строки из 280 символов. Доступно для всех здесь.

Мне было очень любопытно, кто стоит за (хорошим) безумием. Итак, мы договорились об интервью! Мы затрагиваем такие темы, как лидерство, умение лучше слушать, роль менеджеров среднего звена, карьера и самоидентификация, упрямство, календарный театр и отношение к вашим информационным панелям как к продуктам.

Что выделялось? Шреяс имеет богатый опыт управления продуктами. Он работал менеджером по продуктам и менеджером по продуктам в таких компаниях, как Stripe, Google, Twitter и Yahoo. Он прекрасный писатель и оратор. Но по-настоящему сияет его скромность и задумчивость. Он предостерегает людей от слепого копирования его советов и открыто признает, что многие из этих уроков он усвоил на собственном горьком опыте.

Интервью длится 1 час 30 минут (см. аудиоплеер ниже). Если вы хотите прыгать вокруг, мы создали план интервью ниже с отметками времени. Для каждого раздела Шреяс был достаточно любезен, чтобы предоставить ссылки на связанные темы.

Есть дополнительные вопросы к Шреясу? Пожалуйста, пишите свои вопросы, включая @Amplitude_HQ, @shreyas и #shreyasinterview. Если будет достаточный интерес, мы попытаемся запланировать последующую AMA.

У меня есть вопрос к @shreyas и @johncutlefish #shreyasinterview Click To Tweet

И если вы хотите узнать больше о стратегии продукта и лидерстве в управлении продуктом, обязательно загрузите копию пособия North Star. В нем полно рекомендаций и схем, которые помогут вам немедленно оказать влияние на ваш бизнес и вашу команду.

Содержание интервью

Полная стенограмма включает соответствующие твиты для контекста. Спасибо Shreyas за кураторство для всех!

  • Введение [00:00:00]
  • «Не верьте всему, что я пишу…» [00:01:07]
  • Понимание себя [00:04:03]
  • Стать лучшим слушателем [00:05:13]
  • Переход IC на менеджера [00:11:49]
  • Обсуждение неопределенности и организационной культуры [00:14:10]
  • Средний менеджмент и «настоящая правда» [00:16:52]
  • Роль продуктового лидерства [00:18:01]
  • Профессиональная идентичность (и переход к лидерским ролям) [00:21:56]
  • Роль менеджера в том, чтобы помочь людям принять нестандартное поведение [00:25:39]
  • Образ мышления, принципы и тактика (и застревание на тактике) [00:30:29]
  • Основы/основы для высокоэффективной команды [00:35:11]
  • Почему команды, соблюдающие базовые принципы, производят плохие продукты? [00:37:31]
  • Целеустремленность и упрямство (с компанией, которой вы хотите быть) [00:39:24]
  • Аналитический и творческий интеллект [00:44:14]
  • Уровень воздействия, уровень исполнения и уровень оптики [00:49:13]
  • Когнитивные искажения и общий словарный запас [00:54:37]
  • Отношение к информационным панелям как к продукту [01:01:51]
  • Заполненные календари, реактивность, самоидентификация и положительные/отрицательные привычки [01:08:20]
  • Улучшение текущей ситуации (и разрыва с текущим мышлением) [01:14:24]
  • LNO: кредитное плечо, нейтральные и накладные задачи [01:18:10]
  • Заключение [01:21:23]

Стенограмма интервью

Введение [00:00:00]

Джон Катлер: Доброе утро, Шреяс.

Шреяс Доши: Доброе утро, Джон.

Джон Катлер: Как дела?

Шреяс Доши: Довольно хорошо. Хорошо быть здесь.

Джон Катлер: Итак, мы разговариваем во второй раз. И я помню, когда мы впервые поговорили, ты подумал, стоит ли мне продолжать делать это в Твиттере? Или как насчет книги? Я не знаю, сколько месяцев это было. Я имею в виду, кажется, что время пандемии как бы раздавливает вещи в целом, но прошло некоторое время спустя, и для вас все взорвалось.

Так что я просто хотел бы отметить разницу с момента нашего последнего разговора. Так что, думаю, поздравляю.

Шреяс Доши: Спасибо. Это было весело. Просто записываю некоторые мысли о продукте и еще много чего. 280 символов за раз.

Джон Катлер: Для тех, кто не знает, Шреяс Доши, я собираюсь дать самое быстрое введение. Он менеджер по продукту. Так что совсем недавно в Stripe у него был опыт работы в Twitter, Google и Yahoo. Является плодовитым писателем. И я думаю, что это все.

Я хотел прорвать завесу непобедимости, чтобы начать, если это нормально. Потому что ты так лаконично пишешь. С какой ошибкой вы боролись последние пару месяцев?

«Не верьте всему, что я пишу…» [00:01:07]


Шреяс Доши: Да. Итак, одна вещь, которую я хотел бы сказать о своем творчестве, это, прежде всего, не верить всему, что я пишу, и не брать все, что я пишу, и просто реализовывать это, потому что вам нравятся мои писания, или потому что это получило кучу лайков. , так что это должно быть правдой. Джон, это то, что в течение прошлого года я действительно начал писать о своих мыслях о продукте, стратегии, организациях и многом другом.

Прежде чем я нажму твит или, или, или кнопку отправки, самое большое беспокойство, которое у меня, как правило, возникает: о, вот шесть способов, которыми то, что я только что сказал, может быть вредным, если вырвано из контекста или если оно будет реализовано в неправильный контекст. Я постоянно беспокоюсь о том, что пишу, и иногда некоторая точность и, возможно, некоторая сила письма, если таковые имеются, могут звучать правдивее, чем на самом деле в вашей конкретной ситуации.

Написание далеко от совершенства. Потому что он, вероятно, упускает много-много нюансов, даже когда я пытаюсь сделать его более ясным или где-то в протекторе. Так что это один. Во-вторых, я, кажется, несколько недель назад написал это в твиттере, и вы знаете, что я склонен много говорить о том, чего не следует делать против шаблонов. И причина, по которой я говорю об этом, и иногда люди говорят мне, о, это внесло большую ясность. Я видел этот антипаттерн в своей команде, в своей компании, в себе, в своем руководителе, кем бы он ни был. И как ты туда попал? Итак, я написал в твиттере об этом моменте, который, как вы знаете, многие из этих анти-паттернов, о которых я пишу, я был этим анти-паттерном. Верно?

Я видел это внутри себя.

Иногда, может быть, всего на несколько часов, когда я попадаю в этот антипаттерн, типа, о, я это почувствовал, и я остановил его, и мне удалось его остановить. Иногда у меня возникал определенный антипаттерн, о котором я пишу много месяцев. И есть другие, которые у меня были в течение многих лет, и вещи, с которыми я сам не очень хорошо справляюсь.

И поэтому есть такой аспект, знаете ли, многого из того, о чем я пишу, я видел части этого внутри себя или все это в себе в разное время. И, я думаю, единственная разница, возможно, в том, что вы знаете, это своего рода наблюдение за собой, верно? Еще мне нравится делиться тем, что мы можем говорить о тактике и о фреймворках, структурах и шаблонах для управления продуктом.

Понимание себя [00:04:03]

Но с другой стороны, я думаю, что очень важно для всех нас, менеджеров по продуктам, осознать и стать лучше как менеджеры по продуктам, это понять самих себя. Вы знаете, хаб, о котором они говорят, о, поймите пользователя, поймите клиента, поймите рынок, поймите конкурента.

Я согласен со всем этим. Но и понять себя. Начните с понимания себя. Теперь ты не поймешь всего себя сразу. Но если вы начнете с понимания себя, вы обнаружите, что некоторые из этих других способов понимания пользователя и еще чего-то становятся проще.

Есть много вещей, в которых я не силен. Совсем недавно, я думаю, я снова разговаривал в Твиттере, и кто-то спросил меня, о, Шрейас, как можно хорошо справляться в организации?

Я сказал: «Послушай, у меня нет ответа на этот вопрос, потому что я очень плохо справлялся со всем этим много-много лет. Эндрю Ю прислал мне книгу о том, как управлять собой. И поэтому я сказал: «Эй, Эндрю, наверное, тебе следует ответить на этот твит, а не мне». Так что это просто пример того, что вы знаете, я не совсем взломал.

Стать лучшим слушателем [00:05:13]

Джон Катлер: Что мне действительно нравится, так это то, что в ваших тредах вы уязвимы и скромны. Я помню один твит, который мне очень понравился, где вы заметили, что вы в молодости лучше слушаете, и что вы соскользнули в период, когда вы тоже не слушали.

И это было чрезвычайно важно для меня. Потому что я думал, что я прошел через эти фазы в своей жизни, и это не статическая ситуация. Ты всегда учишься. Мне было интересно, конкретно в этой ситуации, на что была похожа эта самореализация? Знаете, когда вы это понимаете и как вы с этим справляетесь? И что потом, какие шаги вы предприняли? И вы начали подробно рассказывать об этом в ветке, но мне было бы очень интересно, если бы вы объяснили это и услышали лично.

Шреяс Доши: Итак, в детстве я был прекрасным слушателем. Раньше в детстве у меня тоже была довольно сильная память. Это уже не так. Я теперь все время что-то забываю. Но я так начинал. И так много вещей в школе, например, было очень рано, легко для меня, потому что я просто слушал, что говорил учитель.

И тогда я смог сохранить его в течение очень долгого времени. Это изменилось в подростковом возрасте и в начале двадцатых годов. Знаешь, я не знаю почему. Должно быть, именно через это вы прошли в юности. Где ты просто, в какой-то момент, я просто полностью отключился в колледже.

И я понятия не имел, я физически сидел там, но я понятия не имел, о чем говорилось. И это продолжалось. Это просто стало шаблоном. Тогда как, когда я начинал свою карьеру инженера-программиста, у меня уже не было той степени апатии к тому, что говорится на собрании или к тому, что говорит другой человек. Но я просто потерял этот навык из-за того, что не использовал его в течение пяти-шести лет.

Джон Катлер: Был ли момент, когда вы подумали: «Подождите, я потерял это?» Мол, как ты, как тебя осенило, или это было похоже на медленное горение. Или, может быть, это был менеджер или кто-то, кто поделился с вами новостями? Как, как вы это поняли?

Шреяс Доши: Знаешь, Джон, я понял это очень поздно. Итак, я хочу сказать, что я был в состоянии быть хорошим слушателем около 12 лет, когда я начал свою карьеру. Это означало, конечно, что я слушала. Я занимался обработкой и так далее. Но я был в этом классическом режиме, формируя свои собственные мысли. Формирование моего ответа и подготовка моего ответа. Или, не совсем слушая то, что было сказано, а слыша то, что я хотел услышать.

Так что я был на этом этапе по крайней мере 12 лет в моей карьере. В какой-то момент я осознал, что ключ к пониманию другого человека заключается в том, чтобы убедиться, что он знает, что я его понимаю. Верно? Итак, я начал с этого первого шага. И это был очень тактический вид, он не был основан ни на каких принципах. Это была тактика вроде ладно.

Джон Катлер: Вы должны были все обдумать в своей голове, что…

Шреяс Доши: Да. Чтобы быть хорошим менеджером, мне нужно убедиться, что другой человек понимает, что я понимаю, о чем он говорит. Это то место, с которого я начал. И, а потом я сделал это, и я бы сказал, что это, может быть, перевело меня из разряда 4 из 10 в 6 из 10. И это нормально. Это улучшение.

Но затем следующее большое осознание и квантовое изменение, которое я смог совершить, произошло, когда я понял, что когда вы слушаете только то, что говорят, и вы полностью присутствуете, ответы создаются сами собой. Верно? Так что мне не нужно думать, пока вы говорите. Или мне даже не нужно думать, как я подытожу то, что вы говорите, просто чтобы убедиться, что я вас понял.

Я просто хочу присутствовать на сто процентов. И я хочу быть любопытным. Это была перемена. Было ли это подлинное любопытство и развитие этого подлинного любопытства, наряду с умением присутствовать и как бы наблюдать за своими партиями, и как бы возвращаться в точности к произносимым словам.

Затем, когда я сделал это, когда я подошел к этому из этого искреннего любопытства и присутствия, вот тогда я увидел, о, ничего себе, когда я делаю это, происходят две вещи. Во-первых, я [00:10:00] просто кажусь этому другому человеку гораздо более заинтересованным в том, что он говорит. А во-вторых, качество моего ответа намного выше.

Принимая во внимание, что раньше, часто, ответ, как правило, имел смысл, хорошо, я вас услышал, и, учитывая мою роль, это часто, как будто я вас услышал, и вот мой совет. Или вот мой ответ. Ответ превратился в вопрос, а не в утверждение.

Так они поняли, что я действительно их понимаю. И я делал настоящую попытку глубже понять их. Они что-то сказали мне. Я действительно присутствовал. Мне было искренне любопытно. И из-за этого я задал им вопрос, который в противном случае не задал бы. И этот вопрос приблизил нас к тому, чтобы лучше понять ситуацию. Когда я начал это делать, я все больше и больше осознавал, что это действительно эффективно. Задавать людям вопросы намного эффективнее, если это правильные вопросы. И если они основаны на глубоком понимании или настолько глубоком, насколько это возможно, понимании того, что другой человек пытается сказать о ситуации.

Джон Катлер: Похоже, вы что-то развили с течением времени и стали намного лучше в этом. Например, вы можете задавать лучшие вопросы один на один и так далее.

Шреяс Доши: Конечно. И, вы знаете, я был менеджером менеджеров по проектам в каждой из четырех компаний, в которых я был менеджером по проектам. К трем из этих четырех компаний я присоединился в качестве индивидуального участника, включая Stripe, моего последнего работодателя. Я присоединился в качестве индивидуального участника, а затем начал управлять людьми.

Переход IC на менеджера [00:11:49]


Итак, я прошел через этот переход от IC к менеджеру. Многие люди проходят через это один или два раза. Ну, а потом они остаются менеджерами. Я прошел через это несколько раз. И я не против быть в IC, где это имеет смысл. Так что это сработало хорошо для меня.

Хотя каждый раз было по разному. Потому что я вырос как менеджер. Я думаю, когда я начал управлять, это было девять месяцев в качестве менеджера по продукту. Мне сказали, о, нам нравится то, что ты делаешь. Почему бы вам не управлять небольшой командой? Оглядываясь назад, я не понимал этого в то время, но оглядываясь назад, я чувствовал себя ужасным, ужасным менеджером ПМ. Это восходит, знаете ли, ко многим этим антипаттернам. Я был этим. Потому что я помню, как рано я был так уверен, что у меня есть ответ.

И так это было одно. А во-вторых, я думал, что моя работа заключается в том, чтобы дать ответ. Если я сталкивался с сопротивлением внутри моей команды, чтобы принять или принять этот ответ, тогда я чувствовал, что моя работа состоит в том, чтобы убедить их с помощью очень аналитических средств, почему это правильный ответ, верно?

Тогда я был просто ужасным менеджером. И, конечно, сейчас я придерживаюсь совсем другого подхода. Во многом это связано с тем, чтобы просто, ну, культивировать подлинное любопытство, я полагаю, также и общую жизненную зрелость. Но и просто возможность наблюдать за своими мыслями, а также понимание того, что именно должен делать PM-менеджер.

Какова их работа и какова их роль? Теперь я лучше понимаю, тогда как раньше меня просто просили начать управлять людьми, как будто я понятия не имел, что я на самом деле должен делать.

Джон Катлер: Когда вы думаете о компаниях, в которых вы работали, я имею в виду одну вещь, которую я заметил в некоторых корпоративных культурах, это то, что они очень по-разному относятся к обсуждению неопределенности. В некоторых, вы знаете, никогда, никогда не упоминайте неопределенность, если у вас нет четкого плана по ее уменьшению.

И в других культурах они кажутся гораздо более открытыми для лидера, чтобы сказать, просто не знаю прямо сейчас. Итак, каков ваш план игры на этот счет? Как будто вы были в этих организациях, но как вы поняли культуру уязвимости для лидеров?

Потому что это очевидно важно, но проявляется по-разному в разных культурах.

Обсуждение неопределенности и организационной культуры [00:14:10]

Shreyas Doshi: Мне нравится, что ты упомянул культуру, Джон, потому что все это восходит к ней. Есть культуры, где. Да, ты должен быть уверен. И если вы не уверены, и если у вас нет полного обоснования, аналитического обоснования, вас считают некомпетентным.

Есть и другие культуры, где определенная доля неопределенности рассматривается как часть того, что мы делаем, то есть, да, мы не знаем, как это сработает, и это нормально.

Это не означает, что вторая категория культуры менее строгая. Я бы сказал, что это более строго. Потому что он не основан на иллюзиях о строгих математических результатах, основанных на определенных входных данных. Он понимает случайность, связанную с тем, что вы берете продукт [00:15:00] и выносите его во внешний мир. Он понимает другие случайности, саму систему на рынке и еще много чего.

Это работает в рамках такого понимания реального мира этих вещей. По сравнению с некоторыми идеализированными, вы знаете, о да, мы должны быть в состоянии доказать это с помощью подхода, похожего на электронную таблицу. Полоса — хороший пример. Где, вы знаете, у нас были бы обзоры продуктов, в которых наши основатели или наши лидеры сказали бы: да, мы не можем быть уверены в этом.

Давайте разберемся, что такое отзывы клиентов. Давайте разберемся, что такое рыночный контекст. И затем, основываясь на этом, мы примем лучшее решение в данных обстоятельствах. Но, знаете, мы не должны быть уверены, что это сработает.

Джон Катлер: Верно. Это невероятное моделирование, верно? Вроде с точки зрения лидера. А это значит, что он проходит долгий путь. Если лидер так говорит, то конечно.

Шреяс Доши: Да. Ага. И, вы знаете, есть также классическая односторонняя дверь, двусторонняя дверь, которую я действительно видел в Stripe. Это решение, которое мы можем отменить. Верно?

Итак, давайте сделаем это. Это отлично. Если мы неправы, мы просто отменим это. Стоимость его удаления не будет существенной. И затем, возможно, есть другие решения, которые будет труднее отменить, или мы не сможем отменить. Давайте на самом деле потратим наше время, чтобы сделать это правильно. Итак, опять же, все, что я здесь говорю, Джон, кажется очевидным, типа да, конечно, ты должен делать это в большинстве случаев.

Мол, конечно, ты должен это сделать. Вопрос почему этого не происходит? Почему большинство организаций очень несовершенны в этом смысле? И, я думаю, мы с вами обсуждали эту тему несомненного театра. И я думаю, что это во многом связано с психологической безопасностью, которую культура создает, в частности, для менеджеров среднего звена.

Средний менеджмент и «настоящая правда» [00:16:52]

С моей точки зрения, менеджеры среднего звена — это способ организации гарантировать, что вы сможете докопаться до настоящей правды. Есть истина на земле и, и, вы знаете, люди, очень непосредственно работающие над этой истиной. И затем, когда они увидят эту правду, они донесут эту правду до среднего звена. И тогда руководство среднего звена выступает в роли этого доверенного лица, прямо между правдой, которую вы видите на местах. И затем руководители компаний видят правду в макромасштабе.

Поэтому я думаю, что для среднего менеджмента очень важно свободно выражать правду, которую они видят с обеих сторон. Не беспокоясь о том, что их работа будет поставлена ​​под угрозу, или их положение будет поставлено под угрозу, или их карьерный успех будет поставлен под угрозу.

И если они смогут это сделать, то это, я думаю, ключ к открытию лучшего потока правды в обоих направлениях внутри организации.

Джон Катлер: Менеджмент среднего звена — это не просто один слой. Во многих случаях это несколько слоев. Итак, как вы поддерживаете поток истины в обоих направлениях через два или три слоя этого?

Роль продуктового лидерства [00:18:01]

Шреяс Доши: Первое наблюдение заключается в том, что мы говорим не о том, что такое работа и какова роль лидера продукта. Верно?

По моему наблюдению, большинство таких продакт-лидеров, знаете ли, с огромным опытом и отличным резюме. Если вы спросите их, какова ваша роль? Например, какова твоя настоящая роль? Они будут бороться. И я не виню их, потому что, знаете ли, их никто не учил, какова их роль. Так что они просто начали что-то делать, а затем, что бы они ни делали, если это работало, если они получали какое-то внешнее подтверждение, они делали больше этого. А затем они подавили то, для чего не получили подтверждения.

Так каким-то образом пришли к определенному стилю, или определенному подходу, или некоему неявному определению роли. Это теперь так глубоко укоренилось в их привычках, что они не могут точно описать это. Мол, хорошо, моя роль X, Y и Z.

И я думаю, что это так важно. Как только вы понимаете роль, становится ясно, что вам нужно делать, верно? Что вам нужно сделать, так это обеспечить успех продукта через других, верно? Как будто это именно то, что вам нужно делать в качестве лидера продукта в среднем звене.

И для того, чтобы как бы обеспечить успех этого продукта через других, и я говорю об этом с точки зрения создания самоуправляемых команд, верно? Поэтому создание самоуправляемых команд жизненно необходимо. В идеале, как лидер продукта, вы знаете, вы не просто тушите пожары и не любите появляться на восьми обзорах, потому что вам нужно быть там, и вам нужно все проверять, и ничего не происходит без вашего присутствия.

И я знаю, что это реальность многих руководителей продуктов, наша повседневная работа, поэтому часто это очень напряжно. И я достаточно регулярно обучаю многих таких лидеров по продуктам, и для них [00:20:00] удивительно, что так не должно быть. Это не обязательно должно быть так, как если бы вы проводили буквально 40 или 50 встреч в неделю.

Есть такой анекдот, который я слышал много раз. Это похоже на то, что вы руководитель продукта, поэтому вы никогда не будете сидеть за своим столом, верно? Как будто ты всегда будешь на собраниях. Ха-ха. Мы принимаем это как реальность. Я абсолютно отвергаю это предположение. На самом деле, как лидер продукта, вы должны проводить массу времени за своим столом. И если вы этого не делаете, это означает, что вы не выполняете второй аспект своей роли, заключающийся в создании самоуправляемых команд. Верно?

Так что я действительно думаю, что это восходит к пониманию роли. И как только вы поймете роль, ваши действия будут совсем другими в плане того, как вы делегируете, как вы не только говорите, ну, мне не нравится этот подход к этому потоку, который вы мне показываете, но мне нравится что-то другое, а вместо этого скажи: вот, посмотри, вот что я думаю об этом.

Вот как я думаю о целях пользователя. Вот что я думаю о целях конверсии, которые у нас есть. И затем здесь, возможно, есть некоторые принципы для нас, чтобы рассмотреть. Вот, возможно, некоторые показатели, которые нам нужно искать, чтобы выяснить, какой правильный ответ, верно? Например, это разговор, который вы должны вести как руководитель продукта со своей командой, потому что именно так вы создаете самоуправляемую команду, а не о, Боб, Бобу просто нравится поток одной страницы, верно? Например, или одностраничные шаги. И это просто причуда Боба. И поэтому просто убедитесь, что это менеджер по продукту говорит дизайнеру, просто убедитесь, что вы делаете это, верно? Нравится, но причина этого отсутствует. Это больше о том, о, если вы хотите успешно пройти проверку Боба, вам нужно будет сделать это. Правильно. Что бессмысленно, потому что теперь вы создали своего рода противоположность самоуправляемой команде.

Профессиональная идентичность (и переход к лидерским ролям) [00:21:56]

Джон Катлер: Еще одна вещь, которая приходит на ум, это то, что часто менеджеры по продуктам, кажется, наслаждаются этой туманной природой своей роли, начиная даже с IC PM. Они почти идентифицируют себя как оборотни. Типа подталкивают себя ко всему, что нужно сделать.

И я мог себе представить, что этот человек, когда он становится директором, продвигается вверх. Может быть, иногда они не могут отпустить это. Возможно, именно это приводит к невозможности прояснить их роль.

Шреяс Доши: О, знаешь, Джон, то, что ты только что сказал, так сильно резонирует. Я хочу поделиться двумя вещами в ответ на это. Во-первых, у вас есть этот классический пример. И снова это был я много-много лет назад. Это был я 12, 13 лет назад. Кажущийся компетентным продакт-менеджером, кто-то, кто действительно хорош в основной работе по продакт-менеджменту.

Кто сказал, хорошо, мы хотим, чтобы вы управляли PM. А вот то, что происходит в этой ситуации, действительно интересно. И я думаю, если это произойдет со многими и многими компетентными ПМами. Что затем делает их немного менее компетентными лидерами продукта, по крайней мере, первого или второго…

Джон Катлер: Вы хотите сказать, что продакт-менеджеры становятся все менее и менее компетентными по мере продвижения вверх по организации?

Shreyas Doshi: Ну, требования, планка меняется. Верно? Так, например, в моем случае я все еще строил и развивал свой основной набор навыков управления продуктом. Он не был полностью построен, но меня попросили управлять, и это нормально, это происходит и во многих других функциях. Но проблема в том, что мысленно я тоже не был там, верно?

Как будто я знал, что у меня есть эти пробелы, и где-то внутри меня все еще было стремление доказать, что я действительно отличный менеджер по продукту. Не менеджер продакт-менеджеров, но действительно отличный продакт-менеджер. И то, как это проявилось с моей командой, это, знаете ли, что-то происходит, и я говорю, о, это явно не правильный ответ. Вот как мы должны думать об этом. Мол, просто следи за моим языком. Верно? Как будто это слова, которые я использовал.

И что я на самом деле делал, теперь я это понимаю, тогда я этого не понимал. На самом деле я просто пытался доказать себе, что у меня все еще есть это. И пытаюсь доказать и показать другим, например, насколько я хорош в основной работе индивидуального участника IC. Ах, и я вижу это у продакт-менеджеров, особенно в первые три-четыре года, когда они начинают управлять продакт-менеджерами. Они все еще пытаются выполнять роль менеджера продукта, основную роль IC, а не роль менеджера.

И тогда это создает всевозможные проблемы для себя. Потому что, вы знаете, когда вы используете такой подход IC, вы собираетесь быть менеджером, который говорит: [00:25:00] о да, мне нужно пойти на это собрание. Не могли бы вы пригласить меня? Потому что вам нужно это в реальном контексте, чтобы вы могли сформировать свое мнение о стратегии продукта или направлении продукта, верно?

Наоборот, развивать умение понимать это через своих людей. А потом это раздражает человека в вашей команде, потому что это типа: «Почему мой босс появляется на этой встрече?» Это не имеет никакого смысла. И о, мой босс - микроменеджер. Или посмотрите, о, потому что мой босс появляется на этом собрании, мне теперь нужно выступить на этом собрании, а не просто быть уязвимым, задавать законные и искренние вопросы и все такое.

Роль менеджера в том, чтобы помочь людям принять нестандартное поведение [00:25:39]

Я скажу вам одну вещь, связанную с этой темой, которую мы обсуждаем, и которая у меня на уме, это рассмотрение роли менеджера, особенно в контексте управления продуктом, рассматривая роль менеджера, роль директора, роль вице-президента, роль CPO как о том, чтобы помочь людям понять, когда они должны принять свое нестандартное поведение.

Возьмем конкретный пример. Где-то в блоге или, может быть, в твиттере вы найдете что-то вроде «о, вот что нужно менеджеру по продукту…

Джон Катлер: Между прочим, мы могли нести за это совместную ответственность. Так что я думаю, что мы можем,

Шреяс Доши: Абсолютно. Это то, о чем я думаю: «О, я нервничаю, нажимая «Отправить»…

Джон Катлер: …Мне снятся кошмары по этому поводу, так что я воздержусь…

Шреяс Доши: Конечно! Итак, давайте возьмем гипотетический пост в блоге о том, что должны делать продакт-менеджеры. И это похоже на то, что менеджер по продукту поддерживает свою команду. Менеджер по продукту разблокирует команду. Менеджер по продукту согласовывает с командой, что нужно команде, и предоставляет то, что им нужно, чтобы они могли быть эффективными.

Они могут быть эффективными. Менеджер по продукту следит за тем, чтобы они проводили регулярные проверки с отдельными инженерами, чтобы убедиться, что они получают то, что им нужно, бла-бла-бла. Верно. Итак, вы можете представить себе такой гипотетический пост в блоге.

И сказать, что я менеджер по продукту или новый менеджер по продукту, и сказать, что все это имеет смысл. И я собираюсь начать делать это. И, угадайте, что происходит? Вроде начал так делать, и работает отлично. Люди говорят, знаете, Элис присоединилась к нашей команде в качестве менеджера по проектам. И это было потрясающе. Это была разница дня и ночи. Я не могу поверить, что мы работали без PM, и это потрясающе, больше PM, понимаете?

Давайте удостоверимся, что мы признаем Элис за наш вклад в качестве менеджера по продукту, и так далее, и тому подобное. Верно. Хорошо. Работает отлично. Так что теперь происходит? Если я менеджер по продукту, я делаю это своим поведением по умолчанию. Потому что я работаю первый год. Я ничего не знаю об управлении продуктом в различных контекстах.

Я предполагаю, что получаю подтверждение этих действий. Так что я должен сделать столько же или больше этих действий, верно? А теперь переведи меня в другую команду. 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. Верно? 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. Верно? Same product managers, same actions, different contexts. Не работает. 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. Верно? 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. Верно. 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. Верно? 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. Верно. 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. Верно. Or even like thread, like do three jobs on a given day. Верно. 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. Верно. 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? Верно? 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…

Джон Катлер: …а потом ты должен отойти, выпить кофе и, типа, подожди, нам нужно спуститься еще на один уровень ниже.

Шреяс Доши: Хорошо. Верно. И, и вроде того, что я заметил, так это то, что, например, 10 минут в 20 минутах в 30 минутах, есть момент озарения, типичный для основателя. Потому что основатель, как правило, тоже очень близок к тому, что он хочет сделать. Так что, опять же, это одна из тех вещей, где постановка вопроса является главной ценностью, а не обязательно ответом.

Но если вы возьмете примеры, станет яснее, например, Google, и, конечно же, в то время, когда я был там, а это было около 10-10 лет назад, компания была очень ориентирована на инфраструктуру. Это было их неявным фокусом. Когда я разговаривал с инженером и сказал, что это то, что нужно пользователю, как мы можем его построить? Ответ будет, о, это очень интересно. Это удивительная проблема. Я собираюсь построить эту внутреннюю инфраструктуру. Мне понадобится шесть месяцев, чтобы построить эту серверную инфраструктуру. И тогда у вас будет эта функция. И как человек, занимающийся продуктом, я, конечно, подождал бы, но это звучит очень долго, чтобы понравиться, это не массовая функция.

Типа, нет, нет, нет. Вот как мы делаем вещи, верно? Мол, нам нужна инфраструктура. И опять же, нет неправильного или правильного выбора. Я также хотел бы указать на это. Верно. Это как, вы знаете, у вас есть Facebook, который очень, по крайней мере, определенно кажется мне со стороны и от людей, с которыми я разговаривал, это очень ориентированная на показатели компания.

Они принимают решения, основываясь на том, что в значительной степени влияет на показатели. Вот почему Google и Facebook работают совершенно по-разному. Внутренне они действуют совершенно по-разному из-за этой направленности.

Самый простой выбор: о, мы хотим быть ориентированными на клиента. И затем я должен напомнить людям, что, хорошо, если вы, если вы говорите, что хотите быть компанией, ориентированной на клиента, но вы продаете корпоративное программное обеспечение, знайте, что со временем вы на самом деле станете компания, ориентированная на продажи. И опять же, есть примеры чрезвычайно успешных компаний, ориентированных на продажи.

Так что я не говорю, что это обязательно неправильный выбор. Но просто быть преднамеренным в этом и снова привязывать это к своему упрямству, это один из способов смотреть на вещи, верно? Вот как мы делаем вещи. Я знаю, это звучит более негативно, чем должно быть, или это работает для нас, верно? Это работает с нашей культурой. Это работает с людьми и навыками, которых мы наняли, и так далее. И это может быть весьма мощным, особенно если вы делаете это намеренно.

Аналитический и творческий интеллект [00:44:14]


Джон Катлер: Пару раз в нашем разговоре вы упомянули слово «аналитический». А потом вы говорили об альтернативе этому, может быть, о творческом интеллекте. Не могли бы вы немного покопаться в этом?

В частности, я думаю о своей повседневной работе, где мы думаем об измерениях. И одна вещь, которую я заметил, заключается в том, что существует огромная разница между использованием измерения для управления людьми, или управления повествованием, или получением идеального ответа, и использованием измерения для обучения. Они чувствуют себя очень, очень по-разному.

В чем, на ваш взгляд, разница между аналитическим интеллектом и творческим интеллектом?

Шреяс Доши: В основе они строятся друг на друге.

Однако это не так, как большинство представителей отрасли. И я думаю, что практики различных компаний, в том числе очень успешных [00:45:00] компаний, часто склонны считать, что одна лучше другой. И обычно — и опять же, мой контекст во многом связан с компаниями, базирующимися в долине, или компаниями, подобными долинам, независимо от того, где они находятся географически, — мы почему-то склонны рассматривать аналитические доводы как чрезвычайно важные и правильные.

Мы склонны пренебрегать творческим подходом к продукту, а также интуицией, суждениями и различными другими аспектами.

Джон Катлер: Существует двойственность, верно? Например, мы также очень сильно раздуваем инстинкты людей, инстинкты некоторых людей, но я понимаю, что вы имеете в виду.

Шреяс Доши: Да. Так что это интересный вопрос, который, я думаю, снова восходит к основному вопросу, например, почему умные команды с адекватными ресурсами все еще производят посредственные или плохие продукты. Мы забываем, что во многих командах и во многих корпоративных культурах людям очень трудно придумывать творческие идеи. Даже опять же, в очень успешных компаниях в целом.

Где многое из этого начинается? Это начинается на собрании, верно? Итак, вы проводите стандартную встречу по продукту на любом уровне. В большинстве таких компаний вы будете выглядеть намного более компетентным, если покажете пять разных графиков. Вы показываете пару таблиц. А затем несколько качественных выводов. И тогда вы говорите, и поэтому вот что должно произойти. Я не думаю, что в этом есть что-то плохое. Верно.

Но что происходит с таким подходом и таким мышлением, так это то, что вы, следовательно, выводы или рекомендации на самом деле довольно ограничены. Они в этой коробке. Вы не знаете, что они на самом деле, как в этой коробке. Но они есть, верно? Теперь, если вы таким же образом допустите творческий интеллект, что произойдет, если выводы будут содержать некоторые дурацкие идеи, верно? Как что-то, что не следует строго из данных, будь то качественных или количественных. Может быть, это даже в том конверте, как, о, у нас нет твердой убежденности в этом, но мы должны попробовать это. Что происходит, опять же, на совещании, возьмем совещание по обзору продукта, так это то, что менеджер по продукту будет сбит с толку или странно посмотрит, когда он поднимет творческую идею.

Или кого угодно, я просто выбираю менеджера по продукту как одну из ролей, но инженера или кого-то еще. Во-вторых, они, скорее всего, потом получат обратную связь от менеджера лайков, и то, как это будет оформлено, не так уж и много, не привносите творческих идей, потому что никто не хочет говорить, что это будет похоже на то, что вам нужно подкрепите свое предложение данными.

Вам нужно лучше поддерживать вещи, и это отзыв, который я даю вам как менеджеру, верно? Это явление происходит очень регулярно даже в очень успешных компаниях. И это мешает командам создавать продукты, которые на самом деле раскрывают потенциал, ммм….

Джон Катлер: Кто-то недавно сказал, что у нас в компании слишком много решений принимают бегемоты. Мы должны использовать данные, верно? Мы должны использовать данные, чтобы бегемоты исчезли. А потом я сказал: ну, а что произойдет, когда у тебя появится интуитивная идея?

И они сказали, ну, ну, конечно, вы знаете, конечно, мы будем использовать тот же подход. Для этого у нас должны быть все данные. И я такой: смотри, твоя проблема не в бегемотах. Потому что в конце концов вы захотите иметь творческие идеи.

Если у вас есть только одна идея, это ужасно. Если у вас есть 50 идей, это парализует. У вас есть, может быть, три? И мой друг Дэн Норт сказал: нет, ты хочешь семь. Потому что первая, первая — это ваша идея, вторые две, три или четыре идеи в основном поддерживают вашу идею. Итак, вы хотите семь, потому что на четвертом, пятом, шестом и седьмом вы выходите из своей зоны комфорта.

Уровень воздействия, уровень исполнения и уровень оптики [00:49:13]

Шреяс Доши: Да. Одна структура, которую я считаю очень фундаментальной, охватывает большинство контекстов продуктов и, конечно же, все контексты продуктов, с которыми я сталкивался, и которую, я думаю, нам нужно лучше распознавать, — это то, что я называю фундаментальной структурой работы над продуктом.

Итак, мы делаем всю работу с этим продуктом, верно? Как мы должны думать об этом? Что мы думаем об этом продукте? Недавно я пришел к выводу, что существует три уровня работы над продуктом. Есть уровень воздействия. Есть уровень исполнения. А вот и уровень оптики. И многие проблемы [00:50:00] внутри продуктовых команд, продуктовых культур возникают из-за несоответствия или непонимания уровня, на котором мы ведем обсуждение. Или уровень, на котором мы работаем.

Часто вы обнаружите, что один человек в команде работает и думает на уровне воздействия. А другой человек думает на уровне исполнения. Но они не об этом. Они обсуждают мелочи ситуации, верно? Итак, классический пример — PM, который очень много работает. Так сказать, PM, работающий на уровне исполнения, работает очень усердно, несмотря ни на что.

У них не было хороших карт, но они сделали этот продукт, верно? Как продукт является реальностью. Они счастливы. Команда счастлива. Инженерия, управление продуктом, дизайн, наука о данных, все они, люди, работающие над основным продуктом, очень рады тому, что они что-то создают.

Верно. И они выносят это на ваше исполнительное рассмотрение, правильно. Или обзор запуска. Конечно, в обзоре запуска есть какая-то демонстрация. И опять же, тактика не имеет значения, как это делается синхронно или асинхронно. Дело в том, что его пересматривают. У вас есть менеджер по продукту, который работает на уровне воздействия. Итак, менеджер по продукту смотрит на продукт и приходит к выводу, что он недостаточно хорош.

Джон Катлер: Индикатор угрозы срабатывает.

Шреяс Доши: Уровень кортизола повышается.

Джон Катлер: …увеличить…

Шреяс Доши: И продакт-менеджер расстроен, может быть, менеджер продакт-менеджера тоже сбит с толку. Вы представляете, с какими трудностями нам пришлось столкнуться, чтобы попасть сюда? Нам просто должно быть позволено запустить это. Я знаю, что это все недостатки, но нет, нет, нет, нет. Нам просто должно быть позволено запустить это.

Таким образом, проблема здесь в руководителях — они работают на уровне воздействия и думают о влиянии на бренд запуска продукта с таким качеством, которое, скажем, ниже той планки, которую они имели. . И это интересная ситуация, потому что люди сразу же начинают говорить об исправлениях, верно?

Это похоже на то, о, вы знаете, может быть, мы изменим что-то одно или второе — опять же, обо всем этом важно говорить — но прежде всего важно признать это несоответствие. И я также скажу, что это будет сложно для продакт-менеджера, инженера или дизайнера. Людям там будет трудно отметить это, верно, просто с точки зрения психологической безопасности.

Таким образом, чтобы руководители могли работать лучше, и это применимо к людям на всех уровнях, нужно понять, почему команда гордится тем, что они сделали, они на самом деле добились больших успехов. И они работают на этом уровне исполнения. А затем явно выкрикните — вместо того, чтобы типа «ах, это недостаточно хорошо, или это не соответствует планке» или что-то в этом роде — это отлично на уровне исполнения, это не соответствует уровню воздействия, как мы можем достичь вас знаете, лучший результат здесь?

Последнее, что я скажу об этом, как часть примера здесь, это то, что вы обнаружите, что во многих местах люди оптимизируют уровень оптики, когда они работают над продуктом. Генеральный директор, или основатель, или влиятельный руководитель, у которого возникает инстинкт или какая-то творческая идея, которую люди просто проглатывают. Верно? Боб сказал это, так что давайте поработаем над этим, потому что это действительно…

Джон Катлер: …и они были очень решительны. Это как, ну, конечно, они были решающими. Это генеральный директор, и вы все их слушаете.

Shreyas Doshi: Другое дело, что разговоры на стороне, часто, да, я не думаю, что это сработает. Но это то, чего хочет Боб, поэтому мы собираемся это сделать. И это не всегда должно быть сверху вниз, между прочим. Верно? Как это также иногда противоположное направление. Верно? Вы строите что-то, и вы вроде как создаете это как более успешное, чем оно есть на самом деле, чтобы управлять оптикой.

Так я не говорю, что оптика плохая. На самом деле вам нужно управлять определенным количеством оптики, чтобы вы могли точно выразить влияние своей работы и качество своего исполнения. Уровень оптики должен помочь двум другим уровням. И поэтому вам нужно проделать там достаточную работу. Но есть много команд, которые в первую очередь оптимизируют под оптику.

Люди говорят о стимулах и о том, как люди в основном будут следовать им. И так далее. Я не использую язык стимулирования. Я думаю, что более фундаментальный вопрос здесь заключается в том, насколько ваша культура и ваша организация заставляют людей управлять оптикой по сравнению с управлением исполнением или управлением воздействием.

Когнитивные искажения и общий словарный запас [00:54:37]

Джон Катлер: Итак, часть моего путешествия в мир когнитивных искажений, потому что в какой-то момент я увлекся этим. Я начал пытаться исследовать способы, с помощью которых мы эффективно противодействовали когнитивным предубеждениям, даже когда мы знали об этом. И это не сильно повлияло на мою способность бороться с заблуждением о невозвратных затратах каждый раз, когда я сталкивался с ним. Что, по вашему мнению, не сработало, и что сработало с точки зрения [00:55:00] попыток противодействия этим вещам?

Шреяс Доши: Думаю, дело в общем словарном запасе, который вы создаете для команды. И я думаю, что просто общий словарный запас — это просто еще одна тема, которая намного шире, чем просто когнитивные предубеждения, и я думаю, что это так важно.

Если вы хотите, чтобы ваша команда была здоровой или более здоровой, возможно, подумайте о том, какой общий словарный запас вашей команды связан с работой, которую вы выполняете? И я имею в виду не только такие модные словечки, как Scrum или что-то еще, верно? Типа, я имею в виду, нет, нет, нет. Какую лексику вы не видите в стандартной литературе по управлению продуктами, но которой вы собираетесь поделиться с командой? Почему это работает в контексте когнитивных искажений? Кому-то очень трудно сказать, Боб, что ты становишься жертвой ошибки невозвратных затрат, или эвристики доступности, или чего-то еще. В большинстве организаций очень трудно кому-то быть в состоянии…

Джон Катлер: …не стандартная беседа на совещании, о которой вы говорите, это не то, спасибо, да, я хотел бы просто указать на ошибку необратимых затрат… совещание в масштабе закрывается довольно быстро. Если этот человек начнет…

Шреяс Доши: Точно! О, и это как, о, этот человек плохо работает с людьми. Или что угодно. Верно. Как люди получают…

Джон Катлер: …они прочитали слишком много книг. Эм-м-м,

Шреяс Доши: Им присваивают ярлыки. Поэтому я думаю, что важно сделать это известным. Вот почему я не говорю об индивидуальных когнитивных искажениях. Обычно я говорю о наших когнитивных искажениях на уровне команд. Верно. Потому что тогда гораздо легче вести разговор о том, что, как команда, это может случиться с нами. Мы можем стать жертвой заблуждения об ориентации на исполнение. Вот когда мы решаем сделать что-то, что, как мы знаем, легко выполнить, даже если это может быть не та команда для выполнения, но это дает нам удовлетворение от начала. И удовлетворение от создания чего-либо.

Как только вы сообщите всем, а во-вторых, как лидер – ответственность за то, что я собираюсь сказать, полностью лежит на лидере – это сказать: «Послушай, я собираюсь стать жертвой этого». И как группа мы можем стать жертвой этого. Я просто хочу создать ожидание, что мы будем говорить об этом. И мы отметим это, когда увидим, что это происходит.

Если мы отметим это, это не слабость. На самом деле все наоборот. Что мы можем быть в курсе того, что происходит на самом деле, и, возможно, принять лучшее решение или прийти к лучшему выводу. И поэтому я думаю, что общий словарный запас, а затем то, что я только что сказал, является общей ответственностью.

Я вообще ненавижу слово подотчетность, но это вообще отдельная тема. Но мне это нравится в этом контексте, который является своего рода совместной ответственностью команды за напоминание друг другу и себе как команде об ошибках, которые мы можем совершать. Или отсутствие ясности, которая у нас может быть.

В качестве примера, есть проект, которым я недавно занимался, это был чрезвычайно амбициозный проект с большим количеством неизвестных. Я поделился с командой заранее, на самом деле в этом случае я поделился двумя вещами. Один из них был связан с когнитивным искажением, то есть, понимаете, мы, скорее всего, станем жертвой этих, этих, этих когнитивных искажений или командных когнитивных искажений.

И поэтому давайте просто знать о них. Второе, что я отметил, это то, что детали не важны, но это была очень сложная ситуация, в которой участвовало несколько команд, и эти команды не очень много работали друг с другом. Они как будто работали в первый раз.

И поэтому я поделился с ними тем, что одна из главных вещей, которая будет мешать нам здесь, заключается в том, что мы не собираемся быть прямыми и открытыми друг с другом, особенно за пределами этих командных границ. Это, скорее всего, приведет к тому, что этот проект не сработает, чем любые аналитические ошибки, которые мы допускаем.

Я сделал это еще более явным с этой группой. Меня больше беспокоит наша способность хорошо работать друг с другом, быть прямыми друг с другом и понимать точки зрения друг друга, чем что-либо еще. Любые другие виды аналитических вещей, о которых мы говорим, например, о, как мы вписываемся в эти три варианта навигации в этом ограниченном пространстве или что-то в этом роде. Это не будет определять наш успех. Что будет определять наши успехи, так это то, готовы ли мы вести тяжелые разговоры друг с другом об этом? И готовы ли мы слушать друг друга и точки зрения друг друга? Другая тактика, которая мне нравится, это то, что я просто также указываю, я также хочу сказать, что, может быть, вы думаете, что это глупый разговор, потому что он очень пушистый, верно?

Как будто это не аналитический материал. Но если вы так думаете, то моя [01:00:00] просьба — пожалуйста, поговорите со мной об этом. Нам всем нужно быть открытыми друг с другом. Если вы обнаружите, что это бесполезное использование времени, то это первое, что вам нужно сказать мне. И так…

Джон Катлер: Вы предвосхищаете их скептицизм по поводу того, что вы призываете их… Мне это нравится!

Шреяс Доши: Да.

Джон Катлер: По сути, вы пытаетесь охватить все свои базы.

Шреяс Доши: Еще одна вещь, которую я должен был сделать в этой ситуации, это как, потому что, опять же, я не работал с некоторыми членами команды, с которыми мы собирались работать, я тогда организовал, вы знаете, один на один с некоторыми из ключевых членов команды, просто чтобы еще раз подчеркнуть это. Типа, слушай, это моя забота как лидера команды.

И вообще, чтобы узнать их достаточно, чтобы они почувствовали способность и свободу действий, чтобы как бы открыться и поделиться, когда что-то не получается. Итак, вы знаете, это пример действия по умолчанию. Обычно я избегаю таких регулярных проверок один на один, верно? Мы просто продолжаем добавлять, и в какой-то степени это как бы захватывает ваш календарь.

Джон Катлер: Вы бы не завели много друзей, если бы делали это каждую неделю в течение последних пяти лет. Я думаю, что блестящая часть этого ответа заключается в том, что когда люди узнают о когнитивных искажениях, это безумие. Что они делают, так это то, что они всегда такие, ну, это объясняет безумное поведение всех остальных. Ага. Теперь я знаю, почему руководители ведут себя так, а не иначе. Во-первых, когда мы думаем о когнитивных искажениях, каждый сталкивается с фундаментальной предвзятостью атрибуции, верно?

Шреяс Доши: Я думаю, что если вы не хотите верить, если вы как человек или как команда не хотите верить в большинство когнитивных искажений, может быть, это нормально. Пока вы твердо верите в два из них: предвзятость подтверждения и фундаментальную предвзятость атрибуции.

Отношение к информационным панелям как к продукту [01:01:51]

Джон Катлер: Да!

Ненадолго переключаю передачи, я очень давно хотел тебя об этом спросить. У вас было такое отношение к информационным панелям как к продукту. Например, что послужило источником вдохновения для этой мысли?

Шреяс Доши: Это была коллекция нескольких разных наблюдений, которые я делал на протяжении многих лет о том, как используются информационные панели. И как люди в целом, продуктовые команды, думают о дашбордах.

Джон Катлер: …очень аналитические люди, о которых мы говорим.

Шреяс Доши: Да. И это как, о. у вас должна быть приборная панель. Так что хорошо, у меня будет приборная панель. Итак, позвольте мне поделиться парой наблюдений, которые я сделал по пути.

Во-первых, существует множество PRD, написанных о нетривиальной функции или продукте, которые не охватывают то, как будет выглядеть информационная панель для этой функции или продукта. И это нормально. Мол, то, что я прошу, здесь нет в виде подробного макета для этого.

Покажи мне маркированный список, хорошо? Например, вот метрики, которые мы собираемся отслеживать, чтобы понять метрики использования, например, как эта функция используется? Что с этим делают пользователи? И второе — воздействие. Иногда много внимания уделяется метрикам воздействия и недостаточно — метрикам использования.

Джон Катлер: Абсолютно.

Шреяс Доши: Но я бы сказал, что вроде…

Джон Катлер: Не называйте это показателем успеха. Потому что тогда разговор о психологической безопасности! Это все сделано в этот момент. Ключевой показатель эффективности, знаете ли, это…

Шреяс Доши: Да.

Джон Катлер: …неважно на данный момент.

Шреяс Доши: Опять же, словарный запас очень важен. Это отличный момент. Он должен принадлежать менеджеру по продукту или тому, кто выполняет эту роль.

Джон Катлер: Чтобы понять это, нужно много знать предметной области, верно…

Шреяс Доши: Верно.

Джон Катлер: …уникальный характер использования.

Шреяс Доши: И у большинства, у большинства команд есть другая категория метрик, а именно метрика здоровья. Потому что, как правило, инженерные группы удостоверяются, что у них есть правильные инструменты и правильная информационная панель для этого.

Это первое наблюдение, что мы не можем адекватно определить это. Правильно. Итак, во-вторых, давайте предположим, что команда делает это, и информационная панель или какое-то электронное письмо с метриками, мне все равно, что это такое. Как будто что-то строится, что теперь начинает давать вам понимание того, что имеет значение. Как люди его используют, какое усыновление, какое влияние, вот и все, отлично.

Второе наблюдение, которое я сделал, заключается в том, что никто не смотрит на эту приборную панель.

Джон Катлер: Я могу подтвердить эту динамику, основываясь на том, что кто-то, кто предлагает один из этих инструментов, что многие из них похожи на деревья, падающие в лесу. Есть кладбища приборных панелей. Скажем так.

Шреяс Доши: Конечно. Если это вы и ваша команда, не расстраивайтесь. Это 90% того, что я встречал в разных точках. Верно. Ага. Мы потратили все эти усилия на создание этой панели. Вряд ли кто-то смотрит на это.

Итак, это был второй вид наблюдения. Когда я это заметил, я понял: о, подождите минутку. Мы ничего не делаем с нашей панелью показателей, [01:05:00] то, что мы говорим, является правильным для наших продуктов. Так что здесь есть определенный вид самореференции. То есть, вы знаете, если мы создаем продукт, вы ясно знаете, что правильно делать, это отслеживать его использование, отслеживать показатели и так далее.

Итак, если вы просматриваете информационную панель, которая дает вам представление о вашем продукте, почему бы не рассматривать ее как сам продукт. И отслеживайте показатели использования вашей панели инструментов. Как простой счетчик, например. Сколько людей просмотрели эту панель инструментов, на создание которой мы потратили массу времени на прошлой неделе.

Верно? Просто что-то вроде этого, просто количество просмотров, например. И тогда вы можете посмотреть на это и увидеть, о, подождите минутку, на самом деле никто не смотрит на метрики. Так что это создает две возможности. Во-первых, это бесполезно с точки зрения понимания или принятия решений. Или есть какая-то проблема, правильно, как у нас, и что-то вроде того, что нам нужно решить. Но вы можете начать делать это, только если будете думать об этом как о продукте, верно?

Как только вы начнете думать о информационной панели как о продукте, вы, конечно же, создадите требования к информационной панели и сделаете ее частью исходного PRD. Это то, что нам нужно отслеживать. Вот почему мы должны отслеживать это. Вот так и будем отслеживать. И тогда вы, очевидно, будете настраивать вещи на приборной панели таким образом, чтобы понимать ее использование и так далее.

И последнее, что я скажу, это то, что большая часть всего этого не является намерением или компетентностью или чем-то еще. Я не думаю, что это происходит из-за некомпетентности людей. Я думаю, это потому, что это тяжело. Я думаю, что на самом деле это так же просто, как трение, верно? Это еще одна вещь, о которой вы должны подумать в течение своего напряженного дня. Вы знаете, что это правильно. Чтобы время от времени просматривать показатели использования. Или, по крайней мере, обратитесь к ним, когда будете принимать следующее решение.

Но есть трение. Есть когнитивная нагрузка, с которой нужно справляться. Итак, теперь, снова думая об этом как о продукте, теперь вы можете начать думать о нем с точки зрения того, как устранить трение? Потому что это то, что мы делаем в наших собственных продуктах, верно? Например, мы думаем о том, что мешает пользователю и как его устранить?

И это приводит к интересным возможностям. Как одна из привычек, которые у меня были в течение многих лет, на данный момент у меня есть мои закрепленные вкладки в Chrome. И у меня есть электронная почта, Slack и календарь, которые закреплены. Еще одна закрепленная вещь — панель основных показателей. Так что это там. Мне не нужно открывать новую вкладку, вводить любой URL-адрес, он просто есть. Еще я заметил, что людям нравятся метрики электронной почты. Почему? Потому что это устраняет трение, верно? Это просто появляется. И есть своего рода договор, который мы, по крайней мере, заключили сами с собой, что мы должны просматривать электронные письма. Так что в конечном итоге происходит то, что люди гораздо более внимательно смотрят на метрики, которые они получают по электронной почте, чем на метрики, которые они должны активно искать.

Так что часто для важных проектов я бы сказал, ну, вы знаете, давайте просто отправим итоговое электронное письмо. Это может быть так же просто, как некоторые тизерные статистические данные высокого уровня, и просто ссылка на панель инструментов. Даже та ссылка, которая будет отправлена ​​вам по электронной почте, значительно облегчит вам задачу и устранит трения. Вместо того, чтобы думать об этом и делать это.

Заполненные календари, реактивность, самоидентификация и положительные/отрицательные привычки [01:08:20]


Джон Катлер: Когда вы видите эти календари людей, и вы видите этих продакт-менеджеров, которые все время находятся в реактивном режиме. Что у них даже нет времени подумать об этом. Какой первый совет вы им даете? Как они управляют этим?

Шреяс Доши: Первые пять лет своей карьеры продакт-менеджера я провел в крайнем стрессе и постоянно находился в обороне. Мне нужно убедиться, что вещи не развалятся. Это все, что я делаю, и это отнимает всю мою энергию. И я думаю, что большая часть этого, конечно, в том, что я, вероятно, был гораздо менее компетентен в этой роли. И поэтому раньше все занимало у меня больше времени, и так далее. И поэтому я не хочу сбрасывать со счетов то, что существует кривая обучения, и за эту кривую обучения приходится платить. И это путешествие, которое должен пройти каждый. Верно. Так. Ага.

Я не думаю, что это обязательно плохо. Вы используете слово «привычка», и я думаю, что проблема в нем. Это происходит потому, что в эти ранние годы, годы нашего становления в качестве менеджеров по продукту, мы приобрели определенные привычки. Предполагая, что мы на самом деле достаточно хороши в том, что делаем, мы видим успех. И поэтому вы, конечно, думаете: ладно, да, похоже, я поступаю правильно. И поэтому я должен делать больше таких вещей. Это действительно помогает еженедельно встречаться один на один с каждым инженером в команде, узнавать у них, что происходит, а затем также общаться с ними на личном уровне и так далее, и тому подобное. Так что я собираюсь делать все больше и больше этого. Отлично. Это работает, когда у вас в команде 10 инженеров, теперь у вас больше возможностей. Сейчас 20, потом 30. [01:10:00] Что, чем ты занимаешься?

Джон Катлер: Верно? А между тем они гордятся собой, самоидентифицируют себя, что у них такие замечательные отношения с каждым инженером. Чёрная дыра один к одному…

Шреяс Доши: Ага . Итак, Джон I, и я думаю, что это вызвало что-то интересное, то есть, я думаю, возможно, это две вещи. Это привычка и идентичность. Вот кто я. Вот как я делаю вещи, правильно. О, та вещь, о которой вы говорите, или та вещь, о которой говорит этот другой человек?

Нет, нет, нет, нет, это не работает для меня. Верно. Как будто я другой. Это моя личность, это то, как я работаю. Итак, есть привычка и личность. И я все время вижу людей как раз в ситуациях, когда это просто совершенно неуправляемо. Они не знают, что делать.

Они просто думают, что это так. Иногда их менеджеры говорят им, что да, такова работа менеджера проектов. Посмотрите на мой календарь, там еще хуже! И еще есть это небольшое сравнение, которое похоже на то, чей календарь хуже. И типа, этот человек больше PM, верно?

Это так сложно из-за проблемы привычки и идентичности. Людям трудно принять, что здесь есть альтернативный путь. Если вы думаете о зрителях, они слушают это, когда бы это ни было выпущено. Наверняка найдется группа людей, которые скажут: да, все, что здесь обсуждается, не относится к моей ситуации. И это не относится к моей компании из-за моего босса, из-за этой причины, потому что моя команда другая, потому что, чем бы я ни отличался, у меня большие амбиции, что угодно. Итак, вы знаете, я бы сказал, что это не может быть решено, пока вы не признаете, что на самом деле есть лучший способ.

You have to understand that you want to solve this problem, versus thinking this is the way it is. 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. Верно? 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. Верно. 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. Верно. 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? Так…

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. Верно.

Like these, these are the assumptions. Ну вот. 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. Ты прав. 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