Итоги года, или как самому офигеть от собственной крутости.

Привет, это Андрей. В начале года я писал о том что хочу завести документ (дневник? таймлайн?) достижений своей команды, и регулярно его вести весь год.

Если коротко, то принцип ведения такой:

→ Записываются только результаты: выпустили релиз, провели эксперимент, в крайнем случае, провели исследование – вот выводы.
"Запланировали", "договорились", "сделали дизайн", "нарисовали архитектуру" – это не результаты, это не в счет.

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

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

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

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

Во-первых, это офигенно. За пару часов дополнительного структурирования и причесывания, у меня получилась красивая презентация результатов команды (в прошлые годы я тратил на подготовку такого отчета от пары дней до недели). Ну знаете... такая, что читаешь и сам офигеваешь от того, какие мы крутые.

Во-вторых, теперь у меня результаты готовы довольно сильно заранее, и я раздал этот документ всем членам команды, чтобы они могли оттуда брать красиво оформленные факты со всем evidense’ом для своих performance evaluation.

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

Конечно, в процессе работы над финальной презентацией, я сделал много наблюдений в духе: “а еще надо было вот это сохранить”, или “надо было сразу написать короткое executive summary”. Очень надеюсь, что смогу на основе этих learning’ов изменить свое поведение на следующий год.

А у вас как проходит подведение итогов? Или в вашей компании это еще рано делать?

Как слушать top-down годовые цели?

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

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

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

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

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

Иногда я вижу: ага, коллега очень старался сказать вот это, но ему не хватило умения формулировать четко и емко. Я кое-как разберу, что он пытается донести, но моя команда – скорее всего нет, надо будет объяснить.

Разница между теми лидерами, кто хорошо умеет делать такую коммуникацию один-ко-многим, и теми, кому этого навыка явно не хватает, видна невооруженным взглядом.

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

А какое у вас состояние перед годовыми планированием? Ваши руководители смогли хорошо донести стратегию и цели компании?

Может ли Chat GPT написать качественные performance feedback?

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

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

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

Не смотря на то, что мне по должности положено ратовать за использование всех форм Machine Learning'a, я считают это невероятно вредной практикой.

→ ChatGPT не может написать evidence based фидбэк, он не знает фактов о вашем взаимодействии с коллегами, а именно они – факты и примеры поведения и являются "мясом" фидбэка
→ да, с помощью ChatGPT можно "добавить воды" в фидбэк, но это самое плохое, что вы можете сделать – подумайте теперь про того, кому эти тексты читать, ему нужно будет тратить силы на обратную операцию "выпаривания" воды. Зачем так делать?
→ ChatGPT не может добавить никакой ценности вашему ревью, даже попыткки "сгладить язык" и сделать его более стандартным приводят к тому, что из сообщения пропадает важная эмоциорнальная окраска

Ну и кроме того, это просто довольно хорошо заметно, и вызывает у получателя (и его менеджера) скорее отрицательные ощущения – кто-то сэкономил на мне и подсунул мне фальшивку.

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

Если когда-нибудь где-нибуль один продакт скажет другому "Постой, ты совершаешь ошибку из кейса Менде с поиском по карте" – я жил не зря.

На этой неделе стартует второй поток курса ML для продактов.

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

Старт 23 ноября
Язык курса: русский
Пять созвонов с активной совместной работой по 90 минут
+ наш новый симулятор

Что за симулятор?
Для тех, кто еще на практике мало сталкивался с ML разработкой, мы сделали симулятор, который мы называем "Основы ML для PM". Этот симулятор позволяет за пять уроков посмотреть несколько базовых кейсов и разобраться с основными понятиями: что такое фичи, где брать лейблы, и чем отличается регрессия от классификации.

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

Что будет на созвонах?
Machine learning применяется в цифровых продуктах всё чаще. Но управлять разработкой моделей – не совсем тоже самое, что управлять изменением UI/UX продуктов. Для них требуется совершенно другая постановка задач, другой цикл разработки.

На курсе мы обсудим, что должен знать и уметь продакт, чтобы уметь эффективно работать с Data Scientist’ами, на какие решения продакт может и должен влиять, а какие – отдавать на откуп команде.

Как упаковать сложные кейсы по ML в симулятор я еще не придумал, поэтому основная часть курса – это совместная работа над задачами во время созвонов, где мы будем много обсуждать создание датасетов, онлайн и оффлайн оценку качества модели итд.

Кому подойдет:
- Тем кто уже столкнулся с ML разработкой, но хочет обсудить с коллегами, как ей управлять
- Тем, кто еще не имеет практического опыта, но хочет быть готовым ко встрече с мечтой (ML-продуктом)

Отзывы (что говорят участники первого потока):

“Курс помог структурировать информацию, которая до этого болталась где-то в голове. Но самое полезное это практическая часть. Пример просто супер и именно их разбор помогает взглянуть на рабочие задачи под другим углом: где можно упростить, где применить другие походы. Тут я говорю не про алгоритмы, а именно про способ мышления, про выбор фич на которые мы будем смотреть.
Над многими примерами хочется подумать не 5 минут, а мы вынуждены были выдавать решения очень быстро, хотя зачастую однозначно правильных решений в задачах просто нет. Повторюсь, это самая ценная для меня лично часть курса.
Огромное спасибо за курс!”

“Мне понравился контент – плотно без воды, информация действительно полезная и применимая на практике”

“Это отличный иммерсивный курс! Мы решили множество кейсов и прошли путь до применения технологии ML в реальных продуктах. Эти знания помогли мне в рабочих задачах — я смог углубить дерево метрик продукта до уровня метрик модели. Рекомендую курс менеджерам, которые хотят понять, как работает этот «черный ящик»”

Присоединяйтесь к новому потоку, до старта меньше недели!

Почему именно продактам важно отличать корелляцию и причинно следственные связи (correlation vs causation)?

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

Была у нас в продукте довольно значимая фича X (это был поиск по карте, но для истории это ключевого значения не имеет). Копаясь в аналитике, я строил поведенческие сегменты, и заметил, что все пользователи, которые используют фичу X, значительно чаще конвертируются в целевое действие, да и все остальные метрики качества сессии у них сильно выше.

Какой вывод? Все же очевидно! Ценность продукта раскрывается через фичу Х. Чем большая доля аудитории начнет ей пользоваться, тем лучше будут показатели у всего сервиса.

Я потратил некоторое время на то, чтобы популяризовать фичу Х, но удивительным образом это ничего не дало. Тогда я решился на радикальный эксперимент: буду половину людей лендить прямиком в эту фичу, чтобы уж наверняка. (Через несколько лет я осознал, что в принципе чаще всего стоит начинать с самого радикального подхода).

...и метрики несколько просели.

[небольшая пауза, чтобы вы сами построили гипотезу, почему так произошло]

Вывод, который я сделал для себя: в любом сервисе есть сегмент пользователей, которые более мотивированы, потребность стоит для них более остро итп. Эти люди будут более активно пользоваться вообще всеми фичами, которые в сервисе есть, просто потому что они генерируют больше действий (проверьте поведенческие сегменты по основынм фичам в своем продукте).

То есть "использование фичи X" и "более высокая конверсия" являются следствием одной и тоже же внешней причины (более высокая мотивация пользователя). Пытаться повлияеть на одно через другое – это глупость, так как между ними есть только корреляция, но нет причинно-следственной связи.

NB! Это совершенно не означает, что не может быть "фичи X", которая является причиной более высокой конверсии. Это означате только то, что наблюдаемой корреляции недостаточно, чтобы сделать такой вывод. Нужны дополнительные косвернные свиделетьства или эксперимент.

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

Стрим ProductDo с Ваней Замесиным: Почему люди покупают?

С вами Андрей Менде.
Йо-хо-хо. Астрологи-продуктологи объявили год звездных стримов на нашем канале. К нам в гости придет Иван Замесин, автор одного из самых популярных курсов для продактов, а также многих фундаментальных текстов и идей.

Регистрируйтесь, чтобы не пропустить.

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

Если вы хотите задать нашему медиуму для общения со вселенной (Ване) какой-то вопрос через меня, то напишите его в комментариях.

Автор самого интересного (по мнению авторов канала) вопроса получит Telegram Premium на год (никаких гивов, никакой херни, напрямую в подарок :)).

Привет! Это Владимир.

Представьте, что вы пытаетесь продвинуть ваш блог или рассылку. Вводные:
– вы публикуете «посты» каждую неделю,
– около 20 000 пассивных читателей,
– около 3 000 открывают ваши электронные письма.

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

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

Продолжение разбора этого кейса в лонгриде на Медиуме: "A simple example of how A/B testing can help creators reach more readers". Всё объяснил на простых примерах.

А как бы вы решали такую задачу?

Друзья, запись вчерашнего стрима на нашем YouTube канале.

Всем привет! Это Константин.

Поскольку на продактов обычно ложатся еще и обязанности проджектов по поводу оценки и ведения спринтов, хотелось бы поднять этот холиварный топик. Здесь я поделюсь своей личной болью планирования объема работ своих команд. В разработке задачи часто принято оценивать в т.н. story points. Для тех, кто не знает, это некие абстрактные единицы, призванные заменить оценку задач в часах. Например, у нас в команде используются числа Фибоначчи: 1,2,3,5,8,etc.

На бумаге идея звучит красиво. Людям свойственно ошибаться в оценке объема и сложности задач. А такого рода абстрактные единицы позволяют не привязываться к точному времени. Т.е. если мы за последние несколько спринтов выполнили в среднем 20 стори поинтов за спринт, то в следующем мы будем ждать примерно то же.

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

Вторая часть проблемы начинается, когда ты пытаешься перевести этот роадмап, оцененный в неделях/днях/часах в стори поинты во время планирования задач на спринты. Оказывается, что перевести его нормально не получается и в итоге вы всё оцениваете заново, потому что переводить стори поинты в часы (и наоборот) некорректно. При этом каждый спринт ты видишь кол-во выполненных стори поинтов и волей-неволей переводишь их объем в фактические человеко-часы. Получается некоторый парадокс при котором часто складывается ситуация, когда “телега рулит лошадью”. Для соблюдения всех формальностей используются стори поинты, но для “реальной” оценки объема работа по прежнему используются человеко-часы/недели/месяцы.

Лично для себя я пока не нашел абсолютно верного решения. Поэтому обычно я придерживаюсь устоявшихся практик в той компании, в которой я работаю. С одной стороны, я понимаю всю красоту идеи абстрактного мышления. С другой – я вижу потребность бизнеса и людей к привязке к каким-то реальным срокам, а не абстрактным величинам. Интересно, что я за свою карьеру успел поработать инженером, аналитиком и менеджером. А эта история с оценкой объема задач командами и несостыковкой с ожиданиями бизнеса преследует меня от роли к роли 🙂.

Делитесь в комментариях вашим мнением по этому поводу и как вы решили эту проблему для себя.