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

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

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

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

В slack я 90% времени пользуюсь вкладкой ‘Unread’. Она офигенна тем, что в ней можно сколько угодно смотреть на новые сообщения, они не будут помечены прочитанными, пока ты сознательно не нажмешь на кнопку ‘Mark as read’. Это фантастически удобно, и позволяет работать с мессенджером как со списком задач.

Если же просто открыть чатик, чтобы посмотреть, что именно тебе написали нового, то он автоматически исчезнет из зоны внимания (а новые сообщения исчезнут из вкладки Unread), даже если там тебя просят что-то сделать и ты не можешь сделать это сразу. Приходится постоянно нажимать ‘Mark unread’.

Еще я довольно часто пользуюсь функцией ‘Remnind me about this…’ чтобы отложить сообщение на определенную дату. Да, это в некотором смысле дублирует функционал списка задач, но сильно добавляет скорости.

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

Какие полезные приемы вы используете, чтобы эффективно работать с рабочими мессенджерами?

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

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

Это классическая история про Jobs To Be Done. Потому что когда начинаешь раскручивать этот клубок из требований, довольно часто приходишь к неожиданным результатам. Например:

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

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

Как продакты мы постоянно работаем с данными и анализируем их.
А еще среди нас есть продакты, которые работают с данными о продактах.

Чтобы у них было больше данных о продактах, а мы все лучше понимали как сейчас устроена индустрия и куда всё движется, поучаствуйте, пожалуйста в исследовании: https://survey.alchemer.eu/s3/90657221/2024

Среди прошедших опрос разыгрываются билеты на ближайший сезон Podlodka Product Crew.
Опрос анонимный, все данные конфиденциальны и будут использованы в обобщенном виде.
Результаты можно будет увидеть уже в конце февраля. Обязательно обсудим тут ;).

Результаты предыдущего исследования devcrowd.ru/pm22

Хард скиллы помогут тебе на всех этапах карьеры: от джуна до директора

Привет, это Владимир.

Спорил на днях со своим директором об одной метрике и осознал, как же он хорошо шарит в деталях, несмотря на свою должность (под ним 10 команд).

От продактов, которые готовятся стать менеджерами, я часто слышу, что “они готовы к стратегической работе” и “детали им уже не так важны”. Вместе с этим приходит представление, что Product Director – это стратег, сидящий за дубовым столом и владеющий собственным если не самолетом, то по крайней мере Porcshe и суровым взгдядом.

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

Например, A/B тест показал смешанные результаты, все смотрят на директора. Если он просто “стратег”, то он нежно отфутболит это команде обратно. Но если он сам запустил не одну сотню тестов, то он предложит такие опции, которые и не дадут прямой ответ, и двинут команду вперед.

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

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

Качайте хард скиллы на наших симуляторах, благо задачек в них хватит не на одного директора!

По теме вчерашнего поста - держите красивую табличку прокачки хард (80%) и софт (20%) скиллов от Джуна до Синьора. Там же есть колонка "чего делать не надо" - если узнаете себя в ней, то будьте осторожны.

https://productdo.it/matrix

Пишите в коментах, если считаете, что мы пропустили какой-то ну очень важный скилл и предложите, как его описать в формате (Jr, Core, Sr, Red flag).

Простите, но я опять про мессенджеры. Мне кажется я провожу в них 20% - 25% рабочего времени, поэтому у меня много мыслей по стилю коммуникации.

И в первую очередь я делю людей на тех, кто имеет тенденцию каждую свою мысль (чаще всего незаконченную) отправлять отдельным сообщеним. Особенно 'Hey!' или "Привет!"

И тех, кто сначала думает, а потом отправляет полное сообщение, ответив себе на вопрос, чего он ожидает от адресата.

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

В четверг 22/02 у нас будет разбор кейсов на софт-скилы. Присылайте свои кейсы!

Привет, канал. В четверг у нас будет вебинар, на который мы пригласили Александру Клименко. Саша давно занимается обучением IT специалистов коммуникациям, переговорам и прочим софт скиллам.

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

Кто:
Александра Клименко, СЕО школы коммуникации Soft Skills Lab
Андрей Менде, Senior Product Manager Data Science Booking .com
Когда: 22/02 17:00 (CET) / 19:00 (GMT+3)
Сколько времени займет: час – полтора
Где: наш канал на YouTube, вкладка Трансляции / Live


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

Где смотреть вакансии (кроме LinkedIn)

Привет, это Андрей Менде.
У меня было несколько менти, которые переходили в продуктовую должность из “смежной”. В перавую оченедь мы занимались подготовкой к интервью и переупаковкой опыта таким образом, чтобы про него можно было рассказывать продуктовые истории. Но помимо этого, я советовал ребятам максимально использовать “нечестные преимущества" при выборе вакансий.

Например, если вы как продакт или как аналитик занимались товарами FMCG, то компания в той же нише будет расценивать то, что вы хорошо знаете отраслевую специфику как сильный плюс. И более вероятно простит вам небольшое количество опыта и “неправильный” тайтл на последнем месте работы.

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

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

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

Например, среди последних опубликованных там есть вакансия продакта по платежам в компанию Trading View. Я этот продукт знаю и люблю, но сам по себе он фантастически сложный для управления. Однако, если у вас есть экспертиза в платежах, вы уверенно можете рассуждать про сертификацию PCI DSS, и знаете, почему лучше сделать refund, чем потом поймать cahrgeback, то у вас есть значимые "нечестные" преимущества.

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

Запись эфира: https://youtube.com/live/XdDMT_OhYX4

Сегодня интересный опыт про продуктовую стратегию

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

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

Далее, ты часто можешь услышать что-то типа “Нам это не нужно, мы знаем, что делать”. Это отлично, значит записать не составит труда, верно?

Потом ты видишь уважительное кивание, когда показываешь в пример какую-то другую команду и их стратегию.
(А продакт их – сын маминой подруги!)
Ты практически в реальном времени видишь расширение сознания и выражение лица “Ахренеть, это и вправду план на год вперед в понятном виде!”.

Потом ты видишь ухмылку “Сделаю такую же завтра, проще-простого”.

Через неделю продакт возвращается без половины волос и говорит, что всё оказалось сложнее, чем он думал. И вообще – вот его первая версия. Виной этому эффект “Да там все ясно”, который заставляет нас игнонировать сложные продуктовые вопросы и плавать в операционке. А когда ты это “ясно” вытаскикаешь на сцену и применяешь к нему логику (“Проблема пользователя, импакт для бизнеса, технические ограничения и тд”), то многие “ясно” просто разваливаются. Когда один за другим разваливаются все “ясно”, то начинаешь седеть: “А что дальше-то!? У меня что, нет планов!?”

Через три-четыре итерации “фидбек менеджера/коллег/переделка” стратегия обретает форму и достигает того самого волшебного эффекта, который можно описать так: “Вроде и планы аж на год вперед, а вся история связная, понятная и реалистичная с точки зрения исполнения”.

Данный артефакт (обычно слайды) важно сделать до начала следующего года (в крайнем случае - в начеле текущего). Огромный плюс: этот док вы будете использовать десятки раз, то объясняя директору план, то напоминая команде компас, то онбордя новичка, и т.д. Свою стратегию я открываю раз по 5 в месяц и, конечно, постоянно немного полирую новыми мыслями.

Есть ли у вас такой док? Если нет, сможете ли вы записать путь от “сейчас” до “31 декабря 2024 года” в понятной любому читателю (программист, нетехнарь-дизайнер, CEO) форме? Если да, снимаю продуктовую шляпу.

Если интересно, то в следующем посте поделюсь шаблоном стратегии.

Делюсь чек-листом по продуктовой стратегии.
По реакциям и комментам 👆видно, что тема горячая.

Сразу обратите внимание на две вещи. Во-первых, не нужно ожидать от шаблона магии - вам всё равно придется ответить на “сложные” продуктовые вопросы (например, какую проблему пользователя вы решаете).
Во-вторых, чтобы ответить на эти главные вопросы, вам нужно будет задать 20 других более мелких вопросов, например:

- Какая конверсия была на странице регистрации?
- Насколько сервис отзывов готов принимать данные о моем продукте?
- Что заставляет меня верить, что вот тут поможет ML?
- Какую метрику выбрать для главной линии экспериментов?
- Уверен ли я, что эту API интеграция реалистично сделать за 2 квартала?

И так далее. А для этого нужны (барабанная дробь) - хард скиллы. Так что пишите стратегию, а когда почуствуете, что не хватает мат. части, то посмотрите на наши симуляторы. Вот тут можно пройти обзорный тест по всем скиллам продакта, из которого есть ссылки на бесплатные уроки по каждой теме:
- Технологии для продакта
- A/B тестирование
- Аналитика, SQL для продакта
- Основы ML
- Планирование и Исследование рынка


Ну и вот сам шаблон по продуктовой стратегии.


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

У Ahoy вышел новый подкаст. 70 минут пользы и инсайтов.

В гостях Андрей Менде, Senior PM ML в Booking и автор в образовательном проекте ProductDo, рассказал о плюсах переезда в Амстердам, как изменилась продуктовая культура в Booking с ростом компании, почему не всегда нужно стремиться стать менеджером, почему практическое образование лучше теоретического и для кого оно подходит больше всего.

Делюсь трюком, которым я пользуюсь, чтобы проверять готовность идей к разработке:
Тест "Начинаем завтра!"

Привет, это Владимир. На неделе я встречался с продактом из соседнего департамента и услышал от нее отличную идею, которую она предлагает для нас сделать. Поскольку конкретный пример вам будет не очень понятен без контекста (а NDA никто не отменял), давайте предположим, что мы в компании Spotify и “идея” состоит в том, чтобы показывать ближайшие концерты группы неподалеку от слушателя.

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

Но на этой неделе я опять получил “идею”: она немного обросла деталями MVP, но по-прежнему не прошла “начинаем-завтра-тест”.

Тест очень простой – вы спрашиваете себя или коллегу: “Если у нас завтра появляется 5 свободных программистов/дизайнеров/итд, проработана ли идея продактом так, чтобы ее можно было прямо завтра начать кодить?”

Тест заставляет мозг перейти из мира мечтаний в мир “на меня пристально смотрят 5 программистов” и принять все продуктовые решения, которые иначе заблочат всех на первом же повороте. Например, в нашем случае продакт должен посмотреть на данные и утвердить:

- Радиус “ближайших городов” - 200 km
- MVP: только артисты одного лейбла, который дает нам доступ к своей базе данных концертов
- Показываем только дату/название клуба внизу странички артиста - ссылки пока не кликабельные
- Меряем событие viewed этот элемент > 3 seconds

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

Я решил кардинально поменять работу и место жительства

Всем привет, это Константин!
Сейчас у меня достаточно свежий (и успешный) опыт поиска работы, который может быть полезен многим.

Для начала давайте расскажу о том, что из себя представляет типичный процесс найма. Если мы говорим про крупные компании, то пройти придется 5-6 интервью. В компаниях поменьше, все будет попроще и количество этапов поменьше. Но по моему личному опыту, чем больше компания – тем лучше там всё стандартизировано, тем более прогнозируемы принципы, по которым тебя проверяют. Подстраиваясь под требования больших компаний, проходить собеседования в компании поменьше в любом случае будет значительно проще. Поэтому предлагаю сфокусироваться на Big Tech подходе к найму сотрудников.

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

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

-2-
Следующий этап один из самых важных. На нем продакт менеджер из компании нанимателя будет проверять насколько ты соответствуешь гордому званию продакт менеджера. В некоторых компаниях просят рассказать про свой предыдущий опыт, какие-то самые интересные моменты из своей карьеры и разобрать определенные кейсы (которые тоже нужно подготовить заранее!). В некоторых компаниях наоборот –от вас потребуют решение метафорических кейсов в вакууме. Мой самый любимый пример про человека, который решал кейс о построении продукта для телепортации при найме в Google 🙂 В такого рода интервью проверять будут прежде всего ваше умение логически мыслить и декомпозировать проблему на уровне: кто наши пользователи? какую проблему мы для них решаем? в чем может заключаться потенциальное решение? на какой сегмент/рынок это рассчитано? и т.д.

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

-3...-
Цель каждого интервью заранее прописана (Strategy, Leadership, Analytics, System Design, etc.). Самым последним этапом обычно ставят собеседование непосредственно с вашим hiring manager. По результатам всех этапов участники обычно выставляют вам свои баллы и разного уровня комментарии (которыми они с вами особо не поделятся). Если в конечном итоге коллектив решит, что ты соответствуешь указанной позиции, уровню, leadership principles компании нанимателя и прочим стандартам, то тебе сделают оффер. Весь этот процесс от начала и до конца обычно занимает 3 месяца и больше. В больших международных компаниях с такими вещами никто не торопится.

Какие практические советы я хотел бы сразу оставить для читателей:

1. Процесс прохождения интервью обычно стандартизирован. К нему вполне можно подготовиться, если знать к чему готовиться заранее (Например, материалов под MAANG интервью в интернете/ютубе полно).

2. Многие недооценивают "Introduce your self" речь и насколько она у них плохая. Свою я переделывал много раз. Здесь лучше подумать и попрактиковаться о кого-то со стороны.

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

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

(продолжение)

5. Решение кейсов со сферическими конями в вакууме для построения телепортов должно быть описано в книге Crack the PM Interview. Я лично не читал🙃, но слышал о ней и другие авторы канала эту книгу советуют. Но если что, примеров в ютубе тоже хватает.

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

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

У нас в команде возник спор: используют ли русскоязычные продакты идиому "business as usual"?

Что-то вроде: "У меня на этой неделе плэнниг спринта, потом гурминг бэклога. Короче, business as usual."

Как продакты решают споры? Смотрят в данные!
Как блогеры узнают мнение подписчиков? Устраивают опросы!

Помогите нам расширить коллекцию стикеров.