Быть продактом!

Первая привычка рационального мышления – «цепляться за факты сильнее, чем за свое мнение». Джулия Галеф называет это «мышлением скаута» (от английского названия разведчиков, а не бойскаутов), похожий подход описывается довольно знаменитой максимой "strong opinions loosely held". Смысл один и тот же: если вы знаете, что карта ≠ территории, то повышение точности описания реальности должно быть для вас важнее чем сохранение собственного мнения о ней. Как сделать такое мышление привычкой? Как и с любой другой рутиной: научиться опознавать триггеры и отвечать на них заранее запланированными поведением и получать за это новое вознаграждение. – Начиная рассказывать свою точку зрения (триггер), не забывать добавлять «я могу быть не прав» (новое поведение) – не просто в качестве мантры, а именно чтобы переключать себя в соответствующий майндсет (результат). – Когда ваше мнение «атакуют» (триггер), не «вставать в защитную стойку», а сначала пытаться как можно лучше понять аргументы собеседника (новое поведение) и если они валидны – не стесняться изменить свою точку зрения (результат). – Прежде чем начинать делать что-то важное согласно своим убеждениям (триггер), вспоминать о том, что стоит рассмотреть альтернативные объяснения, возможности для действий (новое поведение), и начинать только после того как они обдуманы и признаны менее эффективными (результат) [ловушка «аналитического паралича» лежит именно здесь, но каждый рациональный «скаут» знает как ее избегать]. Менеджеру продукта «мышление скаута» помогает не увязнуть в болоте своих иллюзий, а как можно быстрее, в том числе с помощью других людей, добираться до островков реальности. А значит, совершать действия, которые лучше этой реальности соответствуют – и таким образом меньше ошибаться.

Много лет назад я сформировал такое «нефункциональное» определение менеджера продукта: это максимально социально-компетентный специалист по рациональному мышлению. Прокаченные на максимум навыки взаимодействия с людьми нужны продактам, чтобы «экологично» добиваться поставленных целей. Развитые навыки рационального мышления — для того чтобы правильно ставить адекватные цели. Три привычки рационального мышления в следующих трёх постах. Бесплатный «курс» из 10 лекций о том как учиться и быть продуктивным лично и с другими людьми — на сайте.

Ради любопытства (и возможно это мне поможет выбрать что читать после только что законченного «ГЭБа») — какая одна художественная и одна нонфикшен книга оказали на вас фундаментальное влияние? Мои варианты ответа: — «Капитанская дочка» Пушкина (олды угадают, кто был триггером) — после нее я в зрелом возрасте начал с удовольствием читать русскую классику и даже сделал соответствующий хобби-проект. — «Оргуправленческое мышление» Г.П. Щедровицкого — она разожгла мой интерес к философии и заложила фундамент менеджерских навыков. Что так же сильно повлияло на вас?

Вопросы Хэмминга в применении к управлениию продуктами Нам с вами должно быть абсолютно безралично, где Хэмминг работал, кем, чего достиг и т.д. – вопросы, которые теперь носят его имя либо работают, либо нет. Но у меня всегда проблемы с такими "красивыми историями". Их легко рассказывать, они звучат "глубоко", "мораль" этих историй звучит очень привлекательно – все это в полной мери относится к Хэммингу и его «Какая проблема в вашей области самая важная?» и «Почему вы над ней не работаете?». Красиво, нравоучительно, теоретически максимально полезно – и, на практке, почти всегда не достижимо. Проблема таких историй в упрощении. Про какие нюансы можно узнать, если прочитать оригинал: – во-первых, Хэмминг делал очень важную оговорку: мы должны заниматься самыми важными проблемами, "которые мы знаем как атаковать". Если у нас нет возможности решить проблему, то нет смысла тратить на нее время – только нервоз заработаете. – во-вторых, подход Хэмминга работал в очень специальной среде. Почитайте о том, чем была Bell Labs и какие возможности у них были выбирать, над чем работать. – в-третьих, даже в такой среде, большая часть людей, которым авторадресовал такие вопросы во время ланча, в итоге просто переставала с ним общаться. И по делом – заниматься "проблематизацией" решений и работы других людей, если вы не их руководитель, прямой путь к разрушению отношений. Итого, если вы менеджер продукта: – задаваться вопросом о самой важной нерешенной проблеме в зоне вашей ответственности – важно и нужно делать это регулярно, минимум, раз в год, лучше чаще. – если ваша среда (компания) и процессы (стратегия, процесс постанвоки приоритетов и планирования) позволяет – ответ на этот вопрос должен превращаться в питч инициативы, которую бизнес готов поддержать – для этого нужно будет ответить на все обязательные вопросы: "какую проблему видим?", "как объясняем? (гипотеза!)", "что можем сделать? (идеи)", "что для этого потребуется? (эффорт)", "какой эффект ожидаем? (импакт), "есть ли пробелмы с лучшим соотношением затрат к результату?" (альтернативы) – и после этого, когда вы договоритесь с бизнесом, что это главная проблема, которую вы можете решить – останется только сделать это вашим единственным фокусом, что тоже нетривиальная задача И, да, если вы не CPO или не "Хэмминг" (человек с неприрекаемым авторитетом, который не боится потерять статус и отношения) – не приходите к коллегам с такими вопросами, если они об этом не просили. А если вы CPO, то ваша главная задача, сделать так чтобы такой процесс – ответа каждого продакта на эти вопросы и взаимной проблематизации ответов в команде – у вас был.

Продуктивные конфликты Моя вторая любимая (а исторически и вовсе первая и главная) тема для евангелизма – создание и использование продуктивных конфликтов. К менеджменту продуктов это имеет такое же отношение как и к любому другому менеджменту. Сегодня в рекламном объявлени в соседнем продуктовом канале описали отличную историю, чтобы продемонстрировать, в чем смысл продуктивных конфликтов. TL;DR: дизайнер генерирует картинки, арт-директор официально не запрещает, но и не поощряет, компания не хочет органичивать работников, но и не хочет чтобы публика узнала, что часть результатов сделана бездушной машиной. Что делать? Организовывать и использовать ситуацию продуктивного конфликта для вскрытия базовых противоречий – нестыковок в знаниях и представлениях всех участников ситуации. После этого может оказаться: – что всем дизайнерам нужно срочно начать тоже использовать генераторы, арт-директор повысит скилл ревьюера и ментора "художников" (в том числе неживых), а компания захочет трубить об этом на каждом углу или – арт-директор будет вынужден уволить дизайнера-нарушителя, а с остальными подписать поправки к должностной инструкции, запрещающие использование генеративных инструментов или – дизайнер проведет мастер-класс для коллег – арт-директор напишет гайдлайны, четко описывающие кейсы в которых можно и нужно использовать генераторы и как – компания подготовит план public relations, но не будет его активировать, пока не выйдет следующая игра Но в любом случае: – все будут одинаково понимать в чем плюсы, минусы, риски и преимущества использования генераторов изображений – как они соотносятся с задачами компании – как они же соотносятся с ценностями компании и ее отдельных работников – и соответственно как, на каких основаниях и кто принимает решение в этом конкретном кейсе (и каким оно будет). И после этого "никто не уйдет обиженным", просто потому что, когда становится ясно, какие представления сталкиваются, – каждому становится ясно, готов ли он свои представления изменить. И работать можно только с людьми, которые готовы менять свои представления. Но не ценности. Ценностные конфликты неразрешимы. Главное не путать одно с другим )

Вот показательный пример. Сергей Хабаров сегодня рассказывает у себя в канале про образование о самых эффективных школах в США. Оказывается сетью таких школ управляет Министерство обороны. Чтобы бы сделал с такой информацией менеджер продукта, которого научили как можно быстрее проверять как можно больше гипотез? Возможно сказал бы: "Понятно! Чтобы сделать наши школы успешными давайте проверим гипотезу и передадим их на 5-10 лет в управление нашему Министерству обороны!". Но во втором (из трех) постов Сергей приводит гипотезы – объяснительные модели – которые высказывают люди в комментариях к исходной статье NT. Это (почитайте, там интересно) сразу помогает: а) получить набор объяснений – возможных причин – потенциальных механизмов успешности этих школ б) разделить эти механизмы на те, что точно зависят от МО и те, что могут работать и в других условиях в) быстро прикинуть что из этого можно проверить и как (дополнительные исследования, быстрые локальные эксперименты) г) и, конечно, быстро помогают понять, что не стоит торопитсья с идей переподчинять наши школы МО (не зависимо от нашего отношения к каждому из этих институтов). Смысл гипотез в производстве знаний. Из которых складываются модели, обладающие прогностической ценностью. Что в свою очередь позволяет совершать действия, которые с большей вероятностью приведут к желаемому результату. Особенно в условиях, когда на кону большие ставки и риски (как, например. образование целого поколения). В наших продуктах ставки обычно намного меньше, но их последствия для бизнеса могут быть... очень разными. Поэтому чем лучше менедежеры продуктов понимают весь процесс, всю методологию получения и эксплуатации знаний, тем выше шансы, что время и деньги не будут потрачено зря. И, конечно, это все справедливо и для людей, принимающих любые другие решения, в том числе такие глобальные, как о системе образования.

«Проблема остановки» в развитии продуктов Вы наверняка уже видели множество таких примеров, но на этой неделе подоспел очередной, мимо которого мне просто трудно пройти. В математике, «проблема остановки» заключается в том, что даже при наличии описания алгоритма и его входных данных нельзя написать программу, которая скажет, завершится ли выполнение запущенной процедуры когда-нибудь или нет. Звучит контринтуитивно. Для меня, почти так же странно, как "мессенджер-таск-трекер", но именно им сейчас пытается стать Slack. Пытается уже не первый раз и довольно последовательно идет в этом напралении. И никак не может остановиться. С одной стороны, смешение возможностей мессенджера с возможностями трекера задач выглядит логичным: «Мы же здесь уже общаемся с коллегами, почему бы здесь же не трекать задачки?» И я уже не раз видел воплощение такого слак-менеджмента в виде специальных надстроек, использования тредов и закладок и даже был жертвой ТГ-менеджмента, когда задачи прилетали как сообщения в обычной переписке. Пожалуй, наиболее сильным аргументом в пользу слак-менеджмента выглядит такой: «В таск-трекере у нас же уже есть комментарии к каждой задаче, давайте просто соберем все общение в одном инструменте?! Станет понятно, где что обсуждать и ничего не потерятся в частных разговорах». И соседний с ним: «Мы же не готовы перенести все общение в задачи в таск-трекере и избавиться от Слака совсем?» Ок, но! С другой стороны, ключевая ценность таст-трекеров не в задачах и комментариях к ним, а в настройках воркфлоу, связях разных типов (блокеры, зависимости, последовательности), инструментах организации (проекты, доски, спринты) и тайм-менеджменте (дедлайны, трекинг). И все это мгновенно теряется при переносе задач в Слак. И продакты слака, похоже, это понимают и начинают переносить эти возможности в мессенджер. Сначала букмарки (которые могут быть выполнены или in progress), потом заметки (которые можно использовать для описания задач), теперь «списки» – первый шаг к организации задач во что-то напоминающие доски (в качестве проектов уже можно использовать каналы). Следующий шаг – тайм-менеджмент? Потом workflows? Остановятся ли они когда-нибудь? Думаю, что нет. Проблема остановки в приложении к развитию продуктов заключается в том, что публичный (вышедший на биржу), да еще и поддержанный венчурным капиталом бизнес не может перестать расти. И, к сожалению, почти единственный путь к росту, который видят такие продукты лежит в наращивании списка возможностей. Я сам сейчас работаю в компании, которая делает то же самое... И, парадоксальным образом, именно это открывает путь для конкуренции "снизу" – перетока пользователей (которые могут себе это позволить) в решения, которые блестяще решают одну задачу, а не так себе целый набор. Но это уже точно другая история. Мораль: если можете себе это позволить, попробуйте хотя бы задаться вопросом о критериях остановки развития вашего продукта. Ответ может вас удивить )

Если вы вдруг, были на моем вебинаре про гипотезы два с лишним года назад, то поймете референс )) https://miro.com/app/board/uXjVOMCbKzo=/ Но, справедливости рады, версия Никиты лучше и объемнее.