Саша Капустин про продукт, управление людьми и не только.

Ну что, продолжим пост выше, как я обещал. Итак, если единственный "лог", который офлайн генерирует сам по себе, это чек... Значит надо добавлять контрольные события! Пока мы не поставим камеру, датчик в кофемашину или хотя бы пока гость не авторизуется (с чем как бы часто наблюдаются... легкие проблемы, ибо авторизация – большое благо и везение для нас, мало кто это делает, особенно вне мобильного приложения) мы остаемся "без глаз"... Или не совсем? Однако, не будем драматизировать. Кое-что у нас есть: жалобы. И это большая ценность! Однако, жалобы это не финальные данные о проблемах, а верхушка айсберга: на одну поданную жалобу приходится порядка 26 недовольных, которые промолчали и просто не вернулись. В ситуация вообще плоховатая, потому что жаловаться физически неудобно: очередь, обед за пятнадцать минут, что-то пошло не так, да и ну его, "просто не приду больше". Для нас любая жалоба это подарок (мы даже стимулировали жалобы, кек). При этом, отсутствие жалоб не означает отсутствие проблем, возможно, люди просто разочаровались окончательно. Пподдержка (в таком свете) не кост-центр, а наши "приборы". Но жалобы жалобами, а у вас тут жалуются не так часто, как хотелось бы, и нам этого точно недотстаточно для того, чтобы объективно что-то обмерять, оценивать и вообще принимать решение о том, как идут наши дела в бизнесе. Потому мы тут придумали свою систему измерений: получился такой трехслойный пирожок. Первый слой – операционные input-метрики. Скорость обслуживания, точность сборки заказа, чистота, доступность позиций меню, аптайм каналов заказа. Чисто то, что контролируем ежедневно и на что реально можем влиять. Классные метрики, только мерить их – серьезная проблемка. Угадаете, как оценивать точность сборки заказов на выдаче в ресторане?) Чуть позже расскажу, в третьем посте (да-да, все увешаем камерами) 🙂 Слой 2 – голос гостя. Оценки заказов, отзывы на картах, обращения. Термометр, но решения только на нем принимать нельзя, так как обычно пишут далеко не все, отзывы фродятся, и вообще дела с отзывами не так просто идут. Самое последнее, куда прорастают наши тесты и изменения (третий слой) – это возвращаемость когорты первого визита: вернулся в первый месяц, в третий, потерян в шестой. Ну и тут простраивается нормально LTV, и мы можем прикинуть, обгоняется ли шан CAC тот самый LTV, который мы накопили, ну и GMV тоже посчитать из LTV мы можем, да? Казалось бы, все кайф. Но проблема в том, что между слоями месяцы лага: изменения прорастают в ретеншн супееееер долго. Поэтому управляем по первому слою, валидируем корреляции с третьим на когортах и стараемся не обманывать себя вторым. Это другая практика принятия решений, ближе к работе с retention-когортами в подписке, чем к классическим АБ. Ну и личная боль: у нас в экспериментах юнит рандомизации это не пользователь, коих миллионы, а ресторан, и их 1300 (+-). Кластерные дизайны, гео-сплиты, подобранные пары точек, маленькая статистическая мощность, полный кайф, да? Плюс часть эффектов физически нельзя показать половине гостей: чистоту зала не включишь только для тестовой группы. Это конечно не отменяет нормальной методологии, просто все сложнее и дольше: чтобы провести тесты на киоске, где у вас нет конкретного юзера и четкой сесии, надо сплитануться по похожим ресторанам, а не сплитануться между киосками в одном рестике, потому что, банально, один юзер... может походить и позаказывать по разным киоскам, ну например. Или киоски стоят один удобнее, а на другом экран от солнца бликует...). В целом, мы более менее разобрались, на что мы смотрим в метриках. Но соль то в том, что все, что я перечислил надо как-то мерить. А это уже прям сложно, раз уж мы "не в телефоне". Потому в следующем посте я расскажу как мы все это обмеряем, и причем тут AI и что мы вообще делаем. Вот, ждите!

А чтоб добить полезным, я поделюсь с вами своим выступлением на офигенском мероприятии Яндекса – product fest. Разобью на 3 поста, ибо много! Я рассказывал про то, как мы строим лесенку AI внедрений в оффлайне, интересно же? ) Я из бигтеха пришел в офлайн. И столкнулся с оттоком пользователей, но не там, где привык. Пять лет я делал цифровые продукты в Авито: опыт покупателей, реклама, финтех. Теперь руковожу IT в сети из 1300 ресторанов, и мой главный продукт едят, а не тыкают пальцем в телефоне. Ну и первое, что меня встретило: половина гостей не возвращается после первого визита. Как мы это считаем? Постоянник заходит примерно раз в месяц. Следующий уровень активности: один-два визита за квартал. Три месяца тишины, и гость становится кандидатом в отток, включаем реанимацию. Полгода тишины, и он ушёл окончательно. При этом маркетинг работает отлично, новичков приводим много и недорого. Получается классическое дырявое ведро: сверху льём дорогой трафик, снизу выливается половина. Рост на привлечении маскирует проблему удержания. Ловушка, в которую попадали примерно все, я так думаю! Но интереснее не сама цифра, а то, где именно живёт отток.В цифровом продукте мы деремся за каждый шаг воронки: карточка, корзина, оплата. В ресторане середины воронки практически нет. Кто зашёл, тот почти наверняка закажет и поест. Вся драма на краях: придёт ли вообще и вернётся ли потом: теряем мы на возврате. У вас в бигтехе, я так полагаю, залогирован каждый шаг. А у меня две точки касания из семи: заказ и оплата. Очередь, грязный стол, настроение кассира и недоеденная картошка следов в метриках не оставляют, ну кроме... Оттока ) В цифре пользователь перезапустил приложение и забыл. В офлайне это испорченный обед с семьёй за свои деньги. Ошибка эмоциональная, а не функциональная. Да и скорость обратной связи страдает: в онлайне это минуты и часы. У нас недели и месяцы: гостю нужно несколько циклов, чтобы "проголосовать ногами". Зафигачить АБшку и забахать фиче-флаг на 1% трафика? Неа, у меня изменение процесса в 1300 ресторанах, где работают 40 000 живых людей с обучением, текучкой и настроением. Смена от смены...) Отсюда главный тезис про LTV в офлайне: он медленно копится и легко теряется: retention-кривая цифрового продукта плавно затухает, а реактивация стоит копейки, а наша обрывается сразу после первого визита, дальше идёт длинное плато накопления привычки. Десять хороших визитов строят её медленно, один плохой рушит мгновенно, и чаще всего мы об этом даже не узнаём. Я пришёл в компанию с уверенностью, что главный разрыв в цифре: докрутить приложение, добавить персонализацию, поднять конверсии. Оказалось, чинить надо гостевой опыт: чистый стол решает покруче "чистого CX", без шуток. Это у нас подводочка, а вот следующем посте уже будет то, как измерять продукт, у которого из телеметрии только чек. Вторая часть попозже! А не третьем куске уже будет... Лесенка AI внедрений и что мы делаем )

Привет, ребятушки. Анонс выступления, получается! Внезапно, я выступаю на ProductSense’26 (10–11 сентября). Я думаю вы знаете эту конфу, а я познакомился с ней в день моего переезда в Москву, когда оказался с Юрой Агеевым на сосдених местах в самолете. Ну тогда и захотелось выступать, рассказывать что-то интересное и в целом быть полезным для комьюнити. Чем и занимаюсь, получается. Продолжаю тему полезного, надеюсь оно такое вам и будет, расскажу вам про то, как оставаться востребованным менеджером продукта, когда базовые навыки – исследования, гипотезы, метрики, приоритизация уже сегодня доступны любому: новичок с правильным запросом к ИИ закрывает такие задачи за 5 минут. А чего тогда качать то и как остаться востребованным? Короче, если у вас тоже возникало ощущение, что барьер входа в профессию упал почти до нуля и непонятно, и черт пойми, за что вас теперь должны нанимать и повышать – это как раз то, о чём хочу поговорить: разберём, что в новых условиях становится настоящим конкурентным преимуществом, и как выглядит карьерный путь в профессии, которая меняется быстрее, чем выходят новые курсы. Помимо моего доклада будет ещё 40+ докладов и 20+ мастер-классов от коллег из разных компаний – так что будет из чего выбрать, если решите приехать на конференцию. Конфа клевая, приходите! 👉🏻 Подробнее о моем докладе и остальной программе. Будет здорово увидеть вас, пообщаемся после выступления!

Привет, ребята! Было очень много запросов, я просто не успеваю всем нормально ответить. Самый частый запрос был: "когда стартуем точно?" Я точно узнал даты: пары стартуют на неделе с 26 октября. Домашки, очевидно, надо будет проверять со следующей недели - со 2 ноября. Делать все это будем 7 недель, ну, то есть, до нового года, почти. Я прошу прощения, что прошлый пост был такой "размытый", и что я не со всеми связался. Во-первых, я плохо сформулировал запрос, и у меня оказалось около 180 (спасибо за это, кстати) сообщений формата "я готов, а что там делать". Как вы понимаете, ассистента я ищу ровно за тем, чтоб на такое отвечать на курсе от студентов, потому ожидать, что я справлюсь, было наивно, соглашусь ( Во-вторых, там почти нигде не было резюме. Я начал их спрашивать и утонул снова в сообщениях. Короче вышло плохо. Не справился я, вот. Потому я сделаю форму в гугле, вы меня простите, кто писал, а я не пришел. Форма простая: имя / фамилия, ваша телега, ваше резюме, желаемая позиция (они выше описаны: старший ассист курса и ассисты на домашки). Позиции очень разные, потому выбирайте сами, пожалуйста, исходя из вашего желания. Более того, там будет галочка "хочу работать безотносительно курса и препода" для тех, кто готов в ЦУ подключаться на другие программы. Еще раз, я прошу прощения у вас за суету и "вторую попытку", очень благодарен за ваши первые сообщения, и, если я не ответил, это не потому что я козел, а потому что меня завалило и я слишком невовремя уехал в отпуск, похоронив шансы все это разобрать. Урок мне, получается. Если я вам ответил и забрал ваше CV, это не значит, что вы не подошли: я просто хочу по честному всех отобрать и представить универу, плюс появилась возможность попасть на разные курсы (тоже продукт). Ссылка на форму тут: https://forms.gle/CtbJYdZH7d2YaVA57 Вопросы пишите сюда, или мне в ЛС, всем отвечу. Кто присылал CV уже… продублируйте, пожалуйста. Э не обязательно, если что, но поможет систематизировать все.

Вакансии (почти!) Я тут собираюсь начать преподавать в универе. Докатились! Ну а куда еще бы меня привели мои курсы и выступления? Буду преподавать в Центральном университете и вести свой авторский курс по финтеху (на который я всех вас звал в закрепе, а теперь оно вообще в образование попало! Вот! А я говорил, что курс крутой. Правда пошло с изменениями, но студенты не вы, а вы не студенты, и преподов ростер тоже другой). Так вот, о чем я. В универе надо делать много чего. Прям очень много. Почти все делаю я, это из хороших новостей. Но мне равно нужны всякие полезные люди, а то я лопну: - человек, который будет помогать мне в течении 2х месяцев общаться с студентами, организовывать работу и это все. Смотреть как делаются домашки, и как они проверяются ассистентами курса. Это не фул тайм, конечно. Такой, старший ассистент. Требований кроме адекватности, пунктуальности и желания вместе поработать нет. Ну и из продукта быть. Так что есть. - человеки, которые будут проверять домашки. Студентов 40-50, они делают домашки. Домашек 5 и общий кейс. И это надо проверять. Как хотите, хоть клод все сделает, хоть вы, но отвечать за проверку вам: если студент не согласен, то вместе отдуваемся. Тоже не фуллтайм, конечно. Требования как и в пункте выше, только больше в продукт и меньше быть злым полицейским. Если хотите поковырять кейсы, пообщаться и поработать с студентами, ну и со мной, велкам в личку. Все оплачивается по белой, детали в лс. Велкам Обновлено: Мама родная ! Очень много вас! Буду завтра отвечать!!!

Продакт-менеджмент больше не профессия. Это "база" И я реально считаю, что это проблема, если ты продакт, особенно старый. Все, чему мы с вами научились– RICE, дабл даймонды, работа с роадмипами и тд уже давно перестало быть конкурентным преимуществом вас как спеца и стало просто гигиеной. Марти Кейган называет большую часть PM-работы в крупных компаниях "product management theatre": продакты фактически делают работу project manager и AI тулы обострили это противоречие. Сегодня иишки отлично закрывают задачи миддла: пишут стори, синтезируют фидбек, анализируют метрики, строят варианты приоритизации. То, на что у меня когда то уходил день,а то и два (пойди разберись во всех сигналах!), теперь занимает минут 15. Сюда же отлично стреляет текущий рыночек: где нет роста, там и продакт не нужен. Фокус на эффективности, руководство забирает стратегию "наверх" (все чаще и чаще слышу от менти про директивное управление), а продакт становится исполнителем спущенного. Нет RnD, не нужен и продакт. Так о чем я тут, не страха же нагнать? Я вижу, что роль меняется, и "продакты которые умеют все" уже не так нужны, так как это все... Или не нужно бизнесу, или легко зменяется. Я активно поковырял линкед и вакансии, и вот что вижу по "новым типам продакта": 1 Builder-pm – AI-native, сам прототипирует и шипит, граница с инженером намеренно размыта. LinkedIn убрал программу Associate PM и заменил ее треком "Product Builder" с ротацией между продуктом, дизайном и кодом. 2 Integrator-pm – кросс-функциональный, работает в сложных прдуктах на стыке нескольких "джобов", где выравнивание команд по-прежнему остается человеческой задачей. И это все больше похоже на РММ (если это запуск на новые рынки, например), или на проджекта (ага). И вроде все, бросаем "флаги и профессию", но, имхо, остается одно, что не автоматизировать и это остается ключевым скиллом: judgment. Это не просто "насмотренность", это конкретная способность принимать решения на неполных данных, мутных приоритетах и новых рынках. Если вы спрашиваете у AI "что делать?" и внимательно втыкаете в ответы, у меня плохая новость. Если вы синтезируете контекст, сами делаете вывод и задаетесь вопросом "какие здесь риски, которые я не вижу?", то дела наши хороши. Потому что AI это не решение, ну пока, а еще один фактор анализа. Имхо. Для меня judgment, как скилл, состоит из трех частей: Оценочная – сказать "это хорошо" или "плохо" до того, как есть данные. В иностранной тусовке это называется product sense: способность формировать видение и принимать решения там, где метрика еще молчит (чуйка, ага). Качается это тысячей кейсов и сочетанием насмотренности с пониманием рынка и трендов. Контекстная – понимать, почему этот рынок, эта команда, этот пользователь ведут себя именно так. AI умножает экспертизу, но не производит ее, и без доменного знания проверить AI-вывод в неопределенности не выйдет, как и дать оценку. Стратегический – видеть, что важно через 12–18 месяцев, когда данные этого еще не показывают и делать ставки на неочевидное. Или уметь сказать "нет" хорошей идее в плохой момент (а это вообще страшный "баг" многих продактов). Из забавного HBR тут недавно написал, что AI забрал повторяющуюся работу, на которой раньше строился judgment у джунов. Они лишились возможности учиться на ошибках неправильной приоритизации, плохих исследований, и последствий, и понимания, почему так вышло. А без этого цикла откуда возмутся синиоры?.. 7 июля в 19:00 проведу открытый эфир совместно с Центром «Пуск» МФТИ «Как AI меняет карьеру продактов, разработчиков и специалистов по работе с данными (Data Science)». Проходить будет для студентов и абитуриентов (у МФТИ есть онлайн-магистратура «Науки о данных» для тех, кто хочет глубже разобраться в DS/ML, работать с реальными задачами и при желании сделать стартап, корпоративный проект или исследование как диплом). А еще я вас зову, если вам интересно! Обсудим в деталях все написанное сверху. Встреча открытая, приходите послушать! Регистрация: https://t.me/mipt_events_bot?start=dl-1782383568273

Сегодня начал день с того, что вылез из мусорного контейнера. Ну и понятное дело, что до этого я туда залез. Видеть глаза таксиста, который подъехал, и увидел меня в белой майке и кроссовках (а штаны песочные!), вылезающего из помойки, и марширующего к нему – отдельное удовольствие. Ладно не уехал от меня. Заслуженная пятерка и чаевые. В помойке я оказался не из-за ИИ и сокращений в IT, а потому что я выкинул ключи вместе с мусором (а какая была бы статейка!). А сделал я это потому, что у меня кончился запас "прочности" мозгов и я конкретно перегрузился работой, на которой мы за последнее время: 1) запустили за год новый апп для Ростикс (это вообще нифига себе задачка, как бы вам не казалось, что нет) и причем не уронили никаких метрик (вообще шок) 2) прикрутили рекомендашки и начали двигать "всякое МЛьное" в оффлайн, что вообще еще сложнее, чем запустить апп. Кто расскажет мне как проводить АБ тесты на киосках в ресторанах, учитывая что нормально сплитануть надо... Людей (а как идентифицируем, лояльность и логины около 30%?)? Железки? Сессии? Рестораны? Короче, это мясо! 3) перестраиваем в корне историю про гостевой опыт в оффлайн и делаем его ультра-диджитал (хе-хе) и добавляем просто сумасшедший уровень обзервабилити?.. (спасибо AI, да-да...) 4) SLA 99,97 сам тоже не дается на такой огромной махине с немалым RPS 5) полностью перекроили все команды (их много) и процессы вокруг продукта, и занимаемся командами в данных и корп системах И это малая (процентов 15%) часть вещей, которые происходят, и которые я держу в своей уже не совсем продуктовой голове. Еще аудиты, налоги, HR процессы (это тоже у меня в голове, угу). И вот ключи и полетели в контейнер, получается. При этом, я все равно уделяю важную часть нескольким вещам, и буду уделять: 1) я продолжаю учить. Свое свободное время я посвящаю во многом этому, ничего не жду в ответ (правда недавно мне сказали "спасибо, я у тебя учился когда-то, теперь у меня крутая работа и меня ценят, и ты помог туда свернуть". Я был страшно горд собой, если что). Буду читать курс по финтеху в ЦУ в следующем году студентам (адаптированный, тот самый, который делаем с Мишей Колосковым из Авито) 2) я продолжаю учиться. Я разучился решать продуктовые кейсы, и умею только вас тренировать. Начал сам, а то продукт ускользает от меня, и мне обидно. Хотя я шарю теперь во многом больше, но специальность надо держать, считаю 3) у меня был план попасть в пару СД или бордов, который с треском провалился, потому что я лох (зачеркнуто), и не вышло пока упаковать свой УТП, несмотря на прикольный опыт. Я радостно помог паре клиентов на консалте, с треском (и бесплатно) профакал еще парочку, получив опыт "куда не надо идти точно помогать" и "где я точно не помогу" 4) я думаю, как вести канал, чтобы снова сделать его прям продуктово-бизнесовым, и набабахать потом альманах "лучшие продуктовые байки от Капустина" 5) буду скоро выступать на паре крутых конференций: в июле у своих друзей, и в сентябре у других. Там и увидимся Последнее время, не знаю как у вас, ввиду турбулентности рынка и, в целом неожиданных сложностей на нем, у меня пропало четкое понимание "а что дальше", и я действую по налаженной программе, перестраивать которую "на ходу" очень сложно. Надеюсь, получится адаптироваться. А в канал так и буду писать всякое полезное, чтобы помочь в чем-то адаптироваться вам. Пацанский коммит – написать про запуск новой мобилы на живом трафике (делал не я, я рядом стоял) и написать про оффлайн и тесты в нем. Ну и еще хочу статью про гостевой опыт бабахнуть, тоже интересное. И статьи будут, есть еще в загашниках (статья про велосарай выше, кстати, неожиданно зашла многим из вас, спасибо за отзывы!) недописанное, пусть и не собирает лайкасов, и собирает отписки. Ну и интервью хочу вернуть. Жанр хороший. Заходите сами, давайте поболтаем, если у вас есть темы! Ждите, и классного вам вечера!

(часть 4 статьи выше) Начало тут https://t.me/productanddot/334 Культурные изменения 1 Нормализация неопределённости (а я часто про это пишу!). В командах, где bikeshedding процветает, часто есть неявная норма: «хорошее решение должно быть обоснованным по всем параметрам». Это создаёт тревогу перед большими решениями и компенсаторную уверенность в малых. Лидеру нужно явно демонстрировать, что признание неопределённости – признак зрелости, а не слабости. 2 Разделение решений по стоимости обратимости. Джефф Безос описал это как решения «одностороннего» и «двустороннего» входа. Решения, которые можно отменить (двустороннее) – принимать быстро, делегировать, не тратить коллективное время. Необратимые – обсуждать медленно и структурировано. Сделать эту классификацию явной частью культуры команды. 3 Ретроспективный аудит времени. Периодически анализировать: где реально тратилось время команды за последний месяц? На что ушло больше всего синхронного времени? Соответствует ли это приоритетам? Одно только это упражнение часто меняет поведение. Важно, что bikeshedding не означает, что детали не важны. Важны. Плохой нейминг накапливается в технический долг. Плохой UX-копирайт снижает конверсию. Проблема не в предмете дискуссии, а в диспропорции: когда усилие и время не соответствуют весу решения. Кроме того, иногда за тривиальной дискуссией скрывается настоящая проблема. Если команда часами спорит о названии фичи – возможно, она не понимает, для кого эта фича и зачем. Bikeshedding может быть симптомом нерешённого фундаментального вопроса. Как итог скажу, что закон тривиальности Паркинсона описал шестьдесят лет назад то, что до сих пор ежедневно происходит в тысячах команд и я постоянно вижу это у себя в практике, и замечаю за собой. Мы тяготеем к тому, что понятно, безопасно и даёт быстрое ощущение завершённости – и избегаем сложного, неопределённого и рискованного. Это не баг командной динамики, это фича человеческой психологии и попытка показать свою важность, "вставив" что-то ну очень (нет) ценное на совещании, где, как вам кажется, промолчать нельзя. Понимание этого механизма – уже половина решения. Тимлид или продакт-менеджер, способный распознать паттерн в моменте и назвать его вслух, возвращает команде фокус без конфликта и без потери времени. Остальное – вопрос системы: структуры встреч, явных критериев остановки и культуры, в которой признание неопределённости не воспринимается как слабость.

Ну, а что там в практике ? (часть третья статьи выше! Начало тут https://t.me/productanddot/334) Bikeshedding принимает разные формы в зависимости от контекста: В разработке: — Многочасовые code review с комментариями о форматировании вместо обсуждения логики или подготовка тех доков "по формату" — Споры о названиях переменных, файлов, коммитов — Бесконечные дискуссии об инструментах (IDE, линтеры, CI-система), пока реальная задача стоит В продуктовом менеджменте: — Груминг, на котором половина времени уходит на уточнение формулировок в тикетах, а не на приоритизацию — Долгие обсуждения дизайна кнопок на экране онбординга при нерешённом вопросе о стратегии развития продукта — Совещания по планам на квартал, превращающиеся в редактирование описаний фич В управлении: — Совет директоров, принимающий многомиллионное решение за 10 минут и тратящий час на выбор места для корпоратива — Стратегические сессии, захваченные дискуссией о дизайне слайдов А как починить? Перед тем как внедрять практики, нужно признать симптомы: 1 Встречи регулярно заканчиваются без решений по ключевым вопросам, зато с детально проработанными второстепенными 2 Один и тот же нетривиальный вопрос возникает на нескольких встречах подряд без продвижения 3 Участники с наименьшим контекстом в теме говорят больше остальных 4 После встречи у команды ощущение продуктивности, но нет конкретных договорённостей по важным вещам 5 В задачниках много «быстро решённых» тикетов и мало прогресса по ключевым эпикам Структурные практики, чтоб избежать таких "обсуждений не важного" 1 Явное распределение времени по важности. Перед встречей назначайте вес каждому пункту повестки – и буквально: «на этот вопрос – 25 минут, на этот – 5». Публичный таймер резко сокращает тривиальные дискуссии. 2 Метод «достаточно хорошо» (good enough). Для решений с низкой стоимостью ошибки явно формулируйте критерий остановки: «нам нужен любой разумный вариант, а не оптимальный». Это снимает психологическое разрешение на бесконечный спор. 3 Ограничение права участия в дискуссии. Для технических решений ввести правило: только те, кто будет реализовывать или нести ответственность за последствия, участвуют в обсуждении. Остальные могут оставить письменный комментарий заранее. 4 Асинхронный режим для деталей. Детальные вопросы (нейминг, форматирование, копирайт) решать асинхронно в письменном виде. Синхронное время слишком дорого для вещей, которые можно обсудить в комментарии. Фасилитационные техники 1 Именование паттерна в моменте. Когда дискуссия уходит в bikeshedding, прямо назвать это: «Кажется, мы сейчас в велосипедном сарае. Давайте вернёмся к реактору». Общий словарь снижает напряжение – это не критика, это наблюдение. 2 Техника «паркинг-лот» (parking lot). Видимый для всех список вопросов, которые важны, но не для текущей встречи. Даёт участникам ощущение, что их мысль зафиксирована и не потеряется, – и позволяет двигаться дальше. 3 Явное назначение «хранителя фокуса» (scope keeper). Один человек на встрече имеет мандат прерывать обсуждение, которое ушло в детали. Ротация роли снижает ощущение иерархического давления. (окончание ниже)

(часть 2ая статьи выше https://t.me/productanddot/334) ...Разбираемся! 1. Асимметрия когнитивной доступности Человеческий мозг устроен так, что легче рассуждать о конкретном, чем об абстрактном. Выбор реализации, например "что юзаем: PostgreSQL и MongoDB" – это разговор о схемах, запросах, типах данных. Оценка стратегического риска масштабирования на пять лет требует удержания в голове множества неопределённых переменных одновременно. Первое комфортно, второе – когнитивно затратно. Мозг склонен к когнитивной разгрузке: он нативно тяготеет к задачам, где ощущение прогресса достигается быстро. Обсуждение цвета кнопки даёт немедленный выхлоп – решение можно принять прямо сейчас. Обсуждение дальней стратегии развития продукта – нет 2. Иллюзия компетентности и страх исключённости В фуллстек команде каждый обладает разным уровнем экспертизы в разных областях. Когда обсуждается сложный архитектурный выбор, новый член команды, продакт без технического бэкграунда или дизайнер могут не иметь содержательного вклада – и это дискомфортно. Тривиальный вопрос уравнивает: мнение о расположении элементов в интерфейсе или о названии переменной может высказать любой. Участие в дискуссии сигнализирует о вовлечённости и ценности, а молчание – нет. Это создаёт стимул к участию там, где участие легко, а не там, где оно нужно 3. Статусная динамика и безопасное несогласие В иерархических командах не принято открыто оспаривать стратегические решения, принятые сверху. Высказаться о выборе микросервисной архитектуры, которую предложил CTO, психологически рискованно. А предложить другое название для фичафлага– безопасно. Оба несогласия являются актом автономии, но только одно из них несёт социальные последствия. Bikeshedding, таким образом, частично выполняет функцию замещённого инакомыслия: команда находит арену, где можно спорить без риска 4. Эффект завершённости и прогресса Исследования в области поведенческой экономики показывают, что люди переоценивают ценность завершённых действий и недооценивают незавершённые. Закрытый тикет с правкой копирайта создаёт ощущение продуктивности. Три часа размышлений над архитектурным компромиссом не особо, даже если второе принесло в сто раз больше пользы. Этот эффект усиливается в командах, где метрики продуктивности измеряют количество, а не качество решений 5. Коллективный паралич перед неопределённостью Сложные решения содержат неустранимую неопределённость. Сказать это вслух – признать, что команда может ошибиться. Уход в детали создаёт иллюзию контроля: мы не знаем, правильная ли это архитектура, но мы точно можем определиться с дизайном или неймингом переменных, да? Ну, а как лечим? (часть третья ниже!)...

А сегодня вам от меня статейка на тему bikeshedding, или почему команды тратят время на не важное, когда есть реально острые задачи. Статья в 4х частях, и это первая, а остальные ниже. Если вам не актуально, смело скипайте все 4 поста, хотя, как по мне, тема "живая"! Тема остро встала сразу в нескольких моих контекстах: 1 Я часто на совещаниях (всяких уровней) вижу, как коллегия уважаемых специалистов спорит на тему... ну вообще не важную, и уделяет этому большую часть времени встречи, когда на важное времени уже не остается. 2 Команды разработки тратят время на бесконечные технические документы и всякие "а если ..., то что будем делать?", причем весьма в странных кейсах, типа "у нас RPS 100, а вот если будет 1000000 что будем делать?" (а не будет, такого трафика нет просто) 3 Команда продукта бесконечно обсуджает дизайн, а УТП доказанного у продукта нет (один из примеров) 4 Мой друг из крупного бигтеха пожаловался мне на это, с хорошими примерами, когда тех менеджмент просто до смерти долбит "рядовых" по каким то тех докам, вместо реально реализации, до которой еще и не доходит часто. А команда выгорает и демотивируется От чего так выходит? Давайте разбираться в моей мини статье, которую я готовил давно для выступления, и обновил для вас сейчас. Начнем со скучного: с теории. Так откуда взялся термин и причем тут велосипеды? В 1957 году британский историк и теоретик организационного управления Сирил Норткот Паркинсон описал закономерность, которую он назвал законом тривиальности (Law of Triviality). Суть его проста: в организациях непропорционально много времени уделяется вопросам, которые легко понять, и непропорционально мало – тем, которые действительно важны. Паркинсон иллюстрировал это воображаемым заседанием комитета, на котором рассматривались два вопроса: строительство атомного реактора и строительство велосипедного сарая при офисе. Реактор стоил миллионы, имел сотни технических нюансов и был понятен лишь узким специалистам. Комитет одобрил его за восемь минут – члены просто не знали, что возразить. Сарай обсуждался три часа: у каждого было мнение о материале кровли, цвете стен и расположении входа. Термин bikeshedding популяризовал разработчик Поул-Хеннинг Камп в своём письме в рассылку проекта FreeBSD в 1999 году. Он применил его к разработке программного обеспечения, наблюдая, как сообщество часами спорило о незначительных деталях, игнорируя архитектурные решения с долгосрочными последствиями. Важно понимать, что bikeshedding – не проявление некомпетентности. Напротив, он часто поражает именно умные и вовлечённые команды, а причины не совсем тривиальны. Разбираемся! (часть 2 следует далее)

Знаете что я заметил в своей деятельности больше всего в свете развития ИИ? 1. На обучениях я даю уже не теорию просто, а сделал фокус в кейсы и практику. Потому что теория ищется очень легко, а ценность теперь особенно в живых кейсах. Всегда их давал, а сейчас на них все и строю 2. Я больше не гуглю. Ни инструкции. Ни гайды. Ничего, все через умный поиск 3. Стадия Дискавери в товарах («какие колонки лучше для комнаты 20м2») теперь ушла чисто в ИИ сценарий 4. Рутину и всякие скучные материалы готовлю теперь не я 5. Разработчики часто не могут объяснить что они делают и как. И продакты тоже 😂 Это прям из очевидно забавного, я вам скажу. Не считая всякого «накодить что-то быстро» и «найти корреляции в данных». Еще я стал очень сильно хихикать с того, что все братья продакты, кто консалтит, теперь консультанты по ИИ поголовно. И каналы все переименовали даже. И компании свои. Хайп, батюшка, все едет и едет. А у вас как? Что я упускаю?)

"Как ты спокойно выступаешь на +- любые темы?" Частый вопрос от коллег, от частотных слушателей (такие совпадения бывают), да и вообще от всех сочувствующих. Есть три сценария: 1. Я это уже рассказывал. Аудитория другая, тема старая. У меня есть "мастер преза" на 700+ слайдов, из которой я могу собрать +- любой рассказ про продуктовый процесс и его составляющие. И рассказать. Это не сложно, я все делал это сам руками, и помню. 2. Я рассказываю "историю": какой-то кейс, какое-то +- авторское мнение и вообще что-то, что знаю только я. Ясен красен тут не ошибиться, все это превращается в веселый стендап и я этот жанр люблю и практикую: мне нравится, и слушателям, как правило, тоже. 3. Я ВЫСТУПАЮ не спокойно. Не частый сценарий, и, обычно, он происходит тогда, когда я 1) Промахнулся с темой, и плохо встроился к прошлому выступлению (это бывает в обучениях в рамках целой программы). Такое происходит тогда, когда я, по какой-то причине, не уделил внимания проработке именно встраивания себя в программу, ну или предыдущий лектор поступил аналогично. Пару раз выходил, когда все рассказали по моей теме до меня, ну и приходилось на лету переобуваться и уходить от теории к практике, превращая ее в что-то кейсовое или стендап на тему как я накосячил или что-то вот такое. Работает нормально, но очень тяжело на ходу рожать все заново, по-сути. 2) Промахнулся с аудиторией. Самый частый кейс, на самом деле. Я вот вчера, ранее радостно получив бриф на выступление про метрики для инвесторов ("как оценивать стартап, метрики и экономику продукта в частности"), решив что все звучит изи, пришел рассказывать профессионалам рынка (серьезная была аудитория очень) инвестиций что такое CAC/LTV баланс, какие метрики на каких стадиях развития продукта важны и нужны и как собирать аналитику. Это как сварщику про сварку рассказывать: будет интересно, но скорее вам, чем ему :) Пришлось на ходу добавить лейтмотив "я продакт, я инвесторам циферки рисовал, сейчас расскажу на что там смотреть, и где можно кинуть", ну и делать это в течении 30ти минут до выступления, чтобы аудитория совсем не заскучала. Мне понравилось выступление, не понравилась моя подготовка, и очень понравилась аудитория. Какие-то советы, не очевидные, я дать не смогу, вот вам очевидные: • узнайте хорошо аудиторию, запросите профиль. Обычная продуктовая работа, боли / решения, УТП / ЦА и проч • узнайте, как вы встраиваетесь в общую конву дня, что уже рассказывали аудитории и какие были отклики • если что-то пошло не так, рассказывайте про самое важное: про практический опыт, в поле рассказываемой темы, который у вас есть. А если его нет, чего пошли рассказывать :)   • Боитесь? Начните с разговора с аудиторией, чтобы разогреться. Поделитесь своим опытом, авторским мнением, смешной ситуацией по теме и вообще устройте смолл-чат с аудиторией. Помогает мне. Ну или просто скажите "господи какая крутая аудитория, аж страшно". Мне подобное признание помогает снять нервоз. Может и вам поможет. • Репетируйте. Если даже рассказывали 100 раз. Время жмет, будет душно в аудитории, вы поругаетесь с таксистом по дороге, надо быть на 100% готовым. • Ну и понятное дело: надо выспаться до :) У меня после слабого сна вообще не работает голова. Я не могу быстро "переобуваться" и думать, от слова совсем. А может пригодиться. • Не фокусируйтесь на всей аудитории (!!!). Чисто мое из опыта. Всегда будут те, которым скучно. Им не из-за вас скучно, а просто по жизни, например. Всегда будут люди, которые уже знают, что вы рассказываете. Всегда есть те, которым тупо все не нравится. И всегда есть те, которым интересно, которые реагируют, одобрительно кивают и тд. Рассказывайте для тех, кому важно, а они вас поддержат своим вовлечением и реакцией. Понятно, что "терять" аудиторию не надо, вы же на нее работаете, но пытаться угодить всем и реагировать на раздражители – путь к нервам, и плохому рассказу. Будьте благодарным слушателем, это очень помогает тому, кто выступает! А ему сложно. У вас есть какие-то трюки, которыми вы пользуетесь на питчах, выступлениях, лекциях?

А вот и догоняю обещанной презой по экономике / метрикам и вот этому всему. Не знаю, будет ли она вам полезна, и вообще читаемо ли это без моего стендапа в параллели, но я не буду расстроен, если кому-то из вас оно пригодится, а то я давно что-то не выкладывал вам тут чего-то 🙂 Ловите вот тут https://docs.google.com/presentation/d/1St39MV1-6qVuen7k0dSXEiSYD2mopbkMhbWLYPaKCuk/

Сижу занимаюсь лекцией по оценке стартапов, ну а что вы хотели! Я тут все пытаюсь найти время писать, но оно пока не находится. Как так вышло, что в воскресенье я не отдыхаю? Пришли ко мне тут и говорят, а давай расскажем про экономику продукта будущим инвесторам так, чтоб они все поняли, и сразу! Ну а я чего, я и начал готовиться. И как побежали у меня флешбеки вьетнамские перед глазами: цифры с потолка, гипотезы от TAM а не от SAM, отсутствие sanity check'ов при составлении экономики (помню кейс, когда принесли продукт, у котого будет к 2028ому году 260 млн MAU. Круто, но продукт на российский рынок только), экстраполяция на экстраполяции и вообще все, что часто бывает, когда нужно кейс внутри "защитить" и ресурс получить. От этого мне казалось, что будет вдвойне приятно готовить рассказ, на что базово смотреть и как ловить такие вещи. А никак не ловить, только самим полностью погружаться. Вот. Потому что обоснование гипотез лежит чисто на стороне команды, и, если ей доверия нет, то... ну... э... Раскопать подлог, который может сделать хороший продакт менеджер просто нереально, если не проделать полную дискавери работу. Презу я вам сюда выложу, когда закончу. Сегодня, или завтра утром. А пока вот, смешная картиночка с линкеда, чтоб вы знали, что канал еще жив, как и его автор, и еще друзьям скинули, например!

Селф чек продакта, как тема для общения со мной на сессиях, стал все чаще и чаще занимать лидирующие места по числу вхождений в менторских посиделках, уверенно опережая поиск работы, стратегию продукта и карьерную стратегию. И это радует, потому что темы поиска работы уже набили оскомину, стратегию я все еще нежно люблю... но уже так много всего сказал, что прям даже не знаю, что еще добавить. Да и книжки новые не помогают, так как там все уже давно знакомое. Что такое селф чек? Это когда продакт говорит: "Вроде у меня есть беклог, но я пока не понимаю, насколько я вообще молодец. У меня выполняются цели, я понимаю что делать, но что-то мне не понятно, а достаточно ли? А не ждут ли от меня больше?". Если вы задаетесь подобным вопросом, хотя бы периодически, то у меня для вас хорошая новость: вы не остановились в развитии, как продакт, и все еще ищете, где можно сделать больше, чем от вас ждут. Селф чек для меня работает следующим образом: 1. Задаемся вопросом: а какие у меня цели? А какие цели у моего руководителя? А какие цели у компании? Насколько результаты моей работы "бьют" в достижение целей моих сейчас (базовый чек) и в цели руководителя и компании (понимание своего "веса" в рамках подразделения и потенциала для расширения, как ответ на вопрос "а достаточно ли я делаю")? Эти вопрос помогают довольно легко навести прозрачность и сформировать примерное понимание, а достаточно ли у вас амбициозные цели, и какой у вас вообще дальше потенциал к росту. 2. Выполняютлся ли мои цели? Если да, то остался ли "зазор"? Если нет, то какие запуски не дали нужный результат и почему? Тут работает такое: 2.1 Трекшн модель: рискуем на графике времени все свои запуски и ожидания от них за период. По факту запусков мы смотрим на planned vs fact и делаем какие то правильные lesons learned, причем внимательнее именно в случае неудачи. Хотя и удачу, конечно, анализировать нужно. 2.2 Если цель не выполняется, о чем нам скажет пункт выше (по-сути, это просто burndown chart вашей цели по году), то... Все понятно: сидим и ищем проблемы / решения, быстро тестируем, ну и делаем свою стандартную продуктовую работу. А вот если мы понимаем, что цель выполняется раньше, то у нас начинается самая интересная часть работы: у нас остается зазор на то, чтобы попробовать какие-то экстримальные (казино, короче) запуски. И, если у вас с целями хорошо, то у вас на это есть ресурсы и нет рисков и можно заниматься RnD и кайфовать, ну и ждать, что цель поднимут ))) А вот если цели не выполняются, то начинается интересное: вам нужно настолько детально и мелко порезать свои "безумные", ну или просто крупные идеи (в плане стоимости и результата), чтобы без вреда для процесса "делаем гарант выполнения цели" (из начала пункта 2.2) еще и протестировать с минимальными затратами самые важные составляющие этих гипотез. И вот это тоже магия (и мое любимое) работы продакта, когда вы проводите постоянно рефлексию на тему "а могу ли я лучше?", "а какие у меня есть еще идеи?" и "какой у меня есть reason to beleive в потенциал своих идей?" и для ответов на эти вопросы ищете максимально простые и дешевые инструменты для увеличения своей же веры в себя, в конце концов, да и веры компании в вас 🙂 Ну и интересное наблюдение, что ко мне приходят абсолютно адекватные люди, которые имеют абсолютно (ну по мне) адекватный беклог и выполнение целей, но при этом сомневаются в своем весе в рамках компании. Видимо, рыночек давит, что хорошо, потому что продакты стали снова "все делать сами", как было раньше, и плохо, потому что именно так работая я и поседел 😄

Я тут фреймворк придумал! Ну, конечно, не вот прям придумал, а просто жизнь заставила обычный "чтобы что" сделать немного пошире, чтоб отбиваться от всякого, новомодного. Я выступал за последние две недели со стендапами на конференциях на тему "как отбиться от ИИ, если оно не надо", ну и в целом про то, как работать с запросами на "надо", когда технология уже частично комодити, но частично еще хайп, ну и нужна не всем и не везде. Кто-то смеялся в зале (я считаю это успехом на конференции), кто-то одобрительно кивал, кто-то после выступления подходил пожать руку и говорил "наконец-то кто-то сказал как есть, спасибо". Я вообще не претендую на правоту в вопросах ИИ, да и валенок вообще, но широкое корпоративное внедрение, как мне кажется, требует довольно аккуратного подхода и более точной... оценки эффекта, чтоли. А проблема была мной озвучена такая: "к нам вот пришли, сказали, мол, давайте везде ИИ приделаем". Ну и надо достойно ответить, найти золото, а не золото не делать. Так вот, к фреймворку. Hype driven development! Как вам такой термин? Касается не только ИИ, а вооьбще всего такого, что просто надо сделать, потому что уже у кого то есть, кому то кажется что так надо, ну или вообще технология обгоняет собаку, то есть хвост. Что я предлагаю к рассмотрению? Берем стандартные Raw запрос ("давайте ИИ" у нас с вами) -> Problem framing -> Solution (тут его принесли) -> Prioritization -> Prototype / pilot -> Measure -> Scale / kill добавить еще два пунктика: Use-case classification и AI-fit check. Основной проблемой, имхо, в запросе от решения / технологии является то, что вообще не ясно, какую проблему решаем, и как померить, что получилось. Проблемы то нет. Так вот в классификации я обычно смотрю на Автоматизация (cost reduce) / Ассистирование (augment human) / Генерация (content/code) / Анализ (insights). Это помогает на начальном этапе хорошо сматчить решения на проблему, и хорошенько подобрать инструмент. А вот дальше надо сделать чек, а вообще инструмент применим? А потянем? Насколько безопасны ответы? Не скажет наш агент в поддержке что-то не то?.. Какие есть риски ошибки? Успеем мы поймать ошибку на скейле, пока помощники дел не наделали? Сколько % ответов / задач надо проверять и есть ли у нас инструменты observability, чтобы понять, что дело "дрянь"? Насколько наши данные «чисты»? Нам вообще есть на чем модельки то обучать? А сколько стоит инфра? А логично ли данные размечены? А где хранятся?.. Какие риски влияния на конечный бизнес мы видим? Где вообще пользователь столкнется с нашим решением? Повлияет ли это на отток?.. (не знаю как вы, а я дико местами горю от ИИ ответов в поддержке, например) Достаточно ли нам ресурсов на тесты? А на скейл? А если продукт будет расти?.. Мы инфру свою не положим, ну или деньги не сожжом, иначе говоря? А есть ли у нас готовые специалисты? А с учетом вопросов выше как вообще PnL выглядит?.. Вот такое предварительное базовое обследование помогает нам понять, стоит ли оно вообще все того, чтоб этим заниматься. И думаем мы сильно заранее и детально. Вроде обычная продуктовая работа и бриф, но помогают чуть детальнее именно в кейсах с ИИ понять, а хватит ли кармана, и вернутся ли деньги, ведь именно в это все упирается? Ну а пока "оптимизируем операционку за счет более дорого решения" – кейс, который я часто вижу. Поверьте, в формате стендапа с смешными кейсами это все весело, но очень грустно в кулуарном общении потом.

Последнее время есть некоторые сложности с телегой. Почему они и зачем — не тема канала. А тема канала — делиться чем-то, что считаю важным и полезным. Коммерция у меня не выходит, инфо бизнесмен я так себе, а вот делиться мне нравится. Кому-то из вас я помогаю, кому-то помогал когда-то, кто-то просто читает, кто-то у меня учился. И мне очень обидно понимать, что я, вероятно, в какой-то момент не смогу вас радовать в этом канале. Или вы не прочитаете. А могло быть мне интересно (это факт), а вам полезно (вероятно, как в «о чем говорят мужчины», да?) На три буквы я не пойду. По крайней мере, сейчас. По вопросам вы меня сможете найти тут, вроде еще пока можно https://ru.linkedin.com/in/akpstn А пока, я собираю себе тул для экспорта всего в открытую базу. Может что хорошее получится ? Из интересного за последнее время: 1 Я снова буду преподавать. Надеюсь, все получится, и скоро подпишусь с одним очень интересным университетом. Держим пальцы крестиком. Всегда нравилось преподавать, и, надеюсь, смогу что-то интересно рассказывать хотя бы студентам. 2 Один из моих заказчиков на обучения поблагодарил меня за лекцию едой. Это очень круто :) У меня теперь шоколадных батончиков тонна. Да и рассказал вроде интересно, про внутрянку продуктового процесса. Продуктовый подход и люди — уже коммодити. Как в этом найти себя и еще быть специалистом — тот еще вопрос. Про это расскажу дальше в постах. 3 Много общался с участниками рынка со стороны работодателей и нанимаемых. Помогаю двум сторонам, так сказать. Интересно сейчас все. Основная мысль, которая делает меня грустным последнее время: все решает только нетворк и правильно пожатые руки. Начиная с определенного уровня. И не правильно пожатые тоже решают. И не те руки, пожатые до, какой бы вы не были крутой, тоже решают. Выбирают своих, какое бы понятие «своих» не было у нанимателей. И я вижу, как слабые люди в профессии улетают в космос, а сильные, но тихие, улетают в обратную от него сторону, какая бы она не была. Ну а те, у кого 1+1 улетают в 3. Дальний космос :) Что радует. Как сказал мне один очень уважаемый мной менеджер «если бы в один момент мне не было бы кому позвонить, я не знаю, где был бы сейчас». Разверну все дальше в постах, если прокси не подведут, а пока такой вам винегрет, пятничный.

Выступаю! А вы приходите послушать, ну и тут я вам расскажу, но не так красочно и классно, скорее всего 🙂 О чем буду говорить? Последний год я (и, скорее всего, многие из вас) регулярно слышу одно и то же: «Где у нас AI? Почему еще не внедрили? Нужно срочно! Давайте сократим все ИТ, уже ИИшки все пишут же! Давайте всю операционку грохнем! Уберем поддержку и вот это все!» Причем идеи идут не от продукта, а «сверху» или от хайпа, или кто-то где-то какое-то обучение прошел. И там советовали. И в какой-то момент команды начинают делать AI ради галочки. Появляются эксперименты без результата, сложность растет, а ценность для бизнеса и клиентов нет. Еще и стоит как чугунный мост, а так как начали с решения, что я не люблю, ценность запуска... сомнительна. Как вам такое? Разработка продуктовых задач у нас замедилилась при внедрении помогаторов-ИИ для разработки (ну, если честно, архитектурные задачки лучше себя чувствуют, напротив). ИИшные инструменты для дискавери? Ну что-то пока тяжело идет. Автоматизация всяких бизнес процессов? Часто дороже, чем человек. И масштабируется сложно. Но и пользу нашли, и довольно много, и часто там, где просто человеки... косячат. У нас получилось хорошо поставить запросы на рельсы, и хорошо собрать problem-solution fit для большинства проектов с ИИ, и даже кое-чего классного добиться. Но пришлось попотеть. А как получилось?.. И в чем? Ну вот 17 апреля я выступлю на Product Focus Club 2026 и расскажу, как мы с этим всем работали на практике. Расскажу о том, где работает и что получилось, а что нет: — как мы справлялись с запросом «сделайте AI везде» — какие кейсы реально сработали: computer vision, автоматизация, поддержка — что не получилось и почему — как сейчас подходим к внедрению AI без иллюзий Product Focus Club 2026 – конференция про будущее продуктов и бизнеса в эпоху перемен и AI, и проходит очно в Москве / онлайн Среди спикеров также будут собственники и директора из: Сбер, Финам, Rostics, Мегафон, Точка Банк, Вкусвилл, Персона, Ростех, ВК и др. 4 тематических трека: — Продуктовая, бизнес- и AI-трансформация — Лидерство и команда в кризис — Стратегия прорыва и точки роста — AI & тренды А для подписчиков моего канала, раз я рассказываю секретики, действует промокод на скидку 20%: AIIZATION Запись и детали тут!) Приходите, будем очно болтать и обсуждать будущее AI, продуктов и что делать дальше :) Если вы уже собираетесь на кофу, то я буду рад вам пожать руку и познакомиться!

Привет, я давно не писал. Хорошо отдыхал, пока мои ребята запускали классные продукты. А до этого старался сделать так, чтобы у них было место для этого и возможность. Получается! Напишу что-то скучно продуктовое попозже, а пока дам вам странный пятничный совет-рекомендацию. Я слушаю подкасты, редко но метко. И послушал тут подкаст у Джо Рогана (да да, слушаю разное) с Джоном Синой (еще внезапнее). И вот в подкасте много интересного, но меня особенно зацепила одна мысль Джона. Ситуация: герой подкаста сказал лишнее на выступлении, хотя все готовилось заранее, и ошибка была… ну политически критичная для карьеры нашего героя. И он поспешил ее сразу исправить, сделав еще хуже (послушайте подкаст, да). И знаете кого он обвинил во всей ситуации? Себя. Ни тех, кто готовил текст, ни режиссеров и переводчиков, себя. Пока вы вините других, вы сами не сможете расти, и только приняв на себя всю ответственность, можете начать расти из этой ситуации. В подкасте, конечно, все детальнее, но мысль простая. Мы с вами, как руководители команд, продуктов, стратегии или чего угодно, в первую очередь сами отвечаем за результат и только с нас начинается рост. И пока мы не признаем свои неудачи и спускаем их вниз, мы сами не растем. Нет, ну может по карьере то и растем, но снова и снова будем также ошибаться, и «другие виноватые» рано или поздно закончатся. А мы останемся такими же. В авито было много принципов, но «изменения начинаются с тебя» был моим любимым. И вот тут о том же: ваша насмотренность, в том числе, растет от ваших ошибок и от вашей рефлексии на них. Это, кстати, я чаще всего спрашиваю на собеседованиях: что пошло не так, чему вы научились, и как сделали бы иначе. Ведь если получилось, это может и другие помогли, культура, процессы вокруг и так далее, а если не вышло… ну. Вы один с самим собой, и только ваша рефлексия — ваш драйвер роста. Да еще и под давлением целей. Круто же?.. Всем пятницы, ну а я снова тут с вами. Спасибо, что читаете! Пс: подкаст послушайте.