Архив недели
Понедельник
Привет! Меня зовут Аня Лазуткина, я руковожу продуктом в Joom.
Joom — это кроссбордер маркетплейс, где пользователи из 100+ стран могут купить товары из 20+ стран.
На этой неделе я попробую передать вам мое ощущение от работы менеджера продукта.
Всем продуктивной недели!
Итак, начнем с анонса тем на эту неделю:
- В понедельник (то есть сегодня) поговорим о том, как придти в продукт — я расскажу свой путь
- Во вторник — про продуктовую команду и ее структуру
- В среду — про планирование
- В четверг — про эксперименты
- В пятницу — про личную продуктивность (когда я успешно доживу до пятницу, мне точно будет что рассказать 😂)
- В субботу — про собеседования и позицию продакта на рынке
- В воскресенье грех работать, поэтому поговорим про хобби и увлечения — что они дают для работы
А в дополнение по вечерам буду развлекать вас мини-кейсам из нашей реальной жизни и реальных экспериментов в Joom
Итак, тема сегодняшнего дня – как придти в продакт менеджмент. И начать хочу с опроса: а какие у вас отношения с продакт менеджментом?
Мой путь начался совсем не с менеджмента: 10 лет назад я пришла в IT... разработчиком :) потому что все что я понимала –– хочу работать в этой индустрии, но какие в ней есть позиции я конечно же не знала и очевидной была только эта
Начну с того, какие очевидные и важные плюсы я получила из этого опыта. Самое главное –– понимание процесса разработки изнутри: какие стадии задача проходит в голове разработчика, какие вопросы он задает, какие ошибки совершает
Это понимание дает огромное преимущество, когда ты формулируешь задачи и обсуждаешь их. Поэтому если у вас есть сложности в этой области –– очень советую пойти на курс разработки и попробовать самому что-то написать
Другой важный плюс – умение говорить на языке разработки. Это умение очень полезно, когда тебе нужно установить контакт (особенно на новом месте работы). Продакт должен говорить на языке бизнеса, но уметь объяснить все языком разработки, если это необходимо
Ну и третий пункт, который хочется выделить –– это очень хорошо развивает логическое и аналитическое мышление
Благодаря своей первой работе разработчиком я узнала, что есть такие люди –– продакт менеджеры. И поняла, что вот этим-то я и хочу заниматься, но я совсем ничего не понимала в бизнес составляющей и поэтому решила поучиться в бизнес школе
Бизнес школа дала мне скорее уверенность в своих силах, потому что теперь я знала, что такое P&L, EBIDTA и прочие интересные термины. Но к желанной работе продактом меня это не приближало (по крайней мере мне так казалось)
Поэтому параллельно я ходила на всевозможные курсы по управлению продуктом в IT (не буду рассказывать какие именно, это было N лет назад, а в сфере курсов все оч быстро меняется)
И они отлично легли поверх бизнес-образования, дав мне много полезных фреймворков и, что куда важнее, полезных знакомств и мотивирующих людей вокруг
Все это меня настолько замотивировало, что я приехала на стажировку в Aviasales и не смогла уехать обратно, решив, что дальше бизнес школа даст мне меньше, чем реальный опыт работы в IT
Так я бросила бизнес школу и стала работать аналитиком в Aviasales (да-да, все еще не продакт, но я уже стала на шаг ближе)
Что дала мне работа аналитиком: прежде всего серьезный рост аналитических скиллов, без которых невозможно стать хорошим продактом (а в дополнение у меня появилось умение самой посчитать необходимые данные, оно регулярно помогает мне)
Ну а кроме этого – я смотрела за своими коллегами продактами и впитывала их образ мыслей, подход к работе и логику принятия решений
Так в результате я оказалась на долгожданной позиции продакта и сейчас руковожу продуктом. Если резюмировать мой путь был такой:
- разработка
- бизнес школа и курсы
- аналитика
- продукт
Главная мысль, которую хочется тут раскрыть: на самом деле не важно с чего стартовать, главное понимать, каких знаний и умений тебе не хватает и искать способы их получения (и практические способы тут всегда работают быстрее теоретических)
Как и обещала, мини-кейс дня: мы улучшили внешний вид отзывов на товаре (допустим, фотографии стали крупнее). Запустили эксперимент: конверсия упала. При этом в срезе тех, кто на отзывы кликал она выросла, и в срезе тех, кто не кликал – тоже. Что произошло и что делать?
Через час посмотрим на самый популярный ответ и пойдем по этому сценарию :)
Итак, самое популярное предложение: искать проблему в данных. Пойдем к тестированию, проверим отправку всех событий –– проблем нет. К аналитикам –– и тут либо мы очень настойчивы и аналитики под нашим натиском потратят много времени на поиски проблемы.
Либо у нас классные аналитики и они расскажут нам про парадокс Симпсона: просто у нас перераспределились пользователи между теми, кто кликает в отзывы и теми, кто этого не делает
Конверсия кликающих в отзывы существенно выше, чем тех, кто не кликает в них. Часть из кликавших (не лучшая их часть) это делать перестала и перетекла в некликающих, тем самым повысив конверсию в обеих группах и понизив ее в целом
И что же нам делать? Пересмотреть дизайн так, что пользователи снова стали активнее кликать в отзывы
Вторник
Новые день – новая тема. Сегодня поговорим про продуктовую команду и ее структуру. Начну опять с опроса: какое на ваш взгляд идеальное соотношение продакт-разработчики в команде?
Мы в Joom прошли очень разные этапы жизненного пути продуктовой команды. Первый этап – все делают все. Это неминуемый этап для всех стартапов (если только у вас не стартап по организации продуктовой команды)
Это такой конфетно-букетный период, потому что все заряжены на максимум, всем все интересно и зоны ответственности делятся сами собой. Но не долго. Очень важно вовремя осознать, что людей в команде уже стало многовато и пора решить, кто чем будет заниматься дальше
Как понять, что пора?
- тянете одеяло в разные стороны
- тратите много время на разговоры и обсуждения
- делаете схожие вещи в разных местах
- часть людей начинает терять мотивацию
это из самого очевидного
Когда мы пришли в эту точку, первое решение, которое мы попробовали, было поделиться по командам, которые делают разные крупные проекты. Единственное правило – продакт в команде должен быть один.
По сути мы сделали команды вокруг продактов. Что было удобно
- приоритизировать задачи
- планировать ресурсы
Что плохо
- многие проекты в командах не связывало ничего, кроме продакта
- ресурсы распределялись не оптимально: одним не хватало задач, у других поджимали сроки
Нам очень не нравилось неоптимальное использование ресурсов и мы начали искать решение дальше. Следующим на очереди стало разделение по этапам пользовательской воронки
Но этот вариант мы отсекли уже на этапе обсуждения: мы планируемся по OKR (об этом поговорим завтра) и деление по воронке делало невозможным достижение амбициозных целей, потому что такие цели не достигаются на чекауте или онбрдинге
Что смущало нас в делении по воронке:
- продакт вынужден узко мыслить
- большая зависимость друг от друга, потому что крупные фичи идут сквозь разные этапы
- снова неоптимальное распределение ресурсов – что если мы не будем видеть большого потенциала на каком-то этапе?
Мы решили сделать финт ушами и соединить деление по проектам и воронке: окей, пусть каждый продакт "курирует" какой-то шаг воронки, собирает по нему беклог, следит за его состоянием, но команду при этом мы ему соберем вокруг проектов
Уже из описания должно быть понятно, что получилась какая-то непонятная штука, которая умерла, не успев родиться
И мы решили все немного структурировать: какие проблемы мы хотим решить?
- расфокус продактов и команды на несвязанные проекты
- неоптимальное распределение сил
- сложность планирования квартала и приоритезации
Мини-кейс: мы решили скрыть рейтинги с тех товаров, на которых слишком мало отзывов, и увидели рост открытий товаров. Почему?
В итоге мы разделили команду на 3 направления, в которых мы всегда работаем
- core – это направление отвечает за удовлетворенность пользователей
- growth – отвечает за рост
- new discovery – отвечает за смелые эксперименты
Теперь у каждого продакта появились ключевые метрики, на которых он мог фокусироваться, а все проекты мы стали просто разделять по этим направлениям исходя из того, какие метрики растит проект. Проблема расфокуса и несвязности проектов была решена
Чтобы решить проблему приоритизации и планирования мы разделили этот процесс на несколько уровней:
- сначала определяем приоритеты направлений, чтобы уделить внимание каждому
- потом приоритизируем проекты внутри направлений, сравнивая эффект на ключевые метрики
Самое главное, что так процесс планирования проходит гораздо быстрее, потому что каждый продакт сфокусированно думает о своих проектах
Чтобы решить проблему распределения ресурсов мы не стали делать жесткую привязку людей к направлениям работы
- каждый квартал продакт определяет, сколько ресурсов ему нужно
- лиды определяют капасити их команд
- мы все встречаемся и договариваемся о итоговом балансе
После этого продакты рассказывают всей команде продуктовой разработки о том, какие у них планы на следующий квартал, какие проекты хочется сделать и сколько ресурсов им нужно. И после каждый человек в команде может "записаться" в тот или иной проект
В результате мы получаем сформированные кросс-функциональные команды по направлениям. На самом деле они довольно стабильны из квартала в квартал, но система дает возможность людям сменить деятельность, когда им этого захотелось, или нам перераспределить ресурсы при необходимости
Чтобы добиться еще большей гибкости мы пришли к "матричному" планированию спринтов:
- сначала кросс-функциональная команда планирует задачи на спринт
- потом функциональная команда синхронизируется и по необходимости регулирует загрузку, перераспределяя какие-то задачи
Так все участники процесса максимально синхронизированы и вовлечены в происходящее, а продакты и лиды всегда могут договориться и поднажать в каком-то проекте за счет урезания другого
Итак: большинство голосует за то, что эти рейтинги были низкие, поэтому скрыв их мы перестали "отпугивать" пользователей с этих товаров. Но это не так – распределение по скрытым оценкам не отличалось от нашего общего распределения рейтингов
Ответ куда проще: рейтинг занимал дополнительную строку на превью товара. Скрыв его, мы сократили высоту превью => на экран стало помешаться чуть больше товаров => люди стали пролистывать больше товаров => чаще стали в них кликать
Но рост открытий не говорит о пользе такого изменения. Решение нужно принимать по целевым метрикам, которые определялись при запуске эксперимента :)
Среда
Итак, среду объявляем днем обсуждения планирования. Поэтому ставший традиционным опрос
Тут не будет долгой подводки и рассказа, как мы к этому пришли. Просто скажу – мы живем и планируемся по OKRs, у этого есть куча плюсов и такая же горка нерешенных вопросов. Обо всем этом сегодня я и расскажу
Итак, как это происходит:
- сначала мы формулируем цели компании на год
- потом их декомпозируем на цели компании на квартал
- затем накидываем примерные KR и рассказываем всей компании
Дальше начинается процесс командного планирования: все команды обсуждают, как они могут законтрибьютить в цели компании, формулируют проекты, обсуждают их с другими командами, формируют виртуальные команды
Когда планы всех команд сформулированы, появляется финальная версия OKRs компании. Какими правилами при формулировании OKRs мы пользуемся
- KRs либо измеримы, либо имеют дедлайн
- Выполнение всех KRs ведет к цели
- Невыполнения KR отдаляет от цели
- Целей и KRs в идеале от 3 до 5
Какие плюсы мы видим в OKRs: прежде всего они помогают командам сфокусироваться и выбрать то, что команда делать НЕ будет, потому что это не бьет в цели компании
Во-вторых, OKRs помогают синхронизировать планы разных команд и эффективно двигаться к цели, когда для ее достижения нужны ресурсы большого количества людей (а все самые крутые вещи рождаются именно из таких целей)
Кроме этого, OKRs делают работу всей компании прозрачной: любой человек в любой момент времени может посмотреть, чем занята та или иная команда и как это согласуется с планами всей компании
Также, OKRs очень хорошо учат людей структурировать свои планы, определять тайминг, зависимости и продумывать детали
Теперь перейдем к открытым вопросам (мы не любим слово "проблемы" :))
Самая большая опасность OKRs – начать тратить на планирование больше времени, чем на саму работу. Им нужен жесткий тайминг
Еще один вопрос: как не подменить OKRs проектное планирование. Важно помнить, что это разные процессы и OKR определяют цели и способы их измерить, а для продвижения по этим целям нужен отдельный процесс проектного планирования
Связанный с предыдущим пункт: есть большой соблазн подогнать цели и KRs под задачи команды и засунуть в OKRs весь беклог своих задач. Это уж точно не поможет вам сфокусироваться
Ну и главное, не всем командам подходит такой формат. Мы для себя сформулировали это так: OKRs нужны, если есть какое-то состояние А и качественно новое состояние B, а наша задача совершить скачек из А в В. Если же такого скачка не планируется – OKRs вряд ли оправданы
Да, лучше поздно, чем никогда. Что такое OKRs
- O – objectives (куда хотим придти)
- KRs – key results (как измерим, что пришли куда хотели)
Причем цели должны быть достаточно амбициозны, а компенсация не должна зависеть от достижения этих целей. В этом главное отличие от KPIs
Почему OKRs, а не KPIs: KPIs оправданы, если на выбранную метрику влияет только одна команда (например, time to response в команде саппорта). В продуктовой команде таких метрик нет и если привязать компенсацию продакта к прибыли его фич – он не будет проводить смелые эксперименты
Сегодня будет формат "а что если": как думаете, что будет, если при уходе пользователя из чекаута уточнять у него, уверен ли он, что хочет уйти?
Опрос я забыла ограничить во времени, поэтому победителя узнаем только завтра, а пока идем плотненько! Мы проводили такой эксперимент из расчета, что лишний попап на выходе заставит пользователя передумать и продолжить покупку => вырастет конверсия
Но в итоге просто ничего не произошло – никаких значимых изменений. Если человек передумал завершать покупку – уточнение его намерений не заставляло его передумать 🤷🏼♀️
Зато это отличное место, чтобы узнать, а почему же передумал пользователь!
Четверг
Итак, сегодняшняя тема дня – эксперименты. Мы в Joom совершенно повернуты на цифрах и ни одна новая функциональность не выходит в прод без тестирования. Ну практически ни одна. А вы?
Начнем с гипотез: мы следим за культурой проведения экспериментов и начинаются они всегда с формулирования гипотезы
Откуда берутся гипотезы – тут ничего нового
- из данных (аналитика, предыдущие эксперименты)
- из фидбека пользователей
- из рынка
- из других индустрий
- с брейнштормов
- просто из головы (своей или коллег)
Гипотеза есть – теперь думаем, как ее проверить. Стандартные варианты
- уже был схожий эксперимент
- можно провести опрос/эксперимент "на коленке"
- надо пописать код
- вообще не надо это тестировать
Мы стараемся прибегать к варианту "пописать код" в последнюю очередь. Когда это вообще не надо тестировать:
- оценили эффект и он того не стоит
- не можем оценить эффект и не очень сильно верим в фичу
Ну а теперь к самому интересному: как именно мы работаем с экспериментами. У нас есть своя платформа экспериментов, которая полностью забирает на себя заботу о распределении пользователей по группам, валидации метрик и многому другому
Что должен сделать продакт:
- сформулировать гипотезу
- выставить фильтры для выборки
- определить целевую метрику
- определить предполагаемое изменение (размер выборки и срок эксперимента платформа подскажет)
- сконфигурировать тестовые группы
В каждый момент времени у нас запущено порядка 70 экспериментов одновременно (наш трафик это позволяет) и без платформы, которая нас валидирует и помогает нам, это все превратилось бы в хаос
Как мы спасаемся от хаоса: прежде всего у нас есть иерархия метрик. В любом эксперименте мы смотрим на 3 ключевые метрики: оборот, прибыль, конверсия – и на целевую метрику текущего эксперимента
Добиться значимого роста общей метрики может быть сложно, поэтому у каждой команды есть свои прокси-метрики, на которые она опирается. Эти метрики конечно же провалидированы на платформе и мы знаем как и с какими ключевыми метриками они коррелируют
Пример такой метрики – конверсия из открытия товара в добавление в корзину. Какие-то небольшие изменения в UI на карточке товара могут не повлиять значимо на общую конверсию, но в таком срезе показать значимый результат
Также в нашей платформе есть два пространства для запуска экспериментов: общее, где разные эксперименты пересекаются, и эксклюзивное, где у одного пользователя может быть не больше 1 эксперимента
В эксклюзивном пространстве мы запускаем сложные и долгие эксперименты, либо потенциально ухудшающие эксперименты (чтобы не портить жизнь остальным)
Чтобы в общем пространстве не было вакханалии у каждого эксперимента проставляются теги команды, его запускающей, и этапы пользовательской воронки, которые он аффектит. Это позволяет нам следить, что мы не запустили одновременно 15 экспериментов в корзине, например
Ну и поверх всего в нашей платформе есть автоматические проверки, которые следят за основными потенциальными проблемами и сообщают автору, если целевая метрика ведет себя не ожидаемо или если его эксперимент сильно пересекся с чем-то другим
Гипотезы собрали, эксперимент запустили, теперь поговорим про результаты. Тут кроется все самое загадочное :) По моему опыту, взлетевших с первого раза экспериментов бывает максимум процентов 10. И из них еще 10% – взлетели, а ты этого вообще-то не планировал.
Поэтому стандартный флоу:
- открыл результаты эксперимента
- сел чесать голову
- собрался брейнштормить с командой, что с этим делать дальше
Как мы "дебажим" эксперименты – сначала надо убедиться, что внезапные значимые изменения не случайны. Обосновать их логически и доказать на данных. Если вы изменили что-то в поиске, а у вас выросло количество отзывов – вы смотрите на странные метрики и вряд ли изменения связаны
Смогли обосновать их логически – бинго, у вас есть новая гипотеза для доработки и проверки. Если не смогли – надо поискать баг. Если и бага нет, все данные в норме, логического объяснения не нашлось – признайте это случайностью и катите (можно с долгим обратным, чтобы наверняка)
Окей, эта схема работает, если целевая метрика повела себя ожидаемо, но обнаружились другие сайд эффекты. А если целевая меняется не в ту сторону или не меняется вообще?
Тут все также немного вариантов
- баг
- новая гипотеза
- плохо сконфигурировали эксперимент (мало данных, не те метрики)
- эксперимент не удался и ваша гипотеза опроверглась
И ничто, кроме опыта работы с вашим продуктом и вашими пользователями не научит вас быстро выбирать правильный вариант из этих четырех. А чтобы получить опыт – нужно немного поошибаться
Поэтому главное в любом эксперименте подвести для себя итог и сделать вывод. Даже если вы не раскатываете эксперимент: почему вы этого не делаете, какую гипотезу вы проверяли и что в итоге получили
Сегодня такой кейс: вы запустили новый онбординг, в целом у вас растут метрики, но вы решаете посмотреть срезы по каждой стране отдельно и видите, что по большОй части стран результаты не значимы, а в одной (допустим, Франции) – отрицательные. Что делать?
Пятница
Победил вариант: не катить и разбираться. Ну давайте разберемся. А были ли у нас вообще причины предположить, что онбординги поведут себя по-разному в разных странах?
- да –– стоило запускать отдельные эксперименты
- нет –– почему они появились сейчас?
Важно помнить, что чем больше метрик и наблюдений мы добавляем, тем выше шанс встретить случайный прокрас. Если сказать по-другому, добавляя новые метрики и наблюдения рано или поздно вы найдете значимые результаты в пользу своей гипотезы. Не надо так делать :)
В данном случае, если у нас нет веских логических оснований считать, что в какой-то стране онбординг может навредить и мы по опыту знаем, что пользователи этих стран ведут себя подобным образом –– эксперимент стоит раскатить на все страны
Если сомнения не дают спать спокойно –– раскатить с обратным, то есть не давать это изменение части пользователей
Ну а если у вас есть гипотеза, почем все произошло именно так – тогда конечно же стоит дорабатывать функционал и проверять ее
Сегодня поговорим про личную эффективность. Даже без опроса :) Я не могу назвать себя самым эффективным человеком: люблю оставлять запас времени на внезапности и не оценивать их пользу. Но у меня есть немало личных лайфхаков, которые помогают мне не сойти с ума в потоке задач.
Первое и самое главное правило: я записываю все
- заметки со встреч
- рандомные идеи
- задачи любого размера
- ссылки на интересные треды в слаке
В общем абсолютно все я скидываю в одну кучу (в файлик в эверноуте)
В конце каждой недели я разбираю эту заметку и что-то делаю, что-то переношу в другие заметки на будущее :) Но наверняка я знаю одно: если не записать – в нужный момент я буду помнить, что было что-то важное, но не смогу вспомнить что :)
Другой лайфхак относится к сообщениям в слаке. Не так давно слак дал возможность группировать всех и вся. И я, как любитель порядка, конечно же этим воспользовалась
Да-да, я разобрала людей по группам 🤷🏼♀️ и каналы. Теперь я всегда вижу от кого у меня больше всего сообщений и понимаю, могу ли я отложить их просмотр
Самый большой потенциал кроется в Unreads – я всегда просматриваю превью входящих сообщений и помечаю прочитанным неважное. Важное остается нотификациями в баре, напоминая мне вернуться и ответить. Главное – в unreads можно ответить в треде, что, допустим, вернешься через 4 часа
Это позволяет мне держать руку на пульсе, не сходить с ума от потока обращений и действительно оперативно реагировать на все важные вещи. Да, еще поверх этого лучше включить do not disturb и читать слак раз в час/полчаса
Ну и тема продуктивности не будет раскрыта без разговора о календаре. Как выглядит мой календарь
Да, я не только группирую людей в слаке, но и раскрашиваю встречи :)
- зеленые – регулярные синки/1-1/планирования
- розовые – время на глубокую работу
- синие – рабочие встречи
и конечно же обед. Покушать – это святое
Я, кстати, не очень люблю концепцию never eat alone, потому что для меня обед – время сделать паузу и перевести дух. Желательно наедине с едой :)
Зачем раскрашивать встречи – это позволяет мне следить за балансом. Я где-то раз в квартал провожу ревью своего календаря и оцениваю, насколько оптимально тратится мое время и что и где мне хотелось бы пофиксить
Кроме того, цвета помогают мне группировать схожие встречи. 8 часов глубокой работы, размазанные по неделе, не сравняться с днем, проведенным в работе над сложной задачей
Еще одна концепция, которую я подглядела у коллеги, но не успела внедрить до конца: блок на поздние встречи. Так у тебя не появятся внезапности в 8 вечера, а для чего-то действительно важного всегда будет место
Ну и нерабочая активность: я ярый противник заносить в календарь нерабочие приятные вещи, типа тренировок или встреч с друзьями, так у них пропадает шарм. Но вот заблокировать под них время – это святое. Например, у меня стоит блок на вечер среды, потому что по средам я рисую
В чем разница: там нет рисования с 19.00 до 21.00. Там просто стоит блок на весь вечер, который говорит мне: в этот вечер ты точно не работаешь
И одно клевое правило, применимое ко всем задачам, о котором мне недавно рассказал коллега. Правило 4 "D":
- Drop – сразу выкинуть и никогда не делать
- Delay – отложить и скорее всего в итоге не делать
- Delegate – передать кому-то
- Do – сделать, если ничего выше не отработало
Кейс: если пользователь согласился получать пуши – он с большей вероятностью вернется. Было: системный запрос на доступ к пушам на старте приложения. Стало: красивый экран с вариантами пушей, на которые можно подписаться. Подписки на пуши выросли, возвращаемость упала. Почему?
Кстати, хочу сказать, что верных ответов тут вообще нет, это либо примеры из жизни, либо мои рассуждения
В данном случае действительно подписки были не на те пуши. Возвращаемость бустили конкретные пуши. Но когда мы дали пользователям выбор – они не выбирали этот тип пушей. В результате подписок стало больше, а профита от них меньше
Суббота
Итак, сегодня поговорим про позицию продакта на рынке труда и собеседования. Я постоянно вижу, что много людей хотят стать продактами, куча компаний ищет продактов, но крайне редко у этих людей совпадает восприятие этой позиции.
Что хотят компании от людей, которых называют продактами
- управлять разработкой
- решать задачи (часто весьма конкретные)
- считать цифры
- улучшать метрики
- генерировать деньги
Что хотят будущие продакты
- сделать прорывной продукт, которым они пользуются сами и о котором будут рассказывать всем (в идеале в видео Дудя 😂)
Sooo toxic, но я правда любя :)
Что на самом деле делает продакт (по крайней мере в нашем мире)
- изучает пользователей (не себя 😂)
- генерирует кучу гипотез
- ошибается и учится на своих ошибках
- разгребает всякое 💩
- тушит пожары
Это я все к тому, что позиция продакта все больше романтизируется, но на самом деле крутые штуки можно делать, только изрядно набив шишки и делая не только то, что вам нравится
Поэтому мы, например, обращаем большое внимание на собеседованиях на умение человека загораться от своих идей и быть готовым пройти через любые интересности ради этого. И это необязательно про работу: если вас зажигает хобби — значит и в работе вас можно разжечь :)
Воскресенье
На воскресенье я оставила самую абстрактную тему дня — хобби и увлечения и какую пользу они приносят в работе. Я очень ответственно отношусь к своему правилу не работать по выходным, поэтому сегодня просто расскажу вам, какие интересные открытия я сделала в своих увлечениях
Начну с рисования. Каждое занятие заканчивается тем, что преподаватель смотрит на работы учеников и хвалит каждую, находя в ней что-то особенное. Сначала мне было некомфортно и это казалось странным, типа «вот сегодня я откровенно не очень нарисовала, зачем притягивать за уши?!»
Но потом я поняла, насколько это крутая механика. Даже если ты недоволен собой — тебе показывают те стороны, которых ты сам мог не увидеть. И в результате ты можешь пересмотреть свою самокритику (а в ней-то мы все мастера!).
Не говоря уже о том, что потом ты бежишь на занятия за этой порцией дофамина! В общем, хвалите своих коллег и подчиненных чаще, мы это сильно недооцениваем
Теперь про сёрфинг: я очень люблю доски и недавно открыла для себя искусственную волну. В первые же пару попыток я получила знатные синяки и когда пришла в следующий раз: страх упасть просто сжирал меня, я буквально чуть не развернулась и не ушла
Но есть важное правило: чтобы перестать бояться упасть, нужно просто как можно скорее упасть и осознать, что это не страшно. Чем дольше вы боитесь, тем сложнее вы делаете для себя этот шаг. Вот такой каламбур.
Поэтому я всегда стараюсь перешагнуть через свой страх, как только он появился, не дав ему развиться и прочно закрепиться в голове. В работе это часто находит отражение в боязни ошибиться и сделать что-то не так. Чем дольше боишься, тем меньше вероятности, что вообще сделаешь
И мой любимый серф пример: если хочешь красиво проехать по волне — расслабься. Пока ты напряжен и скован — будешь ошибаться на ровном месте, потому что малейшая шероховатость выбьет тебя из строя. Если ты расслаблен — тело само отработает все неровности, а ты их даже не заметишь
И это работает во всем. Чтобы все получилось — нужно расслабиться и получать удовольствие от того, что ты делаешь. Какой бы сложный ни был у вас проект — наслаждайтесь им. И тогда закончить его успешно будет гораздо проще и кучу проблем вы даже не заметите ❤️
Пора подвести итоги недели. Мне было очень интересно поделиться с вами своими мыслями, поэтому, надеюсь, вы тоже нашли в них что-то полезное для себя. И спасибо твиттеру за ограничения по количеству символов, никогда ещё я не вкладывала столько смысла в такие короткие фразы 😂
Итак, тема сегодняшнего дня – как придти в продакт менеджмент. И начать хочу с опроса: а какие у вас отношения с продакт менеджментом?
Итак, тут можно почитать про мой разобранный по косточкам путь в продукте twitter.com/produnderhood/…
Новые день – новая тема. Сегодня поговорим про продуктовую команду и ее структуру. Начну опять с опроса: какое на ваш взгляд идеальное соотношение продакт-разработчики в команде?
Здесь все о том, как устроена команда продукта в Joom и как мы к этому пришли twitter.com/produnderhood/…
Итак, среду объявляем днем обсуждения планирования. Поэтому ставший традиционным опрос
Тут мои мысли про OKRs и рассказ о том, как все устроено у нас в Joom twitter.com/produnderhood/…
Итак, сегодняшняя тема дня – эксперименты. Мы в Joom совершенно повернуты на цифрах и ни одна новая функциональность не выходит в прод без тестирования. Ну практически ни одна. А вы?
Это тред для любителей экспериментов и фанатов данных twitter.com/produnderhood/…
Сегодня поговорим про личную эффективность. Даже без опроса :) Я не могу назвать себя самым эффективным человеком: люблю оставлять запас времени на внезапности и не оценивать их пользу. Но у меня есть немало личных лайфхаков, которые помогают мне не сойти с ума в потоке задач.
Внезапно самый популярный тред — мои лайфхаки личной продуктивности twitter.com/produnderhood/…
Итак, сегодня поговорим про позицию продакта на рынке труда и собеседования. Я постоянно вижу, что много людей хотят стать продактами, куча компаний ищет продактов, но крайне редко у этих людей совпадает восприятие этой позиции. https://t.co/bEM6IUH1iC
Рассуждения на тему вакансии продакта на рынке twitter.com/produnderhood/…
На воскресенье я оставила самую абстрактную тему дня — хобби и увлечения и какую пользу они приносят в работе. Я очень ответственно отношусь к своему правилу не работать по выходным, поэтому сегодня просто расскажу вам, какие интересные открытия я сделала в своих увлечениях
И немного философии о том, какие полезные для работы открытия можно сделать, уделяя достаточно внимания хобби и увлечениям twitter.com/produnderhood/…
Как и обещала, мини-кейс дня: мы улучшили внешний вид отзывов на товаре (допустим, фотографии стали крупнее). Запустили эксперимент: конверсия упала. При этом в срезе тех, кто на отзывы кликал она выросла, и в срезе тех, кто не кликал – тоже. Что произошло и что делать?
А ещё по вечерам мы обсуждали разные кейсы:
как может выглядеть парадокс Симпсона в реальном эксперименте twitter.com/produnderhood/…
Мини-кейс: мы решили скрыть рейтинги с тех товаров, на которых слишком мало отзывов, и увидели рост открытий товаров. Почему?
Как минимальное изменение UI может внезапно отразиться на метриках twitter.com/produnderhood/…
Сегодня будет формат "а что если": как думаете, что будет, если при уходе пользователя из чекаута уточнять у него, уверен ли он, что хочет уйти?
Стоит ли останавливать людей от ухода с процесса оплаты заказа twitter.com/produnderhood/…
Сегодня такой кейс: вы запустили новый онбординг, в целом у вас растут метрики, но вы решаете посмотреть срезы по каждой стране отдельно и видите, что по большОй части стран результаты не значимы, а в одной (допустим, Франции) – отрицательные. Что делать?
Почему не стоит смотреть на 15 метрик в 30 срезах twitter.com/produnderhood/…
Кейс: если пользователь согласился получать пуши – он с большей вероятностью вернется. Было: системный запрос на доступ к пушам на старте приложения. Стало: красивый экран с вариантами пушей, на которые можно подписаться. Подписки на пуши выросли, возвращаемость упала. Почему?
И какие сюрпризы несёт красивый онбординг для подписки на пуши twitter.com/produnderhood/…
❤️