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

Он с гораздо большей охотой закопается еще глубже в данные, потому что пока он работает над анализом, он стоит на твердой почве фактов, а выходить на скользкий неверный лёд гипотез ему страшно. Это состояние еще называется "аналитический паралич" (analysis paralysis).

И получается такой вот склад ума (aka data refrigerator). А могла бы быть фабрика...

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

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

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

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

Может быть кто-то из вас знает, почему не получилось договориться о каком-то стандарте управление cookies на уровне браузера?

Самая большая опасность состоит в том, что ты долгое время будешь вести бизнес в неверном направлении!

Привет, это Константин.
Недавно прочитал прикольный пост Ron Kohavi по поводу опасности ложно-положительных а/б тестов.

Воспроизводимость экспериментов – это на самом деле большая проблема, и присутствует она везде. Особенно остро она стоит в той же психологии. Помните такую великолепную (а книга действительно крутая) книгу “Думай медленно, решай быстро” нобелевского лаурета Канемана? В 2015 году в журнале *Science* опубликовали статью о том, как 270 человек пытались воспроизвести 100 психологических экспериментов. Им это удалось — но только в 39% (!) случаев. Что не так уж и много, согласитесь? Сам Канеман, судя по всему, ошибку признал и сказал, что “в прошлом опирался на исследования со слабой доказательной базой и назвал это «ошибкой»”.

Если переносить этот опыт на нашу с вами сферу, то это касается как самих а/б тестов, так и их отсутствия. На мой взгляд, многие неправильно понимают ценность и практическое применение а/б тестов. Эксперименты не дают тебе абсолютной гарантии того, что ты прав или не_прав в своих гипотезах. Но зато гарантировано увеличивают твои шансы на успех путем статистически подсчитываемых рисков (не)правоты твоих гипотез. Более того, в отличии от экспериментов в психологии, эксперименты в ИТ бизнесе можно легко воспроизводить! Например, запустив повторный эксперимент с выигрышным вариантом в случае каких-то сомнений.

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

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

И при всем при этом... шанс нарваться на ложно-положительный результат (т.н. False Positive Rate) невероятно велик. Даже в крупных компаний, где всё отточено до идеала. Он сильно зависит не только от параметров тестирования, но и от процента успешных экспериментов в компании. Посмотрите в табличку 👆 с данными по ложно-положительным результатам крупных компаний и представьте, какой бы там был процент, если бы а/б тестов не проводилось вовсе.

Что делать с false-positives на практике?

Привет, на связи Владимир, и я люблю практические примеры. Есть два вида FP экспериментов: «сделал всё, что мог» и «решил схитрить».

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

Главной метрикой берём «общая прибыль», поддерживающей – «продажи тортов». Запустили эксперимент, ждём.

1) Вариант 1: прибыль значимо выросла, торты – выросли (ну и экономика сошлась). Странностей в других метриках нет. Тут надо хвалить себя за победу и выкатывать изменение «навсегда».

Может ли тут закрасться FP? Конечно, это ж все вероятности. В большинстве e-commerce confidence interval ставят 90%, так что остаётся 10% ошибиться, что немало.

Прошел год, как быть уверенным, что акция еще работает? Для этого есть техника blackout experiments: в А у нас акция, а в Б - ее нет. В идеале такой тест должен показать ухудшение – без акции значимое падение продаж. Если нет, то либо рынок поменялся, либо… с самого начала это был FP.

2) Второй способ попасть на FP: быть к себе «нестрогим».

Предположим, что в начальном тесте общие продажи выросли, но именно продажи тортиков по два – нет. Тут ОЧЕНЬ хочется все равно похлопать себя по плечу и открыть шампанское. Но если быть строгим, то гипотеза провалилась – мы думали продажи вырастут из-за двойных покупок, а они либо: (1) выросли из-за чего то еще (и надо запускать другой тест), либо (2) - это тот самый FP и акцию раскатывать нельзя.

Побеждает тот продакт, который выбирает не «сердцем», а данными - в долгосрочной перспективе их FP rate будет ниже. Как научиться? Решить 10 кейсов 🙂

Запрещенная соцсеть с когда-то квадратными картинками сокращает всех проджект менеджеров
(но разрешает им попробовать пройти интервью на продакта)

Доброго утра, это Андрей. На выходных мне попалась на глаза интересная статья (не нужно прятать ссылку в коммент, спасибо Паше).
В одной известной компании решили сократить целиком роль проджект менеджеров (они назывались technical program manager, но это по сути та же должность).

Что мы думаем: раньше проджектов было довольно много, они появились в IT индустрии даже раньше продактов. Но сейчас действительно есть такой тренд, что таких позиций становится все меньше и меньше. Должностные обязанности проджекта обычно "размазаны" по смежным ролям, никто не хочет нанимать отдельного человека.

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

Давайте в этот четверг в 17:00 CET (19:00 Мск) обсудим переход из проджекта в продакты на живом вебинаре.
→ мы пригласили несколько человек, которые недавно совершили этот переход, они поделятся опытом
→ обсудим какие навыки нужно качать в первую очередь, чтобы сконвертироваться
→ придет также один "убежденный" проджект, который ни за какие коврижки не готов становиться продактом, узнаем почему

Где?
Наш канал на YouTube. Вкладка Live / Трансляции
Подпишись, чтобы не потеряться.

Есть такое понятие: expected value of information (EVI). Получение любой информации требует времени и ресурсов. Нам приходится постоянно соизмерять
- затраты на получение информации
- с ее потенциальной ценностью для решений, которые мы собираемся принять.

Допустим, мы хотим улучшить экран X в нашем продукте. Хммм, а сколько человек вообще посещают экран X? А что это за сегмент пользователей? А какая у них конверсия в сравнении с остальными? Упс, мы только что потратили 8 часов на анализ задачи, которая (в лучшем случае) даст нам прирост 0.1% целевой метрики.

Если мы хотим проверять свою гипотезу A/B экспериментом, то уравнение становится еще сложнее. Далеко не все гипотезы и далеко не всегда разумно проверять тестами.

Если помнить про ожидаемую ценность информации (EVI), то нужно каждый раз задавать себе вопрос “А какие решения я ожидаю принять на основании того исследования, которое я собираюсь провести?”

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

→ В остальных случаях придется сильно экономить, и выбирать самый дешевый способ проверки гипотезы. Часто это будет означать, что мы будем использовать не настолько точные методы исследования, как нам (data driven людям) бы хотелось.

Конечно, провести A/B эксперимент гораздо приятнее, чем простое коридорное исследования… но если коридорка стоит вам 30 минут, а запуск теста – несколько дней, то даже если коридорный тест дает 60% точности (против 90-95% в A/B), это часто будет рациональным решением.

Ну или другой пример. Если вы собираетесь изменить лендинг страницу, а трафика пока маловато. Стоит ли запускать A/B тест или просто раскатить изменение на всех, и понаблюдать за изменением метрик недельку-две? Если ваш новый лендинг кардинально меняет позиционирование продукта (pivot), то эксперимент может окупиться. Если же это улучшение UI без глубокой цели, то скорее всего, на данном этапе это пустая трата ресурсов. Уравнение может измениться в вашу пользу, если у вас есть опыт и навыки, и запуск эксперимента “стОит” вам относительно дешево.

Собственно, развитие современного продакт менеджмента целиком построено на принципах продиктованных EVI.

→ проверять только те гипотезы, которые смертельно критичны для бизнеса на данном этапе (riskiest assumption first)

→ проверять гиптезы не самым точным, а самым экономным способом

Напоследок посоветую книгу на эту тему: How to Measure Anything. Когда в очередной статье я увидел цитату из нее, то решил наконец нормально ее дочитать до конца. Как только дочитаю, то поделюсь еще чем-нибудь интересным!

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

Погнали! https://www.youtube.com/live/YLCuP8_E7kU?si=h8_kMOBbiNLikfL_

А так можно было!? Список задач в виде набора вкладок в Chrome? Или в инбоксе в Gmail?

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

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

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

→ Вкладки бразузера как список задач

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

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

→ Инбокс Gmail как список задач

Другой коллега Y использует свой почтовый ящик Gmail в качестве списка задач. Задача выполнена = в архив. Для управления списком он часто использует функцию "Отложить/Snooze", которая переносит электронное письмо на выбранную дату в будущем. Если ему нужно создать задачу для себя, он отправляет себе электронное письмо (иногда с отправкой в определенный момент в будущем).

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

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

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

Бесят очереди и неэффективный процесс на tax-return – сделай апу. Раздражает непрозрачность пенсионных накоплений – сделай бизнес!

С вами Владимир с еще одной книгой для продактов: “Fall in Love with the Problem, Not the Solution: A Handbook for Entrepreneurs” от Uri Levine.

Автор – серийный стартапер, самый его известный проект – Waze. Это приложение для навигации, которое строит само комьюнити, просто ездя по маршрутам. То есть там, где 3 раза проехала машина – там дорога. А если кто-то отметил дом номер 6, то с большой вероятностью рядом дома 5 и 7. Бизнес модель – “нежная” реклама магазинов/заправок и тд на карте.

Ему долго отказывали говоря, что он никогда не победит “настоящие” картографические данные, но потом пришел Google и купил их за 1.3 миллиарда. Теперь Waze существует и как отдельное приложение, и, вероятно, как-то “питает” гугловые карты.

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

Потом он много рассказывает про типы пользователей (от early adopters до late majority), о том, почему победа с одними не приносит победы с другими, о том, что стартап – это journey of 100 failures и что надо приготовится падать и вставать.

Много про то, как питчить, как 100 раз слушать отказы инвесторов (венчуры инвестируют примерно в 1%, так что математика суровая), как обговаривать term sheet (договор) и какие подводные камни там ждут. А то построите великий стартап, а выяснится, что у инвесторов и право вето, и почти полное владение компанией, так еще и вестинг период (после которого можно продать свою долю) - 5 лет, так что даже нельзя уйти.

Полезное чтение, как для продактов (ведь они - “стартаперы в тепличных условиях компании”), так и для бесстрашных фаудеров. Точно стоит двух недель вечернего чтения!

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

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

Например, вот недавний пост в фичизме: Нетфликс изменил тарифную сетку: они убрали тариф Basic, и теперь подписка без рекламы стала сильно дороже $12 → $15,5. А тариф с рекламой за $7 в месяц оставили нетронутым.

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

→ ARPPU (в данном случае совпадает с ARPU)
→ Ad reveue per user per month (для пользователей на тарифе с рекламой)
→ Retention rate
→ Распределение пользователей по тарифам (здесь скорее всего релевантны только новые подписки, так как из новости мы видим, то существующие пользователи сохранили свой текущий тариф).

Теперь можно попробовать сделать reverse engineering этого решения. Судя по всему, это означает, что (конверсия + ARPPU + ad revenue + retention) на тарифе с рекламой выглядят сейчас для Netflix привлекательнее, чем ARPPU на тарифе без рекламы. Понятно, что продакт пытается оптимизировать LTV, но никаких способов быстро измерить влияние на LTV у него нет (и предсказательные модели тут скорее всего не помогут).

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

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

А вы что подсмотрели у лидеров рынка в последнее время и какие выводы сделали?

Реальный сценарий открытия страницы товара (!) на мобильном устройстве по ссылке из рекламы.

А кто-то, наверное, ломает голову почему конверсия на телефонах такая низкая…

Фокус с календарем (он же фокус-день):
завести хотя бы 4 часа в неделю, когда тебя нельзя достать никак.

Продакт все время бегает: разблокирует команду, держит за руку клиентов, менеджит менеджера, договаривается с зависимостями, тушит пожары, планирует спринт, квартал, год. Мы такие занятые!

Между тем доказано, что мозг реагирует на сообщения (в соц сетях или slack’е) очень просто – ему нравится короткие картинка +текст или вопрос-ответ-решение, и он выдает порцию дофамина. Потом вторую. Потом пятую. Потом десятую. И потом, когда вы наконец решили сесть за стратегию, то… уже ничего не осталось на выдачу.

Плохо ли это? В режиме пожаротушения или просто “надо-сделать-это” проекта – отличный скилл.

Но действительно классные идеи так не рождаются. Для них нужно несколько часов загружать в мозг контекст (что ты хочешь сделать? что говорят эти 3 ресерча? что показали эти 5 экспериментов?) и тогда кукушка сделает именно то, что пока не может ChatGPT – соединит миллионы нейронов и выдаст “Эврика!” (например, заметит проблемный сегмент пользователей или возможность фичи).

Хорошие новости в том, что этот процесс выделяет больше дофамина, чем чатик. Плохие – что найти 4 часа продакту сложно.


Вот прямой сейчас давайте посмотрим в свои календари: на эту неделю забронировано время для сфокусированной работы? Сколько часов?

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

Для обработки электронной почты придумано много всяких полезных приемов: и автоматические фильтры, и система папочек, и концепция 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 в телеграм и приходите разобрать его на вебинаре. По желанию кейс можно разобрать анонимно.